全链路灰度实现

降低发布影响面：就算出问题，也只会影响部分测试用户，从而可以提前发现新版本中的 bug，然后提前修复，避免影响真实用户；

提升用户体验：除了能发现 bug，还能很好的收集新版本的用户使用反馈，从而提前调整系统，提升用户体验，也能给后续的产品演进带来参考价值。

可以做到不停机的热迁移，版本回滚便捷（速度快）

二、灰度发布几种类型

灰度发布的主要分类：

金丝雀发布

滚动发布

蓝绿发布

1.金丝雀部署

金丝雀部署又称灰度部署（或者，灰度发布），是指在黑与白之间，能够平滑过渡的一种发布方式。

金丝雀的名称来源于「矿井中的金丝雀」，早在 17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感，空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。

我们来看一下金丝雀部署的步骤：

准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件

从负载均衡列表中移除掉“金丝雀”服务器

升级“金丝雀”应用（切断原有流量并进行部署）

对原有应用进行自动化测试

将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）

如果“金丝雀”在线使用测试成功，升级剩余的其他服务器（否则就回滚）

金丝雀部署比较典型的例子，就是我们在使用某个应用的时候，该应用邀请我们进行“内测”或者“新版本体验”，如果我们同意了，那么我们就成了金丝雀。

优点：

用户体验影响小，金丝雀发布过程出现问题只影响少量用户

缺点：

当升级全部剩余实例时，如果流量过多，可能会导致服务中断。

2.滚动部署

滚动部署，同样是一种可以保证系统在不间断提供服务的情况下上线的部署方式。和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。

如何做到细粒度平滑升级版本呢？滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。比如在一个 12 节点的集群中，我们每次升级 4 个节点，并将升级后的节点重新投入使用，周而复始，直到集群中所有的节点都更新为新版本。

滚动部署的步骤：

滚动发布则是在金丝雀发布的基础上进行的改进和优化，第一次也是使用金丝雀发布，后续则使用多批次的形式发布剩余实例，每次批次之间会进行观察，如果有问题，再进行回滚。

优点：

只需要维护一个集群，成本低

用户体验影响小，体验较平滑

缺点：

上线过程中，两个版本同时对外服务，不易定位问题，且容易造成数据错乱；

升级和回滚以节点为粒度，操作相对复杂。（举个例子，在某一次发布中，我们需要更新 100 个实例，每次更新 10 个实例，每次部署需要 5 分钟。当滚动发布到第 80 个实例时，发现了问题，需要回滚。这时，我们估计就要疯了。）

3.蓝绿部署

蓝绿部署，是一种可以保证系统在不间断提供服务的情况下上线的部署方式。

如何保证系统不间断提供服务呢？那就是同时部署两个集群，但仅对外提供一个集群的服务，当需要升级时，切换集群进行升级。蓝绿部署无需停机，并且风险较小。其大致步骤为：

部署集群 1 的应用（初始状态），将所有外部请求的流量都打到这个集群上

部署集群 2 的应用，集群 2 的代码与集群 1 不同，如新功能或者 Bug 修复等

将流量从集群 1 切换到集群 2

如集群 2 测试正常，就删除集群 1 正在使用的资源，使用集群 2 对外提供服务

优点：

1.同一时间对外服务的只有一个版本，容易定位问题；

2.升级和回滚以集群为粒度，操作相对简单；

缺点：

1.需要维护两个集群，成本高；

2.切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；

三、选型

介绍：

方式	零停机	生产流量测试	针对特定用户	机器资源成本	回滚时长	负面影响	实现复杂度
全量发布	❌	❌	❌	低	慢	高	低
蓝绿发布	✅	❌	❌	高（双倍）	快	中	中
滚动发布	✅	✅	✅	中（按需）	慢	低	高
金丝雀发布	✅	✅	✅	中（按需）	快	低	中
全链路发布	✅	✅	✅	中（按需）	快	低	高

最低0.47元/天解锁文章