灰度发布（一）

一、术语
1、灰度周期，由测试/用户决定
2、金丝雀的故事
3、产品说的AB测试
4、客户端APP的灰度，版本更新交由后台控制
5、Java Agent
6、互联网APP常见的玩法

最后灰度发布是什么？
---- 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

二、灰度能做什么
1、白天发布，不用等到晚上11点，夜深人静的时候。
2、应用程序的新旧版本需要共存一段时间，用于做AB测试。
3、把新版本程序当做金丝雀，不影响真实用户的请求。

三、灰度不能做什么
1、应用程序在发布的时候，重启的时候足够安全吗，会影响线上用户吗？
2、线上灰度验证的时候，发现出问题然而开发不能及时修复，程序需要回滚，假如有已执行的数模，也需要回滚，怎么办？
3、它能够帮助我们远程断点或btrace新版本的应用程序吗？

四、灰度的实现
1、必备的条件有：

• 除正常节点外的灰度节点
• 配置灰度规则
• 在请求的入口处，一般是网关层，对流量进行染色
• 应用程序的启动时，加载agent jar包

2、染色的流程

中台服务需要灰度.png 前台服务需要灰度.png

3、灰度规则
支持按流量比例和精准分配两种。精准可以是userId、IP、设备号等，只要http header能取出的key，都将支持配置到灰度规则。

4、传递灰度标识
在网关层进行打上标签，常用做法就是http header增加一个key。（kong plugin 安装灰度插件）
按链路访问顺序，由上往下进行传递，这里为了减少业务方的接入成本，采用java agent技术，做到对业务的完全透明。（java应用程序加载灰度agent的jar包）

5、灰度发布的流程

发布流程.png

五、发布的方式有哪些
除了灰度发布，还有重要的蓝绿发布。
（灰度是允许新旧版本同时存在，蓝绿则规定在同一个环境下，要么是新版本，要么是回滚到旧版本）。
一般地，建议在预发环境下，实现蓝绿发布。在预发环境未验证通过前，预发环境是新版本，而生产环境是旧版本。

六、灰度发布带来了哪些问题
1、预期的流量是要打到灰度节点的，最后却打到正常节点了。如何核实？
现在一般的做法是通过traceId，查询kibana的日志。

2、灰度标识在全链路的整个链路传递的过程中，容易被服务或组件丢失。如何排查到底是哪个组件导致的？

3、日志与监控
日志需要采集，做法和jvm日志一样采用ELK。日志中需要包含程序的版本号、IP等关键信息。