蓝绿发布、滚动发布、灰度发布（金丝雀发布）、A/B测试

服务发布方式

在一般情况下，升级服务器端应用，需要将应用源码或程序包上传到服务器，然后停止掉老版本服务，再启动新版本。但是这种简单的发布方式存在两个问题，

（1）在新版本升级过程中，服务是会暂时中断的。

（2）如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

（3）新功能体验不好，版本升级过程中带来的流量有损，造成用户流失。

为了解决这些问题，人们研究出了几种常见的服务发布策略，下面一一介绍。

蓝绿发布

                                                                   蓝绿发布

所谓蓝绿部署，是指同时运行两个版本的应用，

如上图所示，蓝绿发布部署时候需要对服务的新版本进行冗余部署并不停止掉老版本，一般新版本的机器规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进行版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。由于冗余部署的缘故，如果新版本上线后出现严重的程序 BUG，那么我们只需将流量全部切回至旧版本，大大缩短故障恢复的时间。待新版本完成 BUG 修复并重新部署之后，再将旧版本的流量切换到新版本。

蓝绿发布通过使用额外的机器资源来解决服务发布期间的不可用问题，当服务新版本出现故障时，也可以快速将流量切回旧版本。

蓝绿部署的优点：

1、部署结构简单，运维方便；

2、服务升级过程操作简单，周期短。

蓝绿部署的缺点：

1、资源冗余，需要部署两套生产环境；

2、新版本故障影响范围大。

ps：当然，蓝绿发布也可以在系统非繁忙时段进行升级，把现有的集群服务器一分为二，一半升级一半保留并隔离，待到新系统稳定后升级另一半服务器，并解除隔离。从而充分利用现有服务器资源。

滚动发布

滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。

所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。

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

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

灰度发布（金丝雀发布）

                                                                    灰度发布

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。

相比于前两种发布策略，灰度发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。

灰度发布可以基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于 Http Header 和 Cookie。基于 Http Header 方式的例子，例如 User-Agent 的值为 Android 的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。基于 Cookie 方式的例子，Cookie 中通常包含具有业务语义的用户信息，例如VIP可以访问新版本，普通用户用户仍然访问旧版本（或者相反）。

如图，某服务当前版本为 v1，现在新版本 v2 要上线。为确保流量在服务升级过程中平稳无损，采用金丝雀发布方案，逐步将流量从老版本迁移至新版本。

                                                               新老版本迁移

灰度发布期间再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。通过在监控平台观察旧版本与新版本的成功率、RT 对比，当新版本整体服务预期后，即可将所有请求切换到新版本。

灰度发布的优点：

1、可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；

2、发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。

3、需要构建完备的监控平台，用于对比不同版本之间请求状态的差异（做A/B测试）。

灰度发布的缺点：

1、仍然可能存在资源冗余，因为无法准确评估请求容量；

2、如果流量无差别地导向新版本，可能会影响用户的体验；

3、发布周期长。

总结：如下图描述了几种部署方式的演进

                                                                    演进

最佳实践：

在新版本应用发布时，为了服务器不停机升级且影响最小，使用灰度发布策略，

在灰度发布开始时，使用HTTP Header等策略 匹配指定测试人员的流量到新版本上，

然后当新版本内部测试通过后，可以再按百分比、白名单等，将用户流量一点一点导入到新版本中，直到将流量全部导入到新版本上，最后完成升级，

如果期间发现问题，就立即取消升级，将流量切回到老版本。

运用灰度发布，就再也不需要加班到深夜进行停机升级了，在白天就可以放心大胆地、安全地发布新版本^_^。

参考：

https://blog.csdn.net/luo15242208310/article/details/118888496

https://developer.aliyun.com/article/847533