发布策略 | 阿里巴巴DevOps实践指南

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。

DevOps 追求更短的迭代周期、更高频的发布。但发布的次数越多，引入故障的可能性就越大。更多的故障将会降低服务的可用性，进而影响到客户体验。所以，为了保证服务质量，守好发布这个最后一道关，阿里逐步发展出了适应 DevOps 要求的发布策略。

在开始讲述阿里的实践之前，我们先简单介绍下几种常见发布策略, 以及它们适用的场景和优缺点。

常见发布策略

停机发布

停机发布会在发布以前关闭服务，停止用户访问，然后一次性的升级所有服务。这种发布策略的发布频率往往比较低，且需要在发布之前做好充足的测试。

停机发布的特点有：

• 所有需要升级的组件被整合到一次发布中

• 一个项目中的大部分应用都会被更新

• 发布之前的研发流程和测试流程往往需要花很长的时间

• 发布时如果出现问题, 修复和回滚的成本很高

• 完成一次停机发布, 需要花费很久的时间, 且需要很多团队在一起才能完成

• 往往需要客户端和服务器端同步升级
  停机发布并不适合互联网公司，因为两次发布的间隔很久，从功能特性提出到进入市场的时间太长，对市场反应不敏感，会在充分竞争的市场里处于下风。每次发布因为要停机，也会带来经济损失。

优势：

简单, 不太需要考虑新旧版本共存时的兼容性问题

劣势：

发布过程中，服务不可用
只能在业务低峰期 (往往是夜间)发布，并且需要很多团队在一起工作
出现故障后很难回滚

适合场景：

1. 开发测试环境

2. 非关键应用，用户影响面小

3. 兼容性比较难管控的场景

金丝雀发布

金丝雀发布这个术语源自 20 世纪初期，当时英国的煤矿工人在下井采矿之前，会把笼养的金丝雀携带到矿井中，如果矿井中一氧化碳等有毒气体的浓度过高，在影响矿工之前，金丝雀相比人类表现的更加敏感快速，金丝雀中毒之后，煤矿工人就知道该立刻撤离。金丝雀发布是在将整个软件的新版本发布给所有用户之前，先发布给部分用户，用真实的客户流量来测试，以保证软件不会出现严重问题，降低发布风险。

在实践中，金丝雀发布一般会先发布到一个小比例的机器，比如 2% 的服务器做流量验证，然后从中快速获得反馈，根据反馈决定是扩大发布还是回滚。金丝雀发布通常会结合监控系统，