金丝雀发布的本质

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

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

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

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

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

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

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

回到技术领域。金丝雀发布就是你已经将程序部署到生产环境了，然后根据流量比例、用户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平台，大概率是因为它更标准，更容易实现。而大多企业的金丝雀系统可能与企业内部系统耦合严重，无法开源。

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

（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

用chrome的凳拦金丝雀版本啦,这个是频繁更新的.至於那个chromium是不会从官网自动更新的,我指的那个金丝雀版是测试版的beta版,相信会合你的意,如果实在百度不到这个金丝雀版的下载程序,你粗铅可以给俺发百度消息告知俺'你的电邮'.俺有留着这个程序在俺的岩粗好U盤里,俺可以用电邮信件的方式分享给你)

---