从0到1搭建简单的灰度发布系统

系统发布的演进之路

一般情况下我们系统发布需要将老系统关掉，然后将新系统进行启动，这种发布方式就会有一个比较致命的问题：服务短暂不可用，如果新代码存在bug可能会造成更长时间的故障，那么业界的前辈们想了很多解决方案。

蓝绿部署

所谓蓝绿部署，是指同时运行两个版本的应用，如上图所示，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。但是蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要3台服务器支撑业务，那么使用蓝绿部署，你就需要购置6服务器。
滚动发布

所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要6台服务器，那么升级过程中也就只需要6+1台就行了。但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。为了解决这个问题，我们需要为滚动升级实现流量控制能力。

开源灰度发布技术

基于Nginx+LUA：https://docs.konghq.com/
对齐k8s service，借助istio网格技术实现流量入口控制：http://apisix.apache.org/
基于选择器加签机制实现流量控制：https://shenyu.apache.org/zh/docs/index/

什么是灰度发布系统

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。（来源于百度百科）

灰度发布的好处

线上验证
提前获得目标用户的使用反馈
根据反馈结果，做到查漏补缺优化产品体验
发现重大问题，可回滚"旧版本"

灰度发布的流程

产品和开发共同定义灰度目标人群
针对灰度目标人群制定灰度策略
将灰度策略写入配置
灰度集群发布
灰度目标用户进行线上体验，开发人员以及产品收集反馈并优化产品
进行新一轮灰度

灰度发布的实现思路

业务代码接入

一套线上环境，在业务代码中做开关，对于不同的用户走不同的逻辑。

环境隔离

多套隔离的线上环境，在接入层针对不同用户转发到不同的环境中。

方案	优点	缺点
业务代码接入	灵活，粒度细；一套代码（环境）运维成本低	灰度逻辑侵入代码
环境隔离	基本不侵入代码，风险小，灵活度更高	多套线上环境，运维成本高

流程图如下：

根据我们的业务场景我们需要按照用户维度做灰度发布的思路去做，那么重点就是在转发层做处理，将特定的用户请求分流转发到具有新功能的服务上去。

架构图

用户请求首先到达Nginx然后转发到网关Zuul，此时Zuul拦截器会根据用户携带请求token解析出对应的userId
网关从Apollo配置中心拉取灰度用户列表，然后根据灰度用户策略判断该用户是否是灰度用户。如是是灰度用户则把用户信息增加到请求头以及ThreadLocal中，经过负载均衡转发到灰度服务；否则直接放行

灰度流程

在灰度之前去配置中心配置灰度策略，然后灰度服务发布
用户发送请求经过Nginx，然后转发到gennat-moat
gennat-moat首先判断灰度开关是否打开，如果未打开则直接fallback到非灰度单元
如果灰度开关打开，则拦截请求中的token解析出对应的userId
gennat-moat去配置中心拉去灰度配置，比如拉取灰度用户列表
gennat-moat去比较拦截的用户ID是否在灰度用户列表中，如果不在灰度列表中则fallback到非灰度单元
如果拦截的用户ID在灰度列表中，则在请求头中增加灰度标签tag=gray从而实现灰度服务打标
通过负载均衡继续请求下游
下游解析请求头的tag是否等于gray，如果是则走灰度单元并且将tag=gray放到请求头中进行透传
否则直接fallback到非灰度单元（这里就实现了单元级别灰度，也可以实现全链路灰度）

灰度策略

用户维度，存储在配置中心
IP维度，需要依赖注册中心
流量百分比
基于自定义扩展点机制对用户透明

数据库灰度

数据库不做隔离，灰度环境也是真是真实生产环境
新增字段/新增表支持灰度
更改字段支持涉及到修改业务逻辑所以不支持灰度（也可以考虑新老字段做mapping，但是也会污染业务代码，不建议）

Dubbo服务灰度

多版本：https://dubbo.apache.org/zh/docs/advanced/multi-versions/
服务分组：https://dubbo.apache.org/zh/docs/advanced/service-group/
流量管理：https://dubbo.apache.org/zh/docs/concepts/traffic-management/

消息系统的灰度

消息的灰度发布实现是比较困难的，因为消息的收发经过消息服务器，没有中介者可以干预路由，但有一个简单的思路，即生产者到消费者的过程中，消费者消费完消息，不做具体的业务逻辑，而是将消息通过服务调用的方式，调用不同版本的服务，在不同的服务中去做不同的业务逻辑，从而实现了消息的灰度。

针对业务上用的rabbitMQ，绑定不同的vhost、queue以及topic，即消息发送⽅、消费⽅在同⼀个分组内从而实现分割

Job灰度

创建不同的执行器以及不同的JobHandler来满足不同的环境，不同的执行器配置不同的执行IP，比如灰度执行器配置灰度机器的IP，从而不会影响线上既有代码

配置灰度

通过Apollo支持分组的特性实现配置下发，做到灰度配置只下发到灰度分组

高可用设计

一个高可用的系统，预防故障的发生，首先要排除性能隐患，保证高性能。

gannet-moat请求做了全异步化处理，请求通过Netty线程异步提交到业务处理线程池，调用后端服务使用RPC或HTTP框架的异步方式，释放了由于网络等待引起的线程占用，使线程数不再成为网关的瓶颈。

稳定性保障

流量管控：从用户自定义UUID限流、App限流、IP限流、集群限流等多个维度提供流量保护。
超时管理：每个API都设置了处理超时时间，对于超时的请求，进行快速失败的处理，避免资源占用。
熔断降级：支持熔断降级功能，实时监控请求的统计信息，达到配置的失败阈值后，自动熔断，返回默认值。

灰度回滚方案

关闭灰度开关
数据库因为是向上兼容，所以不需要回滚（这里新增的字段需要给默认值防止影响线上既有代码）

规范发布流程

日常发布中，我们常常会有如下一些错误的想法：

这次改动的内容比较小，而且上线要求比较急，就不需要测试直接发布上线好了
发布不需要走灰度流程，快速发布上线即可
灰度发布没有什么用，就是一个流程而已，发布完就直接发布线上，不用等待观察
虽然灰度发布很重要，但是灰度环境很难搭建，耗时耗力优先级并不高

这些想法都可能让我们进行一次错误的发布，不少故障是因为发布直接或间接引起。因此提升发布的质量，减少错误的发生，是有效减少线上故障的一个关键环节。做到安全的发布，我们需要规范发布的流程。

未来规划

对接服务治理体系

服务治理是主要针对分布式服务框架的微服务，处理服务调用之间的关系、服务发布和发现、故障监控与处理，服务的参数配置、服务降级和熔断、服务使用率监控等。

需要服务治理的原因：过多的服务 URL 配置困难负载均衡分配节点压力过大的情况下，需要部署集群服务依赖混乱，启动顺序不清晰过多服务，导致性能指标分析难度较大，需要监控故障定位与排查难度较大。

全链路隔离流量泳道

通过设置流量规则对所需流量进行“染色”，“染色”流量会路由到灰度机器。灰度流量携带灰度标往下游传递，形成灰度专属环境流量泳道，无灰度环境应用会默认选择未打标的基线环境。

进入带 tag 的节点后续调用优先选择带有相同 tag 的节点，即对经过 tag 节点的流量进行“染色”
有 tag 的调用链路上找不到相同 tag 的节点，则 fallback 到无 tag 的节点
有 tag 的调用链路经过无 tag 的节点，如果链路后续调用有 tag 的节点，则恢复 tag 调用的模式

业内开源框架

http://apisix.apache.org/
https://shenyu.apache.org/zh/docs/index/