这是我参与「第五届青训营 」笔记创作活动的第12天。注：笔记大部分图片内容及代码段为青训营课程视频提供，仅交流，不得做个人使用
一、本课主要内容
微服务核心治理 | 字节跳动服务治理中的探索
二、本节详细知识点
核心服务治理功能
-服务发布
-流量治理
-负载均衡
-稳定性治理
字节跳动服务治理探索
-重试的意义
-重试的难点
-重试的策略
-重试效果验证
1核心治理服务功能
1.1服务发布
服务发布( (deployment),即指让一个服务升级运行新的代码的过程。
服务发布的难点
使服务不可用
让服务停止是很严重的问题
服务抖动
短暂的性能故障也是不好的
服务回滚
新代码可用性达不到要求
- 蓝绿部署
暂时切换到部分集群。等待另外的集群进行升级操作。
简单、稳定，但需要两倍的资源
- 灰度发布（金丝雀发布） 金丝雀（canary) 对瓦斯及其敏感 17世纪时英国矿工在下井前会先放入一一只金丝雀以确保矿井中没有瓦斯。
也是一种滚动发布
难点:需要精细化的流量控制、回滚操作十分困难
1.2流量治理（流量控制）
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精细化治理
1.3负载均衡
负载均衡（Load Balance) 负责分配请求在每个下游实例上的分布
-常见的LB策略：
Round Robin、 Random、 Ring Hash、 Least Request
1.4稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
网络攻击
流量突增
机房断电
光纤被挖
机器故障
网络故障
机房空调故障
...
微服务中为了应对以上非典型问题，架构里提供了典型的稳定性治理功能
限流：servB拒绝
熔断：servA暂时不去连接servB，等一些时间再尝试
过载保护：servB接近上限后拒绝
降级：根据重要程度选择性接收
1.5小结
服务发布：蓝绿部署、灰度发布
基于地区、集群、实例、请求等维度的流量治理功能
几种常见的负载均衡策略
微服务架构中的稳定性治理功能
2字节跳动服务治理实践
2.1重试的意义
- 一个本地函数调用：
可能有哪些异常？
参数非法
OOM（Out Of Memory）
NPE（Null Pointer Exception）
边界case
系统崩溃
死循环
程序异常退出
思考：这种本地函数的调用有重试的必要么？
- 一个远程函数调用
可能有哪些异常？
网络抖动
下游负载高导致超时
下游机器宕机
本地机器负载高，调度超时
下游熔断、限流
思考：这种调用有重试的必要么？
重试可以避免掉偶发的错误，提高SLA （Service-Level Agreement）
-重试三次：
降低错误率：假设单次请求的错误概率为0.01，那么连续两次错误概率则为0.0001。
降低长尾延时：对于偶尔耗时较长的请求，重试请求有机会提前返回
容忍暂时性错误：某些时候系统会有暂时性异常（例如网络抖动），重试可以尽量规避
避开下游故障：实例一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功。
- 既然重试有这么多好处，为什么默认不用？
2.2重试的难点：
重试风暴
微服务的调用链路一般较深（可能几十层），可怕的放大效应。
2.3 策略
- 应对策略——限制重试比例
设定-一个重试比例阀值（例如1%）重试次数占所有请求比例不超过该闸值。（当大部分其他步骤成功时才允许重试）
- 应对策略——防止链路重试
链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。
——可以返回特殊的status表明请求失败但别重试
- 应对策略——Hedged requests（对冲请求） 对于可能（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
2.4重试效果验证
实际验证经过上述重试策略后，在链路上发生的重试放大效应。
for循环和接入重试组件方式的系数比较明显。
小结
-重试的意义及难点
-应对重试风暴的策略
