一、灰度发布系统简介
灰度发布（又名金丝雀发布）是指在多版本之间，能够平滑过渡的一种发布方式。比如一个产品或服务迭代更新, 又要保证上线的影响范围，这个时候就需要一个灰度发布系统。这里我们主要介绍云客服产品的灰度发布实现方式。
灰度发布一般分为三部分：
- 灰度部分用户请求至新版本或新服务
- 测试、运营分析灰度效果
- 紧急回退 或 全量灰度
我们将上面三部分从开始灰度到全量或回退或或称或称为灰度期。
l 灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。
二、灰度发布的优势
1.提前测试线上环境隐性问题
2.提前收集客户反馈，完善不足
3.验证产品的效果
4.控制问题发生范围
5.发现重大问题，可回滚"旧版本", 降低回滚成本
三、常见灰度发布
- 定义目标
- 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
- 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
- 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
- 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
- 产品完善
- 新一轮灰度发布或完整发布
l 以上信息来源百度百科
四、灰度发布实现
根据客服系统的场景，我们将灰度系统分为三部分。ABTest，前后端灰度, 和移动端灰度，下面我们详细说明各部分的实现方式。
1.Test
ABtest 是常见的一种灰度方式，常用与UI改版方案的测试，测试那种更符合客户的习惯和需求等。实现方式一般为负载均衡或nginx 分流。例如我们有新的注册页面上线，但是我们又担心新版本的效果，那么我们可以使用这种方式。灰度后对两个页面的注册人数进行对比，来决定使用老版本还是新版本。
以下为以nginx 为例的AB test 示例。
我们将前端分为两个版本, 分别位于 /data/resources_0 和 /data/resources_1 目录, 然后根据访客请求的 ip 和 端口进行hash, 然后按 1:1 的权重分配资源, 配置如下:
2 前后端灰度
这里有人会疑惑为什么前后端的灰度是在一起的。因为在目前的互联网环境下，前后端分离已经是必然的趋势，前后端的版本往往是要适配的。比如后端修改了某接口的地址或数据结构，那么前端必然是需要调整的。所以我们灰度发布时往往是前后端绑定一起的。
在客服系统中，既有付费用户，也有体验用户。我们往往希望将付费用户的影响降到最低，于是我们对访客请求在 web 层进行分流，分为高危（付费用户）和非高危（体验用户）, 然后后端版本升级时先灰度一部分非高危用户，测试完成后观察一段时间，再进行全量。这样很好的可以控制影响范围，也能让体验用户第一时间体验到新功能，收集反馈结果。
以下我们以用户请求 cookie 中的 userid 为灰度条件, 使用 nginx lua 扩展, 将用户请求转发不通版本的服务。主要流程为:
- 客户请求至 web 服务 （nginx）
- 从客户请求的 cookie 中获取用户的 userid
- 根据 userid 从 redis 中查询该用户灰度的版本（A、B…），当 cookie 中没有 userid 或 没有查询到灰度版本时，我们设置为默认版本。（及上一个全量版本）
- 获取到灰度版本后转发到对应后端服务
- 流程结束
nginx lua 部分代码如下:
nginx 配置部分:
3.移动端灰度
在客服系统中，必然存在众多移动端访客，有时基于浏览器 cookie 的灰度方式不一定合适，所以我们可以考虑这种的方式。实现方式和后端灰度方式类似，只不过将判断请求服务版本的部分交给了客户端，服务端只需要维护一个可以获取用户灰度版本的地址池。当客户端请求服务器时,先获取请求服务的地址，再根据获取到的地址进行请求。常用于手机端或C/S客户端。
例如服务端现有两个版本 A 和 B，A 版本的地址是 192.168.1.1, B 版本的地址是 192.168.2.1, 那么手机端的流程如下:
1.登录后 根据 userid 获取请求地址
2.A 用户获取地址为 192.168.1.1，B 用户获取地址为 192.168.2.1
3.根据请求地址连接不同地址服务，达到灰度效果。
这种方式的有点是不依赖服务端判断，由于请求地址是动态的, 安全性也有所提升。当然，这种方式存在一定弊端，如 A 版本出现问题后，我们将A地址池中的A 版本地址改为 B版本地址，但是手机端用户必须强制杀掉手机端app 才会获取到新地址，不过这种问题还是可以使用其它方式避免的。例如定期 check 地址有效性。
五、总结
灰度发布系统一般都是从公司的业务及需求点出发设计和架构出来的，所以没有优劣之分，只有合适的轮子才能让业务高效、快速的前行。