一些历史约翰·斯科特·霍尔丹(JohnScottHaldane)在1895年提出，由于小型温血动物的呼吸交换速度比人类快，因此矿井中的一氧化碳等有毒气体或甲烷等窒息性气体会首先影响它们。例如，在相同浓度的一氧化碳下，老鼠会在几分钟内受到一氧化碳的影响，而人类则需要20倍的时间才会受到影响。于是在1896年左右，老鼠被用作地下有毒气体的警示物种。一段时间后，发现金丝雀对毒气更加敏感。从1900年开始，有记载表明，一些矿山开始使用金丝雀作为井下有毒气体的预警物种。后来，为了重复利用金丝雀，人们发明了一种专门用来检测金丝雀气体的笼子。笼内可主动充氧，前部有通风孔，可通过密闭窗启闭。当需要金丝雀预警时，打开排气孔。如果笼子里的金丝雀被充气，关闭通风窗并用氧气填充笼子。如果这只金丝雀没有中毒，它还有可能起死回生。资料来源：https://en.wikipedia.org/wiki/Domestic_canary#/media/File:Revival_cage.jpg由于科技的不断发展，有毒气体检测器相继问世。这种用生命来探测的方式，逐渐退出了历史舞台。直到1986年，英国和美国才完全停止使用金丝雀作为预警生物。金丝雀部署，这种部署方式的目标和逻辑很像用金丝雀做预警（通过切换风口/流来控制危害和恢复能力），我猜大家可能也想纪念一下这20只牺牲的金鸟对于世纪的矿工来说，这种方法被命名为金丝雀。了解了名称的由来，让我们开始了解金丝雀部署实际上是什么样的。金丝雀部署的基本定义是先将更改发布给一小部分用户进行测试，然后再发布到整个服务集群并让所有人都可以使用。并在测试过程中，持续观察被测服务各个维度的状态，验证新版本的健壮性、可用性、稳定性等。当验证结果达到预期目标后，可以逐步将新版本部署到更多的服务器上，让更多的用户使用。优点(1)零下线时间，回滚速度快：经过一系列相关验证和测试，如果认为新版本的软件不合适，很容易回滚，控制影响范围。(2)真实场景测试：由于新版本直接部署到生产环境进行测试，因此可以通过真实流量来验证新版本。当然，需要限制流量和用户来控制验证的范围和影响。(3)更低的基础设施成本：因为金丝雀部署策略是通过一定的规则，根据规则，将请求按要求（例如：用户名、地区、年龄、随机等）进行分流或路由，所以只需要少量额外的基础设施就可以达到验证的效果。相比蓝绿部署策略，需要准备与生产环境同一套基础设施，部署成本显然会高很多。灵活按需验证相关版本和功能的正确性。根据不同的特征和标识，可以对请求的流量进行多维度的划分和路由，实现不同特征在不同粒度上的灵活验证。它不是灵丹妙药，虽然金丝雀部署可以为大家的部署提供强有力的支持和帮助。但是，软件工程中没有灵丹妙药。金丝雀部署在很多场景下也需要慎用：严格不允许出错的系统，例如：医疗系统、消防系统等，需要部署的数据结构不能向下兼容当前版本数据结构。虽然阿里云的MDS可以提供??分流影子数据库的能力。但是，如果官方用户使用的话，还是会影响实际的数据和行为体验。因此，仅限于测试人员或内部用户体验使用，才能发挥他的能力。非自动化金丝雀部署既耗时又容易出错。因此，我们应该尽可能以自动化的方式使用它，而不是手动维护导流策略和逻辑。以及很多其他对生产环境有严格要求的场景，不推荐使用。接下来，让我们看看一些与细节无关的讨论。金丝雀发布还是金丝雀部署？在交流和口语中，人们习惯于混合发布和部署。经常看到将蓝绿部署、灰度发布（比金丝雀更愿意用灰度）、滚动发布等名词列在一起，表示都是不同的版本发布方式。现在让我们开始咀嚼文字。发布：[issue;release;deliver;distribute]公告，发布例句：向全国发布消息部署：1.[disposition;deployment]：处理；烹饪例句：火炮的部署已经在这张地图上标出2.[arrange;arrangement]layout]:arrangement例句:deploymentplan根据上面两个词典的定义，我是这样理解release和deployment的：release广义上是指通过报纸、书籍、互联网或公开演讲等。是以演讲、演讲等形式公开信息，并向外界传递信息的过程。放在电脑的范畴里，就是把一个特定的软件放在一些大家可以接触到的地方，被动的让大家更新或者同步。例如：我打包发布了某个版本的软件。部署泛指人力、计划、任务等的安排或执行。放在计算机的范畴内，就是将特定的软件安装或更新到相应的环境中，从而为用户提供服务。比如：我已经把新版本部署到测试环境了，你可以测试一下。根据上面的解释，我觉得还是用CanaryDeployment比较准确。与A/B测试的关系刚开始了解金丝雀部署时，发现很多地方混淆了A/B测试和金丝雀部署，甚至直接把两者当成一回事。其实深入了解之后，你会发现它们之前确实有关联，但还没有达到可以等同的程度。相同点它们之间的网络流量处理逻辑非常相似，都是由流量的不同特性，以及为流量服务的版本决定的。金丝雀部署可以作为实施A/B测试的技术基础的一部分；但是，不要将它们混为一谈。区别在于两者的目的完全不同，金丝雀部署是用来检测问题和回归功能，A/B测试是用来测试业务设计假设的方法。从两者的目标出发，他们的测试和观察的方法是不同的。金丝雀部署通常使用技术端观察工具（APM、日志监控等）。技术/开发人员观察需要部署的新版本服务。当观察到的结果符合预期时，技术人员可以进一步进行。否则，需要先解决问题，再部署观察，直到可以达到预期，再进行下一步。如果我们用同样的方法和工具去观察业务，就无法得到准确的结果。甚至观察者的功能也不同。一般来说，A/B测试的观察部分需要预观察数据采集埋点。然后，对采集到的业务数据进行整理统计，最终得出相关的数据分析结果和统计结果，提供给业务人员分析判断新的业务。最后，在时间更敏感的基础上，业务人员可能需要几天时间才能收集足够的数据来证明A/B测试的重要性，而技术人员则希望金丝雀部署在几分钟或几小时内完成。说了这么多与实现无关的话题，我们来看看金丝雀部署的实现方式。实现结构化金丝雀部署的要点如下：网络流量分发分发策略管理多应用分发传输策略数据兼容性处理从上图中的要点来看，通过下图我们可以更清楚地理解：让我们从流程下面开始吧，看看金丝雀部署的具体执行流程是怎样的。具体过程从流程开始，便于了解金丝雀部署在不同阶段的特点和能力。正常阶段：当前环境中只有1-n个经过验证的版本，为所有用户提供服务验证阶段：当前环境中有2到n个版本，其中一个已经通过验证，为大部分用户提供相对稳定的服务，其余1到n-1个版本为可验证版本，为特定用户（某些场景随机选择）提供相对不稳定的服务。同时，持续观察需要验证版本的运行状态，以确定版本是否需要部署或进行其他处理。部署阶段：待验证版本验证通过后，将待验证版本部署到规划的服务集群中。如需进一步测试，则返回验证期进行验证，直至需要验证的版本部署比例达到最终要求。滚动部署常用于部署。这里提到的状态流概览实现方式主要是服务端的实现方式。我根据不同的实现方式分为以下几种：基础设施实现（IaaS）：例如通过阿里云MDS工具实现平台（PaaS）：通过K8SIngress组件或者Istio通过Nginx等中间件：直接控制流量转发通过Nginx中的脚本规则...因为金丝雀部署本身的实现细节与应用场景紧密耦合。具体实现方法这里不展开。在使用过程中，要注意文中提到的它的特点和注意事项（不是灵丹妙药），以及部署的具体执行流程和结构。我在这里做的更多是展开讨论，希望大家可以有更多关于金丝雀部署的精彩内容和想法一起讨论。最后来源：http://coachellavalleyweekly.com/canary-in-a-coal-mine/20世纪的一天，在一个黑暗而狭窄的矿井中。戴着矿灯的矿工一手拿着笼子，一手撑着脚往前爬。汗水沾满了黑色的粉末，从他的脸上滴落下来。美丽的小鸟在摇摇晃晃的笼子里挣扎着保持着平衡，在侥幸逃脱后迎接它的是阳光还是令人窒息的毒药。
