go-微服务知识点.docxVIP

Info 配置管理 不鼓励，运行时（on-the-fly）修改 redis mysql 配置 默认值 -> 最佳实践值 避免复杂 多样的配置 简单化努力 以基础设施 -> 面向用户进行转变 配置的必选项和可选项 配置的防御编程 权限和变更跟踪 配置的版本和应用对齐 安全的配置变更：逐步部署、回滚更改、自动回滚 包管理 单元测试 api 层 - 集成测试 / yapi dao 层 - gomock 参考 -? /go-kratos/beer-shop Cache Line cache，中译名高速缓冲存储器，其作用是为了更好的利用局部性原理，减少CPU访问主存的次数。 cache 分成多个组，每个组分成多个行，linesize 是 cache 的基本单位，从主存向 cache 迁移数据都是按照 linesize 为单位替换的。比如 linesize 为 32Byte，那么迁移必须一次迁移 32Byte 到 cache。 这个 linesize 比较容易理解，想想我们前面书的例子，我们从书架往书桌搬书必须以书为单位，肯定不能把书撕了以页为单位。书就是 linesize。当然了现实生活中每本书页数不同，但是同个 cache 的 linesize 总是相同的。 所谓8路组相连（ 8-way set associative）的含义是指，每个组里面有8个行。 高速缓存其实就是一组称之为缓存行( cache line )的固定大小的数据块，其大小是以突发读或者突发写周期的大小为基础的。 隔离 表数据 稿件表 基本信息，不会频繁修改 稿件统计表 播放、点赞、收藏等数据 数据分开以后，可以增加其性能 采用 CQRS 实现的领域驱动设计与经典 DDD 有很大的不同 数据读写分离是在数据库层面来实现读写分离的机制，而 CQRS 是在业务逻辑层面来实现读写分离机制 为什么需要引入CQRS模式 传统的实现方式也会存在一些问题： 使用同一个领域实体来进行数据读写可能会遇到资源竞争的情况。所以经常要处理锁的问题，在写入数据的时候，需要加锁，读取数据的时候需要判断是否允许脏读。这样使得系统的逻辑性和复杂性增加，并会影响系统的吞吐量。 在大数据量同时进行读写的情况下，可能出现性能的瓶颈。 使用同一个领域实体来进行数据库读写可能会太粗糙。在大多是情况下，比如编辑操作，可能只需要更新个别字段，这时却需要将整个对象都穿进去。还有在查询的时候，表现层可能只需要个别字段，但需要查询和返回整个领域实体，再把领域实体对象转换从对应的DTO对象。 读写操作都耦合在一起，不利于对问题的跟踪和分析，如果读写操作分离的话，如果是由于状态改变的问题就只需要去分析写操作相关的逻辑就可以了，如果是关于数据的不正确，则只需要关心查询操作的相关逻辑即可。 CQRS也有其使用场景： 系统的业务逻辑比较复杂的情况下。因为本来业务逻辑就比较复杂了，如果再把命令操作和查询操作绑定同一个业务实体的话，这样会导致后期的需求变更难于进行扩展下去。 需要对系统中查询性能和写入性能分开进行优化的情况下，尤其读/写比例非常高的情况下。例如，在很多系统中读操作的请求数远大于写操作，此时，就可以考虑将写操作抽离出来进行单独扩展。 系统在将来随着时间不断变化的情况下。 然而，CQRS 也有其不适用的场景： 业务逻辑比较简单的情况下，此时采用 CQRS 反而会把系统搞的复杂。 系统用户访问量都比较小的情况下，并且需求以后不怎么会变更的情况下。针对这样的系统，完全可以用传统的实现方式快速将系统实现出来，没必要引入 CQRS 来增加系统的复杂度。 业务划分等级 L0/L1/L2 快慢隔离 按照各种纬度隔离：sink、部门、业务、logid、重要性（S/A/B/C） 热点隔离 访问频次最高的数据，对其进行缓存 remoteCache 提升为 localCache 主动预热 线程隔离 把业务进行分类，并交给不同的线程池进行处理 进程隔离 case study 转码被大视频攻击，导致转码延迟 缩略图服务，被大图吃完 CPU，小图被丢弃 数据库未隔离，导致大 SQL 引起故障 INFO 日志量大，导致 ERROR 日志采集延迟 SOP 一般指标准作业程序。所谓 SOP，是 Standard Operating Procedure 三个单词中首字母的大写 ，即标准作业程序 checklist 超时 超时控制，组件可以快速失效（fail fast） 没有什么比挂起的请求和无响应的界面更令人失望 良好的超时策略，可以尽可能让服务不堆积请求，尽快清空高延迟的请求，释放 goroutine 业务迭代，耗时发生变化，意外导致依赖超时 服务提供者定义好 latency SLO 更新到 gRPC proto 定义中 后