科普：蓝绿部署、金丝雀发布（灰度发布）、A/B测试

so~what

已于 2022-08-31 23:01:12 修改

阅读量4.2k

点赞数 1

分类专栏：未来通信~5G/6G/XG 文章标签：蓝绿部署金丝雀发布（灰度发布）

于 2022-08-31 23:00:37 首次发布

本文链接：https://blog.csdn.net/qfturauyls/article/details/126633689

版权

未来通信~5G/6G/XG 专栏收录该内容

6 篇文章

订阅专栏

蓝绿部署（Blue-green Deployments）

蓝绿部署的目的是减少发布时的中断时间、能够快速撤回发布。

It’s basically a technique for releasing your application in a predictable manner with an goal of reducing any downtime associated with a release. It’s a quick way to prime your app before releasing, and also quickly roll back if you find issues.

蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。

最初，没有任何系统，没有蓝绿之分。

然后，第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分。

后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统之外搭建了一个使用新版本代码的全新系统。这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

蓝色系统不对外提供服务，用来做啥？

用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）

蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统：

切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

蓝绿部署只是上线策略中的一种，它不是可以应对所有情况的万能方案。蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。

BlueGreenDeployment中给出的一张图特别形象：

金丝雀发布（anCanary Releases）

金丝雀发布（Canary）也是一种发布策略，和国内常说的灰度发布是同一类策略。

蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。

譬如说，目标系统是一组无状态的Web服务器，但是数量非常多，假设有一万台。这时候，蓝绿部署就不能用了，因为你不可能申请一万台服务器专门用来部署蓝色系统（在蓝绿部署的定义中，蓝色的系统要能够承接所有访问）。

可以想到的一个方法是：

只准备几台服务器，在上面部署新版本的系统并测试验证。测试通过之后，担心出现意外，还不敢立即更新所有的服务器。先将线上的一万台服务器中的10台更新为最新的系统，然后观察验证。确认没有异常之后，再将剩余的所有服务器更新。这个方法就是金丝雀发布。

实际操作中还可以做更多控制，譬如说给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。

这个控制叫做“流量切分”，既可以用于金丝雀发布，也可以用于后面的A/B测试。

蓝绿部署和金丝雀发布是两种发布策略，都不是万能的。有时候两者都可以使用，有时候只能用其中一种。

上面的例子中可以用金丝雀，不能用蓝绿，那么什么时候可以用蓝绿，不能用金丝雀呢？整个系统只有一台服务器的时候。

金丝雀发布（canary release）也叫灰度发布。

        人们发现金丝雀这种生物对于有毒气体很敏感。因此矿工在下井采矿之前会把金丝雀鸟儿投入或携带到矿井中，如果鸟儿能够从矿井中飞出就表示井下有氧气，矿工就可以安心下井采矿了。

        通过这个故事，我们就可以看出金丝雀部署就是先把新版本试水的一部分就叫金丝雀发布。金丝雀发布可以快速而有效地发现软件新版本存在的问题。

        它的原理就是部署的时候让一小部分用户先试用功能，通过日志监控或者服务器监控，看下新用户的反馈。如果没有严重问题，尽快部署这个新版本，否则快速会退。小代价去试错。