这是我参与「第五届青训营 」笔记创作活动的第11天。
服务发布：灰度发布（金丝雀发布）的意义如下所示： 金丝雀（canary）对瓦斯极其敏感，17世纪时，英国矿工在下井前会先放入一只金丝雀，以确保矿井中没有瓦斯。
流量治理：在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
负载均衡：
定义如下：负载均衡（Load Balance）负责分配请求在每个下游实例上的分布。算法有 Round Robin， Random， Ring Hash，Least Request等。
稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。问题主要有以下这些：
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
治理方法如下：
- 限流
- 熔断
- 过载保护
- 降级
字节跳动服务治理实践：
重试的意义如下：
本地函数调用可能有哪些异常？
- 参数非法
- OOM (Out Of Memory)
- NPE (Null Pointer Exception)
- 边界 case
- 系统崩溃
- 死循环
- 程序异常退出
远程函数调用可能有哪些异常？
- 网络抖动
- 下游负载高导致超时
- 下游机器宕机
- 本地机器负载高，调度超时
- 下游熔断、限流
重试可以避免掉偶发的错误，提高 SLA（Service-Level Agreement）
————————降低错误率：
假设单次请求的错误概率为 0.01，那么连续两次错误概率则为 0.0001。
————————降低长尾延时：
对于偶尔耗时较长的请求，重试请求有机会提前返回。
————————容忍暂时性错误：
某些时候系统会有暂时性异常（例如网络抖动），重试可以尽量规避。
————————避开下游故障实例：
一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功。
重试的难点有幂等性，重试风暴，超时设置等。
重试策略
-
限制重试比例 设定一个重试比例阈值（例如 1%），重试次数占所有请求比例不超过该阈值。
-
防止链路重试 链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。 可以返回特殊的 status 表明“请求失败，但别重试”。
-
Hedged requests 对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
