如何发布

蓝绿发布

蓝绿部署,Blue-Green Deployment,蓝/绿部署是一种部署策略,您可以在其中创建两个独立但相同的环境。一个环境(蓝色)正在运行当前的应用程序版本,一个环境(绿色)正在运行新的应用程序版本。如果部署失败,使用蓝/绿部署策略可通过简化回滚过程来提高应用程序可用性并降低部署风险。在绿色环境上完成测试后,将实时应用程序流量定向到绿色环境,而弃用蓝色环境。 broadcasting

蓝绿色的部署还为您提供了一种快速回滚的方法 - 如果出现任何问题,您将路由器切换回蓝色环境。在绿色环境实时时,仍然存在处理错过交易的问题,但是根据您的设计,您可能能够以使两种环境的交易将交易送达,以使蓝色环境作为绿色现场时的备份。或者,您可能能够在剪切之前将应用程序放在只读模式下,在仅阅读模式下运行一段时间,然后将其切换为读取版模式。这可能足以解决许多出色的问题。

这两个环境需要不同,但尽可能相同。在某些情况下,它们可能是不同的硬件,或者它们可以是在相同(或不同)硬件上运行的不同虚拟机。它们也可以是单个操作环境,该环境将两个切片的单独的IP地址分配到单独的区域中。

一旦将绿色环境生存并对它的稳定性感到满意,然后将蓝色环境用作登台环境,用于下一次部署的最终测试步骤。当您准备好下一个版本时,您以与早期从蓝色到绿色相同的方式从绿色转换为蓝色。这样一来,绿色和蓝色环境都定期在现场,以前的版本(用于回滚)和下一个版本之间循环。

基本的想法是要有两个易于切换的环境可以切换,其中有很多方法可以改变细节。一个项目通过弹跳Web服务器而不是在路由器上工作来进行切换。另一个变体是使用相同的数据库,使Web和域层的蓝绿色开关。

数据库通常可能是一个挑战,尤其是当您需要更改schema以支持该软件的新版本时。诀窍是将schema更改的部署与应用程序升级分开。因此,首先数据库重构更改schema以支持应用程序的新版本和旧版本,部署该架构,检查所有内容都可以正常工作,以便您有回滚点,然后部署应用程序的新版本。 (当升级已卧床不起时,请删除对旧版本的数据库支持。)

优缺点

  • 发布简单
  • 硬件数量翻倍
  • 快速回退

灰度发布/金丝雀发布

金丝雀发布,CanaryRelease,是一种降低在生产中引入新软件版本的风险的技术,方法是在将更改推广到整个基础架构并使其可供所有人使用之前,缓慢地将更改推广到一小部分用户。 broadcasting 首先将软件的新版本部署到基础架构的子集,没有用户被路由到该子集。

随着您对新版本的信心增强,您可以开始将其发布到基础架构中的更多服务器并将更多用户路由到它。推出新版本的一个好做法是使用PhoenixServers重新调整现有基础架构的用途,或者使用ImmutableServers配置新的基础架构并停用旧的基础架构。 broadcasting

Canary 版本是ParallelChange的一个应用程序,迁移阶段一直持续到所有用户都被路由到新版本。届时,您可以停用旧的基础设施。如果您发现新版本有任何问题,回滚策略只是将用户重新路由回旧版本,直到您解决了问题。 broadcasting

使用金丝雀版本的一个好处是能够在生产环境中对新版本进行容量测试,如果发现问题,可以采用安全的回滚策略。通过缓慢增加负载,您可以监控和捕获有关新版本如何影响生产环境的指标。这是创建完全独立的容量测试环境的另一种方法,因为该环境将尽可能地类似于生产环境。

在大型分布式场景中,不是使用路由器来决定哪些用户将被重定向到新版本,而是使用不同的分区策略也很常见。例如:如果您有地域分布的用户,您可以先将新版本推出到某个地区或特定位置;如果你有多个品牌,你可以先推广到一个品牌,等等。

Facebook 选择使用多个金丝雀的策略,第一个只对其内部员工可见,并且所有的FeatureToggles都打开,这样他们就可以检测新的问题特征早. broadcasting

由于技术实现的相似性,Canary 版本可以用作实现 A/B 测试的一种方式。但是,最好避免将这两个问题混为一谈:虽然金丝雀版本是检测问题和回归的好方法,但 A/B 测试是一种使用变体实现来测试假设的方法。如果您使用 canary [2]监控业务指标以检测回归,那么也将其用于 A/B 测试可能会干扰结果。在更实际的情况下,收集足够的数据以证明 A/B 测试的统计意义可能需要几天时间,而您可能希望在几分钟或几小时内完成金丝雀部署。

使用金丝雀版本的一个缺点是您必须一次管理软件的多个版本。您甚至可以决定同时在生产中运行两个以上的版本,但是最好将并发版本的数量保持在最低限度。

另一个很难使用金丝雀版本的场景是当您分发安装在用户计算机或移动设备中的软件时。在这种情况下,您无法控制何时升级到新版本。如果分布式软件与后端通信,您可以使用ParallelChange来支持这两个版本并监控正在使用的客户端版本。一旦使用量下降到一定水平,您就可以收缩后端以仅支持新版本。

在进行金丝雀发布时,管理数据库更改也需要注意。同样,使用ParallelChange是一种缓解此问题的技术。它允许数据库在推出阶段支持应用程序的两个版本。

参考文献

  1. BlueGreenDeployment – Martin Fowler
  2. CanaryRelease – Danilo Sato
  3. 灰度(金丝雀)发布、蓝绿部署、滚动发布 – 玄明Hanko


blog comments powered by Disqus
—  原创作品许可 — 署名-非商业性使用-禁止演绎 3.0 未本地化版本 — CC BY-NC-ND 3.0   —