得物蓝绿发布演进

1. 得物蓝绿发布演进中间件平台宋加林

2. 目录 01 蓝绿发布的背景 02 什么是蓝绿发布 03 蓝绿发布发布控制 04 组件适配-RPC 05 组件适配-MQ 06 组件适配-JOB 07 蓝绿发布的收益

3. 0 1 背景

4. 滚动发布

5. 滚动发布-梯队大规模微服务架构下，敏捷迭代和跨域协同的需求催生了梯队+滚动发布模式将发布车队中的服务按依赖顺序进行梯队分组(DAG) 按自底向上、依赖先发的原则，保证发布时新功能流量无损图 1 图 2

6. 滚动发布-效率发布过程总计使用 12 个单位时间

7. 滚动发布-痛点准备工作繁琐串行发布耗时长缺乏灰度 &止血能力传统的滚动发布方式已经不能满足得物对大版本发布的效率和稳定性需求

8. 0 2 蓝绿发布

9. 蓝绿发布-拆分提前将服务集群拆分为对等的蓝、绿两个子集群一次性的前置动作服务进程通过启动时注入的环境变量感知所处蓝、绿集群

10. 蓝绿发布-蓝集群摘流蓝集群梯度的将流量摘除绿集群缓慢承接全部流量绿集群逐渐承接全部流量，需要盯盘关注其水位

11. 蓝绿发布-蓝集群发布蓝集群(左侧)摘流后，流量全部由绿集群(右侧) 承接新代码已经提前构建完成蓝集群(左侧)内多个服务的多个节点进程可以无损停机、更新代码、启动确认蓝集群节点都正常启动后可引入小流量灰度

12. 蓝绿发布-蓝集群引流蓝集群(左侧)代码更新后，可通过控制面板，梯度的将流量引入更新代码后的蓝集群(左侧) 利用小流量在蓝集群(左侧)验证新代码逻辑的可用性、老代码逻辑的兼容性请求链路封闭在蓝或绿集群，不会交叉调用验证过程中有异常情况可以随时对蓝集群(左侧)摘流止血、hotfix

13. 蓝绿发布-蓝集群验收、绿集群发布此时流量已经全部导入到新代码测试同学在此时介入进行老功能回归、新功能验证蓝集群新、老代码验收通过后，绿集群发布新代码

14. 蓝绿发布-绿集群发布、引流原则上无需验证，代码预热后可以快速引流已经没有备用的、稳定版本的老代码，没有回退逻辑，所以该流程是固定的，可以自动化进行

15. 蓝绿发布-发布完成蓝、绿集群都替换了代码并各自承接50% 的流量请求不再封闭在蓝绿一侧

16. 蓝绿发布-流程回顾

17. 蓝绿发布-效率发布过程总计使用 7 个单位时间，同比滚动发布模式减少 5 个单位时间摘流、发布新代码、引流、验证等步骤是多服务并行进行的发布的服务越多，相对滚动发布提效越明显

18. 蓝绿发布-优势请求链路粘性解耦发布依赖批量构建批量部署精确流量调度异常快速止血

19. 0 3 发布控制

20. 发布控制-通道发布通道是对待发布服务逻辑上的聚类、分组(服务名单) 发布通道是发布时批量操作的抓手发布通道上各自关联独立的服务名单和流量比例发布通道可以同时并存多个同一个发布通道内的服务间保证RPC请求粘性，DAG形式的多服务在一个通道里发布

21. 发布控制-图解(RPC)

22. 发布控制-流量规则流量规则是关联到发布通道的配置信息包含通道的状态(是否活跃)、通道内包含哪些服务、通道当前的流量比例

23. 发布控制-流量规则SDK (调度SDK) 流量规则SDK是蓝绿发布能力的代码底座，负责和元数据中心通讯、交互它屏蔽了流量规则的细节，向中间件组件如 RPC、MQ、JOB提供了主动查询流量规则和被动接受流量规则变更事件的能力各中间件组件响应流量规则变更进行合适的动作实现蓝绿流量调度

24. POIZON 发布控制-控制面板

25. 0 4 组件适配 - RPC

26. RPC适配-流量调度(Dubbo) RPC请求的过程是去中心的点对点调用流量服从蓝绿流量比例需要调用方服务在调用时控制被调用方需要让上游调用方感知到自身实例的流量比例和蓝绿颜色

27. RPC适配-加权负载均衡加权负载均衡实现流量调度的优势兼容性透明无感开箱即用加权逻辑和通用负载均衡逻辑是正交的，兼容常用的负载均衡算法借助服务注册实例本身的元信息来传播实例权重、流量比例信息，规避了人常用的RPC框架如Dubbo 所有内置负载均衡算法都识别、处理服务实例权重，肉梳理服务上下游的复杂度和风险规避了梳理、推动上游调用方进行SDK升级的难点

28. RPC适配-稳定性实例权重变更请求错峰当发布涉及的服务较多、影响的集群节点较多时，流量规则变更导致的注册中心服务实例权重变更会产生大量的注册中心接口写调用，为规避潜在的稳定性风险，各个服务进程感知流量规则变更后会随机延迟（最大延迟5s，可动态配置）后再请求注册中心。集群摘流时禁用集群实例考虑到注册中心上注册的服务实例可能存在其他DubboRPC以外的，无法识别、响应服务实例权重的使用者，导致集群摘流不彻底影响无损重启服务进程。在感知到蓝、绿集群摘流时，流量规则SDK会直接禁用注册中心上被摘流的集群服务实例，让摘流实例对服务订阅者不可见。集群半数实例修改实例权重权重值是相对的，只需要保证蓝、绿集群实例权重的相对比重服从流量比例即可，无需同时修改蓝绿集群所有实例的权重。实例权重初始值设为100，修改权重时，尽可能保证一半集群实例权重保持100不变，只修改另一侧被调整的集群实例的权重。将蓝绿集群流量比例状态从1:1调整到3:1的两种变更方式

29. RPC适配-请求粘性蓝绿子集群的代码版本是有差异的，按我们制定的发布流程，蓝集群是新代码，绿集群是老代码。如果不能固定请求链路的颜色实现请求链路一蓝到底或者一绿到底，那么可能会出现上游新代码调用到下游老代码，产生代码兼容性问题。因此，需要通过某种方式，在请求链路上缓存、透传通道维度的蓝绿节点决策结果并复用。

30. RPC适配-流量标透传借助既有的、广泛接入的基于 OpenTracing的全链路压测基础设施，实现通道蓝绿路由标链路透传。如果当前Trace中有下游被调用服务所属通道蓝绿路由决策结果，则服从该蓝绿决策结果筛选节点。否则按照下游服务实例权重筛选、决策实例，并将决策结果(下游集群实例颜色)append到Trace中向后透传、复用。

31. RPC适配-路由决策调用方在发起向下游的调用时，拥有如下路由决策信息: 1. 请求途经过的所有通道的蓝绿决策结果(Trace) 2. 下游被调用服务的服务标识(注册中心服务实例元信息) 3.下游被调用服务的所有服务实例(注册中心) 4. 当前所有发布通道元信息(流量规则SDK)

32. 0 5 组件适配 - MQ

33. MQ适配-流量调度(RocketMQ)

34. MQ适配-非发布状态蓝、绿集群对每一个订阅关系各自启动两个消费组

35. MQ适配-摘流状态服务感知到通道内蓝集群摘流时，蓝集群节点关闭消费组，绿集群节点启动三种颜色消费组。此时，MQ流量完全由绿集群接管。通道内绿集群摘流时同理。

36. MQ适配-稳定性单消费组到多消费组的升级、过渡窗口兼容性服务集群拆分时，集群内部分节点是单消费组、部分是多消费组。存在一个集群实例状态不一致、消息消费逻辑不一致的时间窗口。如果不做兼容处理，会出现消费倾斜、消息丢失、重复消费等问题。利用动态交割开关将蓝绿多消费组消费逻辑生效的时间延后到集群状态一致来规避。 MQ消费堆积导致透传的通道蓝绿决策结果过时 MQ消息上也缓存、透传了通道蓝绿决策信息。当消息消费堆积，缓存的决策信息已经滞后于当前实时的流量规则。过时的决策信息会对后续链路产生错误的干预，导致下游服务摘流不彻底等问题。通过在MQ消费时修正该决策信息来规避。

37. 0 6 组件适配 - JOB

38. Job适配-流量调度(elasticJob) 对elasticJob的任务分配、执行的逻辑进行定制任务执行会避让已经摘流的集群节点，保证已经摘流的服务集群节点上没有任务在运行，继而可以无损重启

39. 0 7 收益

40. 收益发布效率横向对比蓝绿发布落地前后10次大版本发布耗时如右图整体有 50% 以上的效率提升随着使用熟练度提升、流程打磨优化，大版本发布耗时最好成绩是 2.5 小时单位：小时

41. 谢谢