灰度发布实现及蓝绿发布

1.0 简介

随着公司业务的不断发展壮大，需要一套稳妥的发布方案，如果发布的新版本服务有问题能及时撤回，不至于造成太大范围的影响;

2.0 现状

手动部署代码

• Scp、Rsync上传代码;
• 登陆，Git pull 或者 Svn update;
• xftp、ftp、filezilla上传代码;
• 发送压缩包，rz上传，解压部署代码;
• docker镜像打包部署;

缺点

• 如果节点多，上线速度慢。
• 人为失误多，目录管理混乱。
• 回滚不及时，或者难以回退。
• 一旦部署的新版本有问题，会影响到所有用户。

3.0 方案

3.1 灰度发布

灰度发布是一种常见的服务滚动升级或A/B测试策略。在新版本服务正式发布前，可以部署少量的新版本服务和上个版本共存，用部分生产流量测试新版本的功能和特性。如果新版本反馈良好，则可以渐进地提高新版本的比例或者全部替换成新版本，如果有问题也能够及时撤回，不至于造成太大范围的影响。

原理图

发布过程

1 . 发布前检查：预检查当前 Ingress 是否有且只关联了唯一的 Service 实例，且 Service 实例下有且只有唯一版本的 Deployment。

2 . 生成 Canary 版本：克隆 primary 版本的 Service 以及 Deployment 生成 canary 版本的 Service 和 Deployment，同时修改 canary 版本 Deployment 的镜像到新版本。

3 . 修改 Ingress 流量规则：根据发布配置调整 Ingress 配置，开始执行灰度。

4 . 人工验证：通过 cookie 或者 header 对灰度版本进行验证，根据结果选择完成发布或者回滚。

5 . 完成灰度：修改 Ingress 配置以及流量规则，下线 Primary 版本的 Service 以及 Deployment 实例。

6 . 回滚发布：修改 Ingress 配置以及流量规则，下线 Canary 版本的 Service 以及 Deployment。

实现

即将迁移的ack容器服务灰度功能支持cookie,header,query等类型，匹配规则有完整匹配和正则匹配

1 . 代码中做;

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

2 . 接入层做;

多套(隔离的)线上环境,接入层针对不同用户转发不同的环境中;

实现方法一(侵入代码)

将含有header含有js-design:v1.2进行分流，百分之二十请求(配置中心或者后台管理做配置)新服务的逻辑，其余请求访问老版本逻辑;

后端比较耗费精力，比如是否用到数据库，字段是否改变，事务，灰度版本成功老系统数据同步等;

实现方法二(接入层)

接入层一般采用nginx，可以基于以下两种方式分流:

IP

可以针对比如一个办公室公网IP进行匹配到新版本服务，进行测试体验，如果有问题改进再发布;

cookie

如果有用户登录逻辑可以选择基于cookie, 基于cookie又可以细分为两种:

1 . nginx维护Cookie名单文件，每来一个请求看Cookie是否在名单中，做不同的转发,每次请求都要去判断是否是灰度用户会造成性能损耗, 变更Cookie名单需要操作接入层服务;

2 . nginx不维护Cookie名单文件，根据Cookie的特征进行转发

1 . 业务中维护白名单文件（存放在数据库中）;

2 . 在登陆时(如果是公司内部员工，测试人员，接受内测)的用户在名单中则给用set特定标识的Cookie；退出或Session过期后Cookie失效;

3 . nginx匹配特定Cookie，做转发;

这样，调整灰度的范围，只需要操作数据库即可，无需重启服务。

通过header实现灰度发布验证

待改进

1 .

2 .

3 .

3.2 蓝绿发布

不停老版本,部署新版本然后进行测试，确认ok，将流量切换到新版本，然后老版本升级到新版本;

特点

无需停机，并且风险较小;

部署过程

第一步: 部署版本1应用(开始状态)

所有外部请求流量都达到版本1上;

第二步: 部署版本2的应用;

版本2的代码与版本1不同(新功能，bug修复等);

第三步: 将流量从版本1切换到版本2;

第四步: 如版本2测试正常，就删除版本1正在使用资源(例如实例1),从此正式使用版本2;

小结

从过程不难发现，部署过程中，应用始终在线，并且新版本上线过程中，并没有修改老版本的任何内容,在部署期间，老版本的状态不受影响，这样做风险很小，并且只要老版本资源不被删除，理论上，我们可以在任何时间回滚到老版本;

注意:

两倍资源，机器损耗;

新旧接口不兼容;

故障定位困难;

后台删数据，更新数据;

当你切换蓝色环境时，需要妥当处理未完成业务和新的业务，如果你的数据库后端无法处理，会出现数据不一致问题;

需要提前考虑数据库与应用部署同步/回滚问题;

蓝绿部署需要有基础设施支持;

非隔离基础架构(VM,Docker)上执行蓝绿部署，蓝绿环境有被摧毁的风险;