蓝绿发布原理概要
1. 概述
在一般情况下，升级服务器端应用，需要将应用源码或程序包上传到服务器，然后停止掉老版本服务，再启动新版本。但是这种简单的发布方式存在两个问题，一方面，在新版本升级过程中，服务是暂时中断的，另一方面，如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。
蓝绿发布便是解决上述问题的一种方式。
蓝绿部署是一种应用发布模式，可将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中（两者均保持在生产环境中运行）。
旧版本可以称为绿色环境，而新版本则可称为蓝色环境。一旦生产流量从绿色完全转移到蓝色，蓝色就可以在回滚或退出生产的情况下保持待机，也可以更新成为下次更新的模板。
本文介绍的蓝绿发布方案，在上述思路上针对多应用并行发布做了一些定制，以下通过图解说明相关要点。
2. 核心功能
蓝绿发布的核心功能是实现多应用 (设N=发布应用数) 批量摘流、并行发布、批量引流、并行验证，以实现发布提效。
多应用发布场景兼容单应用发布场景(即上述N=1)。
以下通过一个典型的案例说明上述功能。
假设现在有一个新需求，需求涉及的3个应用(A、B、C)的接口都有变更。代码已经开发、测试完毕，需要发布到生产环境。
应用间依赖拓扑如下图：
以RPC作为流量示例，其他流量 (MQ、JOB) 也是类似的逻辑
2.1 滚动发布(既有的发布模式)
为保证新功能请求不会出错，目前使用的是【自底向上，依赖先发】的分批滚动发布模式。先发布C，验证后发布B，验证后发布A。
2.1.1 整体发布时序
| 时间\应用 | A应用 | B应用 | C应用 |
|---|---|---|---|
| t1 | 【等待】 | 【等待】 | 单节点发布 |
| t2 | 【等待】 | 【等待】 | 验证 |
| t3 | 【等待】 | 【等待】 | 全量发布 |
| t4 | 【等待】 | 【等待】 | 验证 |
| t5 | 【等待】 | 单节点发布 | |
| t6 | 【等待】 | 验证 | |
| t7 | 【等待】 | 全量发布 | |
| t8 | 【等待】 | 验证 | |
| t9 | 单节点发布 | ||
| t10 | 验证 | ||
| t11 | 全量发布 | ||
| t12 | 验证 |
如上图，发布过程总计使用12个单位时间，其中有一半时间相关业务同学在standby，等待下游依赖完成发布。
整个过程是串行进行的，A必须等B发布完验证完再发，B必须等C发布完验证完再发
发布过程中没有灵活的流量控制能力，最小的流量灰度比例是1/M(M=应用集群节点数)，当M较小时，灰度风险较大
2.2 蓝绿发布
通过将A、B、C应用集群拆分为蓝、绿两个子集群，发布时先对一个子集群进行摘流，然后并行发布、并行小流量验证。
2.2.1 集群拆分(发布前置动作)
此时，蓝、绿子集群各自承担拆分之前集群总流量的一半。
同一应用蓝、绿集群上的接受的请求量相等
使用蓝绿发布能力的前置工作，每个应用只需要操作一次
2.2.2 蓝集群(左侧)摘流(发布动作)
蓝集群(左侧)摘流后，流量全部由绿集群(右侧)承接。此时，蓝集群(左侧)内应用进程可以无损停机、更新代码、启动。
2.2.3 蓝集群(左侧)引流(发布动作)
发布过程中，蓝、绿节点间流量不会互相窜(对比上图，蓝绿集群间斜向箭头没有了)
蓝集群(左侧)代码更新后，可通过控制面板，梯度的将流量引入更新代码后的蓝集群(左侧)，利用小流量在蓝集群(左侧)同时验证新代码逻辑的可用性、老代码逻辑的兼容性，验证过程中有异常情况可以随时对蓝集群(左侧)摘流止血。
蓝集群(左侧)验证无误后，对绿集群(右侧)采用同样的步骤，完成绿集群(右侧)摘流、无损停机、更新代码、启动、小流量验证。
2.2.4 发布完成(发布动作)
等最后发布验证完成后，蓝、绿集群都替换了代码并各自承接50%的流量。
2.2.5 整体发布时序
| 时间\应用 | A应用 | B应用 | C应用 |
|---|---|---|---|
| t1 | 蓝集群摘流 | 蓝集群摘流 | 蓝集群摘流 |
| t2 | 蓝集群发布新代码 | 蓝集群发布新代码 | 蓝集群发布新代码 |
| t3 | 蓝集群小流量验证 | 蓝集群小流量验证 | 蓝集群小流量验证 |
| t4 | 蓝集群大流量验证 | 蓝集群大流量验证 | 蓝集群大流量验证 |
| t5 | 绿集群摘流 | 绿集群摘流 | 绿集群摘流 |
| t6 | 绿集群发布新代码 | 绿集群发布新代码 | 绿集群发布新代码 |
| t7 | 绿集群小流量验证 | 绿集群小流量验证 | 绿集群小流量验证 |
| t8 | 绿集群大流量验证 | 绿集群大流量验证 | 绿集群大流量验证 |
| t9 | 发布完成，集群流量均分 | 发布完成，集群流量均分 | 发布完成，集群流量均分 |
| t10 | |||
| t11 | |||
| t12 |
如上图，发布过程总计使用9个单位时间，同比既有发布模式减少3个单位时间，同时发布的应用越多，提效越明显。摘流、发布新代码、引流、验证等主要步骤都是多应用并行进行
整个发布过程是以蓝、绿集群维度并行调度、实施的，通过批量统一摘流，解除了批次依赖。
发布过程中有灵活的流量控制能力，可以按1%、5%等阶梯流量验证应用。
上述发布流程，可以同时并存若干个，摘流、引流动作互不影响 (多发布通道)
3. 总结
通过蓝绿发布，一方面让服务实现了无损更新代码，另一方面可以让存在上下游依赖关系的服务可以同时并行发布、并行验证；同时解决了效率和稳定性的问题。