金丝雀发布的本质

金丝雀发布在国内也经常被叫做灰度发布。下文将使用”金丝雀发布“这一术语。

金丝雀发布是发布模式的一种。“发布”是什么意思？发布：即宣布，发表。有向外公开的意思。

说到“发布”，就不得不说“部署”。不少人将“发布”与“部署”两个概念混淆。

“部署”又是什么意思？在软件工程领域，“部署”指的是将（编译）打包好的程序发送到目标服务器上，并启动执行。

就是说，部署了，并不一定代表着向用户发布。

如果把软件产品比喻成一舞台剧。部署是将舞台提前布置好，但是幕布是拉上的。而发布则是把观众放进剧场，然后拉开幕布。注意：只有真正“拉开幕布”，才称为发布。

那金丝雀发布又是什么？接着刚刚说的比喻，指的是你并不是一次性将所有的观众都放进剧场。只是有条件的让一部分人进场并拉开幕布。你可以通过这些观众对于舞台剧的评价对舞台剧进行调整改进。最后，再选择合适的时机向所有的人开放消费。

回到技术领域。金丝雀发布就是你已经将程序部署到生产环境了，然后根据流量比例、用户ID、用户地域、用户类型等不同维度的条件，允许用户使用部署到生产环境上的程序上的功能。这个过程中，你可以观察这些”特权“用户的数据，以判断你是否需要对功能进行改进。当数据足以支撑全量发布时，就可以进行全量发布。

这就是我们文章开头强调的：金丝雀发布是发布模式的一种。以下是根据流量比例进行金丝雀发布的图示（来自flagger.app）:

Flagger是一种基于K8s的发布控制器。能以较低的成本实现金丝雀发布。本例中，它启动一个V2版本的程序的实例，并”放行“5%的用户请求进入V2版本的实例。

因为软件产品一次性全量发布后，你并不能确保它一定受大众喜爱，所以，一步步的试探用户的喜好的软件产品发布策略成为必然选择。

比起一次性全量发布，金丝雀是一种演进式的发布模式，也可以说是一种业务级别的决策。

说到”目的“，就不得不说与金丝雀发布容易混淆的”蓝绿部署“。

蓝绿部署也是一种发布模式。如下图。它的部署方式与金丝雀发布的部署方式几乎一样。

蓝绿部署与金丝雀发布之间存在两个区别。主要区别是”目的“。蓝绿部署的发布模式的目的是更安全的部署，金丝雀发布的目的是演进式的发布。

次要区别是决策维度的不同。蓝绿部署是技术维度的决策，而金丝雀是业务维度的决策。

如下图展示的是蓝绿部署的决策过程。如果V2版本的实例在生产环境经过多种验证方式验证过，即可把流量全部切到V2版本。在验证期间会保留V1实例，以保证可以随时回滚。

另，至于为什么是叫蓝绿部署（Blue-Green Deployments）而不是蓝绿发布。个人认为是因为从一开始蓝绿部署的出发点是零停机（Zero Downtime），而不是演进式的发布。当然，从名称上也体现了在蓝绿部署和金丝雀发布在”决策维度“上的区别。

参考Martin Fowler关于蓝绿部署的文章： https://martinfowler.com/bliki/BlueGreenDeployment.html

容易与金丝雀发布混淆的，还有”滚动更新“。它是一种将软件程序从一个版本平滑的升级到另一个的版本部署技术。如下图。属于技术决策。与业务无关。与金丝雀发布不是同一个维度的东西。

动态图来自： https://www.bluematador.com/blog/kubernetes-deployments-rolling-update-configuration

在厘清与金丝雀相关的各种概念定义之后，我们从设计者的角度思考金丝雀发布：如果让你设计一个金丝雀发布系统或者平台，你该如何实现？

笔者认为它至少要实现三个接口：

这三个接口与具体实现应该是无关的。比如你可以通过Prometheus实现指标的收集接口，也可以通过AWS的CloudWatch。

同时，金丝雀发布系统还需要一些用户体验性相关的功能，比如出现回滚时进行通知、滚动更新前进行人工审批、滚动更新的步骤大小等等。

金丝雀发布系统所需的接口后，我们发现，由于Service Mesh技术的兴起，让金丝雀发布的实现变得容易了很多。

因为Service Mesh技术天生就支持以上三个接口。所以，行业里一下就出现一些轻量级的发布系统，比如Argo Rollouts和Flagger。我们可以通过以下表格进行对比：

Flagger的三个接口的实现更丰富，几乎完胜Argo Rollouts。Argo Rollouts除了UI，几乎没有优势。

虽说金丝雀的好处是看得见的，但是并不代表，你的每一次发布都能使用它。我们需要清楚的认识到，执行金丝雀发布的过程中，程序存在一个中间状态：就是两个版本同时存在，有时甚至是多个版本。在生产环境，如果你的程序无法同时运行两个版本，你就不能采用金丝雀发布。这个风险需要开发在开发过程就确定的。

所以，我们认为采用金丝雀发布的前提是：开发人员开发出来的程序必须有同时运行多个版本的能力。

而这一能力，对程序员本身的能力也有要求。比如它要求程序员在设计接口和DB schema时考虑向前兼容。在程序员能力不足时，也无法采用金丝雀发布。

金丝雀发布的概念的理解程度，决定了团队是否能采用金丝雀发布，也决定了金丝雀发布系统的设计。

开源的金丝雀系统倾向于基于标准化的Kubernates平台，大概率是因为它更标准，更容易实现。而大多企业的金丝雀系统可能与企业内部系统耦合严重，无法开源。

作为技术人员，肯定听说过 灰度发布 这个技术术语，它指的是发布版本 (黑) 与线上版本 (白) 之间，能够平滑过渡的一种发布方式。

一般来说，随着一个产品不断地快速迭代开发上线，必然会有一方面要保证线上版本稳定，另一方面又要保证新版本上线的需求，这时候就需要设计一套灰度发布系统，让大部分用户继续使用原来的线上版本，少量用户或内部测试人员使用新版本功能，并且一旦出现问题可以很快的控制影响，如果没有不良的反馈意见，则继续逐步扩大范围，把所有用户都迁移到新版本上面来。

灰度发布可以保证整体业务的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，实现更好的风险控制。

这种发布形式非常实用，包括Google都在使用，并在书中有详细介绍，是不少成长型技术组织和互联网公司的主流发布方式。

金丝雀发布 这个说法其实来自欧美，以前旷工矿工开矿，在下矿洞时面临的一个重要危险就是矿井中的毒气，于是他们想到一个办法来辨别矿井中是否有毒气，矿工们下矿井时随身携带一只金丝雀 (Canary) 。

由于金丝雀对毒气的抵抗能力比人类要弱，在毒气环境下会先挂掉起到预警的作用，这种风险控制背后的原理暗合灰度发布的根本需求，即：

灰度发布，又名金丝雀发布，或者灰度测试，是指在黑与白之间能够平滑过渡的一种发布方式。

在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。

灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。

灰度发布可以从业务，功能，性能，用户体验很多方面使产品得以提升，并平滑上线。

A/B test其实属于灰度当中的一个小小的分支，做产品、运营数据的都必须要懂。这是国际前沿的产品发布和改版方式，而不是依靠主观去进行。

---