这是我参与「第三届青训营 -后端场」笔记创作活动的的第四篇笔记.

• 本次青训营课程中，微服务架构课程分为上下两篇，这是下篇《微服务架构原理与治理实践》。前面架构相关的课程有《架构初探-谁动了我的蛋糕》。
• 我把《微服务架构原理与治理实践》的笔记也分为上下两篇。这是下篇，本篇介绍了核心服务治理功能以及字节跳动内部的服务治理实践
• 微服务架构原理与治理实践 (上篇)| 青训营笔记 - 掘金 (juejin.cn)

话不多说，我们开启本篇笔记~

3.核心服务治理功能

服务发布

含义:即指让一个服务升级运行新的代码的过程。 难点：

• 服务不可用
• 服务抖动
• 服务回滚 蓝绿部署： 一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统，切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统工作状态，如果出现问题，直接切换回绿色系统。

优点： 简单，稳定

缺点： 需要两倍的资源

灰度发布(金丝雀发布)： 17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。

部署新版本的系统的时候，先让一些用户适用新版本，然后再慢慢扩大比例，最后实现全量。

流量治理

在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。

负载均衡

负载均衡（Load Balance）负责分配请求在每个下游实例上的分布

常见的LB策略:

• Round Robin
• Random
• Ring Hash
• Least Request
• ......

稳定性治理

线上服务总是会出问题的，这与程序的正确性无关

• 网络攻击
• 流量突增
• 机房断电
• 光纤被挖
• 机器故障
• 网络故障
• 机房空调故障
• ......

微服务架构中典型的稳定性治理功能：

• 限流
• 熔断
• 过载保护
• 降级

4.字节跳动服务治理实践

重试的意义

本地函数调用存在的问题:

• 参数非法
• OOM(Out Of Memory内存溢出)
• NPE(Null Pointer Exception空指针异常)
• 边界case
• 系统崩溃
• 死循环
• 程序异常退出 远程函数调用存在的问题:
• 网络抖动
• 下游负载高导致超时
• 下游机器宕机
• 本地机器负载高，调度超时
• 下游熔断、限流
• ......

重试的意义：重试可以避免掉偶发的错误，提高SLA(Service-Level Agreement)，但是重试只适用于远程函数调用

• 降低错误率

  假设单次请求的错误概率为0.01，那么连续两次错误的概率为0.0001

• 降低长尾延时

对于偶尔耗时较长的请求，重试请求有机会提前返回

• 容忍暂时性错误

  可尽量规避网络抖动

• 避开下游故障实例

  一个服务中可能会有少量实例故障，重试其他实例可以成功

重试的难点

既然重试有这么多好处，为什么默认不用呢？

幂等性：多次请求可能会造成数据不一致

重试风暴:随着调用函数的增加，重试册数会指数上涨

超时设置：假设一个调用正常是1s的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢？

重试策略

限制重试比例：

设定一个重试比例阈值（例如1%），重试次数占所有请求比例不超过该阈值

防止链路重试

链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试，可以返回特殊的 status 表面 “请求失败，但别重试”

Hedged Request

对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到的响应

重试效果验证

实践验证经过上述重试策略后，在链路上发生的重试放大效应

END