成都创新互联从2013年成立，先为吴堡等服务建站，吴堡等地企业，进行企业商务咨询服务。为吴堡企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

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

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

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

常见发布策略

停机发布

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

停机发布的特点有：

• 所有需要升级的组件被整合到一次发布中
• 一个项目中的大部分应用都会被更新
• 发布之前的研发流程和测试流程往往需要花很长的时间
• 发布时如果出现问题, 修复和回滚的成本很高
• 完成一次停机发布, 需要花费很久的时间, 且需要很多团队在一起才能完成
• 往往需要客户端和服务器端同步升级

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

优势：

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

劣势：

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

适合场景：

1. 开发测试环境
2. 非关键应用，用户影响面小
3. 兼容性比较难管控的场景

金丝雀发布

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

在实践中，金丝雀发布一般会先发布到一个小比例的机器，比如 2% 的服务器做流量验证，然后从中快速获得反馈，根据反馈决定是扩大发布还是回滚。金丝雀发布通常会结合监控系统，通过监控指标，观察金丝雀机器的健康状况。如果金丝雀测试通过，则把剩余的机器全部升级成新版本，否者回滚代码。

优势：

1. 对用户体验影响较小，在金丝雀发布过程中，只有少量用户会受影响
2. 发布安全能够得到保障

劣势：

1. 金丝雀的机器数量比较少, 有一些问题并不能够暴露出来

适用场景：

1. 监控比较完备且与发布系统集成

灰度/滚动发布

灰度发布是金丝雀发布的延伸，是将发布分成不同的阶段/批次，每个阶段/批次的用户数量逐级增加。如果新版本在当前阶段没有发现问题，就再增加用户数量进入下一个阶段，直至扩展到全部用户。

灰度发布可以减小发布风险, 是一种零宕机时间的发布策略。它通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本。整个发布过程会持续比较长的时间, 在这段时间内, 新旧代码共存, 所以在开发过程中, 需要考虑版本之间的兼容性, 新旧代码共存不能影响功能可用性和用户体验。当新版本代码出现问题时, 灰度发布能够比较快的回滚到老版本的代码上。

结合特性开关等技术，灰度发布可以实现更复杂灵活的发布策略。

优势：

1. 用户体验影响比较小, 不需要停机发布
2. 能够控制发布风险

劣势：

1. 发布时间会比较长
2. 需要复杂的发布系统和负载均衡器
3. 需要考虑新旧版本共存时的兼容性

适用场景：

1. 适合可用性较高的生产环境发布

蓝绿发布

蓝绿部署是指有两个完全相同的、互相独立的生产环境，一个叫做“蓝环境”，一个叫做“绿环境”。其中，绿环境是用户正在使用的生产环境。当要部署一个新版本的时候，先把这个新版本部署到蓝环境中，然后在蓝环境中运行冒烟测试，以检查新版本是否正常工作。如果测试通过，发布系统更新路由配置，将用户流量从绿环境导向蓝环境，蓝环境就变成了生产环境。这种切换通常在一秒钟之内就能搞定。如果出了问题，把路由切回到绿环境上，再在蓝环境中调试，找到问题的原因。因此，蓝绿部署可以做到仅仅一次切换，立刻就向所有用户推出新版本，新功能对所有用户立刻生效可见。

优势：

1. 升级切换和回退速度非常快
2. 零停机时间

不足：

1. 一次性的全量切换, 如果发布出现问题, 会对用户产生比较大的影响
2. 需要两倍的机器资源
3. 需要中间件和应用自身支持热备集群的流量切换

适用场景：

1. 机器资源比较富余或者按需分配 (背靠云厂商)

A/B 测试

A/B 测试和灰度发布非常像，可以从发布的目的上进行区分。AB 测试侧重的是根据 A 版本和 B 版本的差异进行决策，最终选择一个版本进行部署。和灰度发布相比，AB 测试更倾向于去决策，和金丝雀发布相比，AB 测试在权重和流量的切换上更灵活。

举个例子，某功能有两个实现版本 A 和 B，通过细粒度的流量控制，把 50% 的用户总是引导到 A 实现上，把剩下的 50% 用户总是引导到 B 实现上，通过比较 A 实现和 B 实现的转化率，最终选择转化率较高的 A 实现作为功能的最终版本。

优势：

1. 快速实验能力
2. 用户体验影响小
3. 可以使用生产环境流量做测试
4. 可以针对某些特定用户做测试

不足：

1. 需要较为复杂的业务流量识别和控制能力
2. 需要考虑较为复杂的新旧版本兼容性问题

适用场景：

1. 用来做业务探索和创新测试
2. 需要对多个方案进行决策

流量隔离环境发布

在上述的发布策略中, 发布的单位都是应用, 但是一个功能模块往往是由多个应用组合在一起提供的服务,即使当前发布的应用出现了异常, 这个异常也未必体现在当前应用中, 在复杂的情况下, 异常会延迟到它的下游应用才体现出来, 如何发现此类问题并且不影响用户体验是非常重要的。此外, 我们有时候还希望新版本的代码上线以后, 只影响到一小部分用户。而传统的灰度发布, 因为无法识别业务流量, 所以即使某个应用只有一台机器出现了问题, 也可能会影响到所有的用户。

如下图左侧的灰度发布，App1 的所有机器都有一定概率会路由到出现问题的红色 App2 机器上。 而右侧的隔离环境发布中，新版本的代码会先发布在全链路隔离环境中，即使发布中出现问题，也只会影响少量用户。

优势：

1. 能够发现一些复杂的, 涉及到多应用的问题
2. 出现故障时, 只会影响很小一部分用户

不足：

1. 需要对流量隔离环境进行独立监控
2. 系统设计复杂, 需要中间件和链路上的所有应用能够识别业务流量

适用场景：

1. 较为核心的生产业务场景

阿里巴巴发布最佳实践

我们将按照发布的过程来介绍阿里巴巴发布的最佳实践。

发布计划

发布前要对待发布功能模块做充分验证，同时要思考假如本次发布引入故障该如何止血。所以在发布之前写出本次发布的计划清单是非常重要的，一个典型的发布计划如下：

a. 本次发布参与人
    开发人
    测试人
    代码 Review 人
b. 发布内容
c. 测试过程
d. 风险描述
e. 线上验证方案
f. 线上出现问题的止血方案
g. 发布步骤
    分 x 批发布, 前 x 批发布后暂停 x 小时