关于不停机发布新版本程序的方式

“不停机发布新版本程序”，暂且这么称呼吧，其实就是所说的滚动发布、灰度发布、金丝雀发布和蓝绿发布。
之所以会总结性地提一下这几个概念，主要是本次出门游历，流浪到了乌兰察布市四王子旗，在这儿遇上了个有趣儿的家伙，就此话题进行了兴致勃勃地探讨，借此记录一下探讨结果。

滚动发布是指每次只升级一个或多个服务， 升级完成后加入生产环境， 不断执行这个过程， 直到集群中的全部旧版本升级新版本。 本质是新版本逐步替换旧版本。

操作过程：

先升级 1 个副本， 主要做部署验证；

每次升级副本， 都需将待操作副本从 LB 上先摘掉， 待升级成功后再加入集群；

事先需要有自动更新策略， 分为若干次， 每次数量/百分比可配置；

回滚是发布的逆过程， 先从 LB 摘掉新版本， 再升级老版本， 这个过程一般时间比较长；

业务部署自动化程度要求高。

开始滚动升级后， 流量会直接指向已经启动起来的新版本， 但是这个时候，新版本是不一定可用的， 比如需要进一步的测试才能确认。 那么在滚动升级期间， 整个系统就处于非常不稳定的状态， 如果发现了问题， 也比较难以确定是新版本还是老版本造成的问题。

蓝绿发布提供了一种零宕机的部署方式。 不停旧版本， 部署新版本进行试， 确认业务状态无异常后， 将流量切到新版本。 始终有两个版本同时在线，有问题可以快速切换。 一套是正在提供服务系统， 标记为“绿色” ； 另一套是准备发布的系统， 标记为“蓝色” 。 两套系统都是功能完善的， 并且正在运行的系统， 只是系统版本不同。 开发了新版本， 要用新版本替换线上的旧版本，在线上的系统之外， 搭建了一个使用新版本代码的全新系统。 这时候， 一共有两套系统在运行， 正在对外提供服务的系统是绿色系统， 新部署的系统是蓝色系统。 蓝色系统经过反复的测试、 修改、 验证， 确定达到上线标准之后， 先将绿组的集群从负载均衡中移除， 由蓝组则对用户提供服务。 这段时间内观察蓝色系统（新系统） 工作状态， 如果出现问题， 直接切换回绿色系统。 当确信对外提供服务的蓝色系统工作正常， 不对外提供服务的绿色系统已经不再需要的时候， 蓝色系统正式成为对外提供服务系统， 成为新的绿色系统。 原先的绿色系统可以销毁， 将资源释放出来， 用于部署下一个蓝色系统。 或者移出的绿组进行服务的升级， 等升级完毕后， 再从新将绿组接入到负载均衡中为用户提供服务。 再把蓝组进行移除销毁， 将资源释放出来， 用于部署下一个蓝色系统。此时整个项目集群得进行升级完毕， 我们将此称为蓝绿发布。

蓝绿部署能够简单快捷实施的前提假设是目标业务系统是非常内聚的， 如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。

金丝雀发布（Canary Release） ， 中国大陆又称作灰度发布（Gray Release）。本质上是在生产环境上引一部分实际流量对一个新版本进行测试， 测试新版本的性能和表现， 在保证系统整体稳定运行的前提下， 尽早发现新版本在实际环境上的问题， 以确定产品交付形态。 它在一部分用户中逐步推出新功能或更新，以便在全面推出之前进行测试和评估， 这种方法可以帮助开发人员识别和解决潜在的问题， 同时最小化对用户的影响。 也算是一种软件产品质量测试方式，新版本如果出现问题， 只会发生在低比例的流量上。

事实上金丝雀发布（Canary Release） 和灰度发布（Gray Release） 略有区别： 金丝雀发布是只有一套系统， 版本升级是逐步替换这套系统； 灰度发布则是有稳定和灰度两套环境， 只升级部分服务， 一部分用户继续用老版本， 一部分用户开始用新版本， 如果用户对新版本没什么意见， 那么逐步扩大范围，把所有用户都迁移到新版本上面来， 即通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本。

金丝雀发布实现步骤：
步骤一： 将流量从待部署节点移出， 更新该节点服务到待发布状态， 将该节点称为金丝雀节点；
步骤二： 根据不同策略， 将流量引入金丝雀节点。 策略可以根据情况指定， 比如随机样本策略、狗粮策略、分区策略、用户特征策略；
步骤三： 金丝雀节点验证通过后， 选取更多的节点称为金丝雀节点， 重复步骤一和步骤二， 直到所有节点全部更新。