Open fayeah opened 4 years ago
没有搜到Martin Fowler这篇关于金丝雀部署（Canary Release）的翻译，我斗胆试着译一下，若以后有人想迅速了解金丝雀部署又不喜欢英文，我也算是给技术界做过知识分享的人了。
原文地址：Canary Release by Martin Fowler
金丝雀发布是一项关于软件新版本发布的技术，先将新版本发布给小部分用户，逐渐发布整体架构并且将新版本发布给所有用户，以此方式来降低发布的风险。
与蓝绿发布（BlueGreenDeployment）相似，先将要发布的新版本部署到基础架构的子集中，此时，这个子集没有用户使用。
当你觉得新版本没有什么问题，就可以将新版本路由给部分用户。对于哪些用户能看到新版本有几种策略：比较简单的策略是使用随机样本；一些公司在对外发布之前选择内部用户和员工来先使用新版本；另外一个更为复杂的方法是通过用户信息和统计数据来选择测试用户。
当你对新版本获得更多信心的时候，就可以发布到更多的服务并路由给更多的用户了。一个好的实践是使用PhoenixServers通过修改已存的架构来部署新版本，或者使用 ImmutableServers来提供一个新的架构并且关掉旧的架构。
金丝雀发布是一个ParallelChange的应用，集成阶段会持续到所有用户全部都切到了新版本。那个时候，就可以关掉旧的架构。一旦新版本出现了什么问题，只需要使用回滚策略将用户切回到旧版本，直到新版本的问题修复。
金丝雀部署的好处之一是能够在生产环境下进行新版本的容错测试，并且在发现任何问题的时候都能安全地回滚。缓慢提高加载量，你能够监控并捕获新版本在生产环境产生的数据变化。这是一个创建一整套独立容错测试环境的可选方案，因为该环境尽可能地与生产环境保持一致。
尽管这个技术的名字还不为人熟知，实际上金丝雀部署的的实践已经被采用了一段时间了。有时候也被称为phased rollout或incremental rollout。
在比较大的、分布式的场景中，不是使用路由的方式来决定哪些用户切到新版本，而比较常见的是使用不同的划分策略。比如：如果有地理上划分的用户，你可以将某个地区或者某个具体地理位置的用户切换到新版本；如果有多个品牌可以先切到某个品牌的用户，等等。脸书采用多个金丝雀的策略，先是让内部员工看到新版本，同时把FeatureToggles打开，以此来尽早地监测到新版本的问题。
金丝雀部署也是A/B测试的一种方式，因为他们在技术实现上很相似。然而，应该尽量避免结合使用，原因有两个：金丝雀部署是监测问题和回归的比较好的方式，而A/B测试利用变量来检验假设。如果在金丝雀部署中通过监测回归来监控业务数据，这可能会干扰A/B测试的结果。更值得注意的是，A/B测试需要通过几天的时间来收集数据，从而表现统计的价值，而金丝雀部署的完成只需要几分钟或几个小时即可。
金丝雀部署有一个缺点就是必须一次性管理软件的多个版本。甚至有时候需要同时在生产环境上同时运行两个以上的版本，但最好保证并发的版本在最小的数量。
另外一个场景是当你发布的软件需要安装到用户的电脑或者手机设备上的时候，使用金丝雀部署是比较困难的。这种情况下，对升级新版本的控制力就会减弱。如果发布的软件需要跟后端交互，你可以使用ParallelChange来支持版本的切换以及监控用户正在使用哪个版本。一旦使用旧版本的数量降低到某一个程度，就可以指定后端只支持新版本。
使用金丝雀部署也需要注意数据库变化的管理。ParallelChange同样可以缓解数据库的问题。在推出新版本的阶段它允许数据库支持应用的新旧两个版本。
没有搜到Martin Fowler这篇关于金丝雀部署（Canary Release）的翻译，我斗胆试着译一下，若以后有人想迅速了解金丝雀部署又不喜欢英文，我也算是给技术界做过知识分享的人了。
原文地址：Canary Release by Martin Fowler
金丝雀发布是一项关于软件新版本发布的技术，先将新版本发布给小部分用户，逐渐发布整体架构并且将新版本发布给所有用户，以此方式来降低发布的风险。
与蓝绿发布（BlueGreenDeployment）相似，先将要发布的新版本部署到基础架构的子集中，此时，这个子集没有用户使用。
当你觉得新版本没有什么问题，就可以将新版本路由给部分用户。对于哪些用户能看到新版本有几种策略：比较简单的策略是使用随机样本；一些公司在对外发布之前选择内部用户和员工来先使用新版本；另外一个更为复杂的方法是通过用户信息和统计数据来选择测试用户。
当你对新版本获得更多信心的时候，就可以发布到更多的服务并路由给更多的用户了。一个好的实践是使用PhoenixServers通过修改已存的架构来部署新版本，或者使用 ImmutableServers来提供一个新的架构并且关掉旧的架构。
金丝雀发布是一个ParallelChange的应用，集成阶段会持续到所有用户全部都切到了新版本。那个时候，就可以关掉旧的架构。一旦新版本出现了什么问题，只需要使用回滚策略将用户切回到旧版本，直到新版本的问题修复。
金丝雀部署的好处之一是能够在生产环境下进行新版本的容错测试，并且在发现任何问题的时候都能安全地回滚。缓慢提高加载量，你能够监控并捕获新版本在生产环境产生的数据变化。这是一个创建一整套独立容错测试环境的可选方案，因为该环境尽可能地与生产环境保持一致。
尽管这个技术的名字还不为人熟知，实际上金丝雀部署的的实践已经被采用了一段时间了。有时候也被称为phased rollout或incremental rollout。
在比较大的、分布式的场景中，不是使用路由的方式来决定哪些用户切到新版本，而比较常见的是使用不同的划分策略。比如：如果有地理上划分的用户，你可以将某个地区或者某个具体地理位置的用户切换到新版本；如果有多个品牌可以先切到某个品牌的用户，等等。脸书采用多个金丝雀的策略，先是让内部员工看到新版本，同时把FeatureToggles打开，以此来尽早地监测到新版本的问题。
金丝雀部署也是A/B测试的一种方式，因为他们在技术实现上很相似。然而，应该尽量避免结合使用，原因有两个：金丝雀部署是监测问题和回归的比较好的方式，而A/B测试利用变量来检验假设。如果在金丝雀部署中通过监测回归来监控业务数据，这可能会干扰A/B测试的结果。更值得注意的是，A/B测试需要通过几天的时间来收集数据，从而表现统计的价值，而金丝雀部署的完成只需要几分钟或几个小时即可。
金丝雀部署有一个缺点就是必须一次性管理软件的多个版本。甚至有时候需要同时在生产环境上同时运行两个以上的版本，但最好保证并发的版本在最小的数量。
另外一个场景是当你发布的软件需要安装到用户的电脑或者手机设备上的时候，使用金丝雀部署是比较困难的。这种情况下，对升级新版本的控制力就会减弱。如果发布的软件需要跟后端交互，你可以使用ParallelChange来支持版本的切换以及监控用户正在使用哪个版本。一旦使用旧版本的数量降低到某一个程度，就可以指定后端只支持新版本。
使用金丝雀部署也需要注意数据库变化的管理。ParallelChange同样可以缓解数据库的问题。在推出新版本的阶段它允许数据库支持应用的新旧两个版本。