go 进阶训练营 微服务可用性(上） 笔记

隔离

本质上是对系统和资源进行分割，从而实现当系统故障时能限定传播范围和影响范围，即发生故障后只有出问题的服务不可用，保证其他服务仍然可用。

服务隔离

动静隔离

mysql 表中的bufferpool 频繁过期，隔离动静表。如 稿件的基本信息，作者、封面等和稿件的播放、点赞 频繁变化的数据进行的隔离。

cdn 的静态资源和动态资源的隔离。动态api的时候还讲了一个case 如边缘计算，qps高的时候可以在边缘节点加一个小程序进行压缩汇总，pipeline 打包发送到真正的处理地址，这个可以降低qps 节省服务器。

读写分离

cqrs command 和 query 进行分离，也就是写请求和读请求进行分离。比如 审核服务，审核是一个比较重的业务逻辑，也有多道程序，审核的逻辑和稿件的展示底层存储可以分离。审核的程序完成之后，对应稿件的存储层才可以进行展示，将关注点进行分离。

轻重隔离

业务按照 Level 进行资源池的划分(L0、L1、L2)

这里想起来之前做广告服务的时候，收集广告、点击的服务之前是一个接口通过不同参数进行区分，而且是写入同一张表，qps比较大的时候，处理不过来会丢失部分点击数据，点击数据需要回掉给广告主，所以是比较重要的请求，后续将 底层表 点击、曝光进行拆分，将接口也进行拆分，因为点击qps比较少，处理明显提高，隔离开之后，不会受曝光qps的增加影响核心点击数据的写入。

快慢隔离

将不同业务维度进行隔离，防止某些业务出现问题，影响整体不可用。

热点隔离

小表广播：从remote cache 提升为 local cache,定时更新local cache.

主动预热：统计热点数据中的top k 数据进行主动预热。

物理隔离

线程隔离

java 中线程池的隔离

进程隔离

容器化 docker

集群隔离

多集群部署

机房隔离

多活

超时控制

本质上：fail fast。良好的超时控制策略，可以尽可能地让服务不堆积请求，尽快清空高延迟的请求，释放Go routine.

具体做法：

默认值：一定要设置默认超时时间，而且要防御一下，比如超过60s，我们内部rpc 默认超时时间是250ms,当然有些job 扫表的超时时间不够，可以调整client的超时时间到800ms去解决。

超时传递：进程间传递+跨进程传递(grpc 默认支持）

看了一下 请求db的时候是有 Shrink 方法的，收敛context 的超时时间

如果上游 ctx 有 Deadline(),则从 上游的deadline 中获取超时时间，和自己设置的超时时间进行比较，两者比较获取较小的，这样就可以进程间传递超时时间了

gRPC 框架底层通过 HTTP2 协议发送 RPC 请求时，将 timeout 值写入到 grpc-timeout HEADERS Frame 中

参考：

《Go 进阶训练营》

gRPC 系列——grpc超时传递原理