这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
本堂课主要内容是微服务架构，下面是我个人听课时的一些笔记。主要是核心服务治理功能和字节跳动服务治理实践两部分内容，是上一篇笔记的续篇。
个人笔记
核心服务治理功能
核心的服务治理功能，包括流量治理、服务均衡、稳定性治理。
-
服务发布
难点：
- 服务不可用
-
服务抖动（服务中某个或某些实例的不可用）
-
服务回滚（之前代码没问题，新上线的代码有bug，需要回滚）
-
蓝绿部署
解决思路：在一个服务中设置两个cluster集群，在上述问题出现时交替切换使用集群，从而达到无损升级
优势是简单搞笑
弊端是需要两倍资源
-
灰度发布（金丝雀发布）
金丝雀(canary) 对瓦斯及其敏感，17世纪时，英国旷工在下井前会先放入一只金丝雀,以确保矿井中没有瓦斯。像放一只金丝雀一样，在发布新代码时先只增加一个新代码的instance实例，没有问题出现的话，逐步将旧的实例替换为新的实例
弊端是需要以实例为维度精细地控制流量，这对于负载均衡是很大的挑战，且回滚较为复杂（这是为了节省资源所带来的代价）
-
流量治理/流量控制
在微服务架构下，我们可以基于地区、集群性能、实例情况、请求类型等维度，对端到端流量的路由路径进行精确控制。
-
负载均衡
负载均衡(LoadBalance)负责分配请求在每个下游实例上的分布。
常见的LoadBalance策略：
Round Robin Random Ring Hash Least Request
-
稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
除了程序的正确性之外，可能遇到其它问题：网络攻击、流量突增、机房断电、光纤被挖、机器故障、网络故障、机房空调故障等等
- 限流（rate limit）
- 熔断（circuit）
- 过载保护（dynamic overload）
- 降级（degrade）
总结：
-
服务发布：蓝绿部署、灰度发布
-
基于地区、集群、实例、请求等维度的流量治理功能
（流量治理更像是全流程都有的，而负载均衡着眼于上游服务的流量流向下游服务中的实例这个过程的均衡）
-
几种常见的负载均衡策略
-
微服务架构中的稳定性治理功能
字节跳动服务治理实践
字节跳动在微服务架构稳定性治理中，对请求重试策略的探索及实践。
-
远程函数调用可能出现的异常：
网络抖动；下游负载高导致超时；下游机器宕机；本地机器负载高，调度超时；下游熔断、限流；
-
重试的意义：
重试可以避免掉偶发的错误，提高SLA（Service-Level Agreement）
-
降低错误率
假设单次请求的错误概率为0.01，那么连续两次错误概率则为0.0001
-
降低长尾延时
对于偶尔耗时较长的请求，重试请求有机会提前返回。
-
-
容忍暂时性错误
某些时候系统会有暂时性异常(例如网络抖动)，重试可以尽量规避。
-
避开下游故障实例
一个服务中可能会有少量实例故障(例如机器故障)，重试其他实例可以成功。
-
重试的难点：
幂等性：多次请求可能会造成数据不一致
重试风暴：随着调用深度的增加，重试次数会指数级上涨
超时设置：超时时间的设置
-
重试策略：（用于降低重试风暴）
限制重试比例：用一个比例阈值来限制重试次数占所有请求的比例
防止链路重试：链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明“请求失败，但别重试”。
Hedged requests：对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求， 并等待先到达的响应。
参考
- 字节内部课 —【微服务架构原理与治理实践】
