灰度分布的主流方案

伴随着互联网技术的高速发展，产品功能的迭代速度也越来越快，年度、季度发布几乎成为历史，一线互联网公司都支持周度上万次发布。如此高频的发布，如果新版本不够稳定，或者新特性的用户体验不好，对于企业来说可能会带来口碑或经济上的损失。

那么从技术角度如何保障每次发布风险最低、让用户获得更好的体验呢？在持续部署方面通常的做法是新老版本并存，先引入少部分流量到新版本，验证通过后，逐步加大新版本流量的比例，这正是灰度发布要解决的问题。灰度发布的核心能力是可以通过配置流量策略，将用户在同一访问入口的流量导到不同的版本上，一般有如下几种方案。

1、蓝绿发布

在老版本不变的情况下，完全独立部署一套新的版本，但新版本并不加入代理后端。当新版本经过线下验证后，直接将流量全量切换到新版本上，并删除老版本。当新版本有问题时，可快速切换回老版本。

在新老版本都存在时，蓝绿发布切换会非常快，快速切换的代价是要多出一倍的资源，即服务的实例个数是平常运行时的 2 倍。另外，由于流量全部切换，如果新版本有问题，那么所有用户都将会受到影响。即便如此，仍然比发布在同一套资源上重新安装新版本导致用户全部中断要好很多。因此，蓝绿发布适用于对用户体验有一定容忍度、机器资源有富余或者可以按需分配的场景。

2、滚动发布

所谓滚动发布，就是在升级过程中，并不像蓝绿发布那样全量启动所有新版本（V1），而是先启动一台新版本，并停止一台老版本（V2），再启动一台新版本，并停止一台老版本，如此循环，直到全量发布完成。比如有 10 台服务器，滚动发布将会按照先 V1:V2=9:1，然后 V1:V2=8:2,V1:V2=7:3……直至 V1:V2=0:10 的模式执行。

滚动发布虽然解决了蓝绿发布在资源层面浪费 2 倍服务器的问题，但也有相应的弊端。在开始滚动发布后，流量会直接流向已经启动的新版本，而此时新版本的状态是待验证状态，往往需要进行线上回归测试才能确认。在滚动升级期间，整个系统处于一种不稳定状态，如果发现线上问题，也比较难确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力，即控制一部分精确的线上流量进行验证。

3、金丝雀发布

金丝雀发布起源于矿工对矿井的检测。矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度很高。映射到软件工程中，就是当上线新版本应用时，先启动一台新版本的服务器，然后切入少部分流量到新版本，比如 5%的线上流量，此时观察新版本在生产环境的表现，就像把一只金丝雀放到瓦斯井里一样，探测这个新版本在环境中是否可用，先让一小部分用户尝试新版本。在观察到新版本没有异常后再增加切换流量的比例，如 20%、50%、80%，直到 100%全部切换完成。

金丝雀发布是一个渐变、逐步尝试的过程，实际上只有金丝雀发布才可以算作灰度发布。这里把蓝绿发布、滚动发布都称为灰度发布，可能与其他资料的定义不同，但是也不用纠结这些概念名词的划分，抓住问题的本质即可。灰度发布的核心是支持对流量的管理，能否提供灵活的流量策略是判断基础设施灰度发布能力的重要指标。

4、AB 测试

AB 测试是金丝雀发布的一种变形。两者示意图很像，但目的不同。金丝雀发布的核心是在上线前验证新版本是否稳定，而 AB 测试通常用于核心功能的更改与老版本的效果对比，比如更改了推荐搜索的算法，但不确定新算法是否能达到预期，需要和老版本的算法进行收益比较，按一定的目标策略选取一部分用户使用老版本，另一部分用户使用新版本，收集两部分用户的使用反馈，对用户采样后做比较，通过分析数据来决定最终采用哪个版本。