前言
DevOps追求更短的迭代周期和更频繁的发布。但发布次数越多，引入故障的可能性就越大。更多的故障会降低服务的可用性，进而影响客户体验。因此，为了保证服务质量，保持发布的最后一关，阿里逐渐发展出适应性DevOps要求的发布策略。
在阿里的实践开始之前，我们将简要介绍几种常见的发布策略，以及它们适用的场景和优缺点。
一 常见的发布策略
1 停机发布
停机会议在发布前关闭服务，停止用户访问，然后一次性升级所有服务。这种发布策略的发布频率往往相对较低，在发布前需要充分的测试。
停机发布的特点有：
所有需要升级的组件都集成在一次发布中
项目中的大部分应用程序将被更新
发布前的研发过程和测试过程往往需要很长时间
如果出现问题，修复和回滚的成本很高
完成停机发布需要很长时间，需要很多团队一起完成
客户端和服务器端通常需要同步升级
停机发布不适合互联网公司，因为两次发布之间的间隔很长，从功能特征到进入市场的时间太长，对市场反应不敏感，将在充分竞争的市场中处于劣势。每次发布都会因为停机而造成经济损失。
优势：
简单，新旧版本共存时不需要考虑兼容性
劣势：
在发布过程中，服务不可用
只能在业务低峰期发布 (通常是晚上)，需要很多团队一起工作
故障后很难回滚
适合场景：
开发测试环境
非关键应用，用户影响小
场景兼容性难以控制
2 金丝雀发布
金丝雀的术语起源于20世纪初。当时，英国煤矿工人在下井前会将笼养的金丝雀带入矿井。如果矿井中一氧化碳等有毒气体浓度过高，金丝雀在影响矿工之前比人类更敏感、更快。金丝雀中毒后，煤矿工人知道应该立即撤离。金丝雀发布是在向所有用户发布整个软件的新版本之前，发布给一些用户，并用真实的客户流量进行测试，以确保软件不会出现严重问题，降低发布风险。
在实践中，金丝雀通常首先发布到一个小比例的机器，如 2% 服务器进行流量验证，然后快速获得反馈，并根据反馈决定是扩展发布还是滚动。金丝雀的发布通常与监控系统相结合，通过监控指标观察金丝雀机器的健康状况。如果金丝雀通过测试，将剩余的机器升级为新版本，否则滚动代码。
优势：
对用户体验影响不大，只有少数用户会受到金丝雀发布过程中的影响
发布安全可以得到保障
劣势：
金丝雀的机器数量相对较少，有些问题无法暴露
适用场景：
监控相对完整，与发布系统集成
3 灰度/滚动发布
灰度发布是金丝雀发布的延伸，将发布分为不同的阶段/批次，每个阶段/批次的用户数量逐步增加。如果新版本在现阶段没有发现问题，将增加用户数量进入下一阶段，直到扩展到所有用户。
灰度发布可以降低发布风险，这是一种零停机时间的发布策略。它逐渐从一个版本切换到另一个版本，通过切换在线共存版本之间的路由权重。整个发布过程将持续很长时间。在此期间，新旧代码共存。因此，在开发过程中，需要考虑版本之间的兼容性。新旧代码共存不会影响功能可用性和用户体验。当新版本的代码出现问题时，灰度发布可以快速回滚到旧版本的代码上。
灰度发布结合特性开关等技术，可实现更加复杂灵活的发布策略。
优势：
用户体验影响不大，无需停机发布
可控制发布风险
劣势：
发布时间会更长
需要复杂的发布系统和负载平衡器
新旧版本共存时需要考虑兼容性
适用场景：
适用于可用性高的生产环境发布
4 蓝绿发布
蓝绿色部署是指两个完全相同、独立的生产环境，一个称为“蓝环境”，一个叫做“绿环境”。其中，绿色环境是用户正在使用的生产环境。当需要部署新版本时，首先将新版本部署到蓝色环境中，然后在蓝色环境中进行烟雾测试，以检查新版本是否正常工作。如果测试通过，发布系统更新路由配置，并将用户流量从绿色环境引导到蓝色环境，蓝色环境将成为生产环境。这种切换通常可以在一秒钟内完成。如果有问题，将路由切回绿色环境，然后在蓝色环境中调试，找出问题的原因。因此，蓝色和绿色部署只能切换一次，并立即向所有用户推出新版本。新功能可以立即对所有用户生效。
优势：
升级切换和返回速度非常快
零停机时间
不足：
一次性全切换，如果发布有问题，会对用户产生很大的影响
需要两倍的机器资源
支持热备集群的流量切换需要中间件和应用程序
适用场景：
机器资源比较富余或者按需分配 (背靠云厂商)
5 A/B 测试
A/B 测试与灰度发布非常相似，可以区分发布的目的。AB测试侧重的是根据A版本和B决定版本的差异，最后选择一个版本进行部署。与灰度发布相比，AB与金丝雀发布相比，测试更倾向于做出决定，AB在权重和流量的切换上，测试更加灵活。
例如，有两个实现版本的功能 A 和 B，通过细粒度的流量控制， 50% 的用户总是被引导到 A 在实现方面，剩下的50% 用户总是被引导到 B 实现上，通过比较 A 实现和 B 实现转化率，最终选择转化率高的 A 作为功能的最终版本实现。
优势：
快速实验能力
用户体验影响小
生产环境流量可用于测试
可针对某些特定用户进行测试
不足：
需要更复杂的业务流量识别和控制能力
新旧版本的复杂兼容性需要考虑
适用场景：
用于业务探索和创新测试
多个方案需要决策
6 发布流量隔离环境
在上述发布策略中，发布单元是应用程序，但功能模块通常由多个应用程序组合提供服务，即使当前发布的应用程序异常，异常也可能不反映在当前应用程序中，在复杂的情况下，异常会延迟到其下游应用程序，如何发现这些问题，不影响用户体验是非常重要的。此外，我们有时希望新版本的代码推出后只会影响少数用户。传统的灰度发布，因为无法识别业务流量，所以即使一个应用程序只有一台机器有问题，也可能会影响所有用户。
下图左侧发布灰度，App1 所有机器都有一定的路由红色 的概率App2 机器上。在发布右侧的隔离环境时，新版本的代码将首先发布在全链路隔离环境中。即使发布中出现问题，也只会影响少数用户。
优势：
可以发现一些涉及多应用的复杂问题
故障只会影响少数用户
不足：
需要独立监控流量隔离环境
系统设计复杂，中间件和链路上的所有应用都需要识别业务流量
适用场景：
较为核心的生产业务场景
第二，阿里巴巴发布最佳实践
我们将介绍阿里巴巴发布的最佳实践。
1 发布计划
在发布之前，我们应该充分验证发布的功能模块，并考虑如果发布引入故障，如何止血。因此，在发布前编写发布的计划清单非常重要。典型的发布计划如下：
参与者开发人员测试人代码的发布Review 人
发布内容
测试过程
风险描述
在线验证方案
线上有问题的止血方案
发布步骤分 x 批发前 x 批发布后暂停 x 小时
2 在不同的环境中使用不同的发布策略
上述发布策略各有优缺点，应根据自身场景特点和需要选择合适的发布策略。
一般来说，测试环境用于初步功能测试，因此代码和发布将经常更新。如果采用灰度发布的方式，发布的批次设置相对较大，开发效率将大大降低。此时，单机或多机单批停机发布实际上是一个不做的选择。
对于预发环境，不仅要考虑自己的测试需求，还要考虑上下游其他开发者的测试需求。因此，单批停机发布不再合适，可以设置两批发布。
对于在线环境，可以先发布隔离流量环境，然后多批发布在线环境。
3 发布中注重监控报警
仅仅依靠发布策略是不可避免的，在发布和发布后仔细观察应用程序的监控数据是非常重要的。应用程序的核心指标监控数据，如 QPS、RT、成功率和错误的报告可以帮助用户尽快发现故障。此外，在生产环境中，如果批量设置相对较小，每批发布机的数量相对较少，那么即使一些监控指标有问题，因为数据相对较小，可能会淹没在整体监控数据中，因此配置发布机的独立监控也非常重要。
4 金丝雀发布，无人值守
大多数阿里内部应用程序将部署在多个机房/单元中，可能有一个场景，在某些机房/单元中配置相同的代码和配置单元正常，其他单元/机房下会出现故障。因此，在批量发布时，有必要在第一批发布时出现所有机房/单元的组合，以便尽快暴露问题。此外，研发人员往往关注前几批发布。如果后一批出现问题，研发人员可能无法快速响应。
阿里巴巴的单元化部署架构是为了解决容灾和扩展性问题。
此外，应用程序中一般有许多监控项目。在发布周期较长的情况下，研发人员不能总是关注每个监控项目，需要一定的智能解决方案来帮助研发找到需要关注的监控项目。
为了解决上述两个问题，阿里巴巴设计并实现了自己的金丝雀发布策略。金丝雀发布从每个应用机房/单元中提取 10% 的机器。无人值守智能监控系统将对这部分机器进行独立监控。对于每个监控项目，无人值守将比较发布和未发布机器的监控指标数据，并比较发布前后的监控数据。如果发现异常，将推送给研发人员进一步判断。
这种金丝雀发布策略可以帮助研发尽早发现问题，减少研发人员的工作量，提高研发效率。
5 持续集成发布
根据上述最佳实践，合理选择发布策略，发布的风险可以控制在很小的范围内，甚至小于停机发布的风险。事实上，发布周期很短，每次发布只包含少量代码是一个很好的发布实践。由于部署间隔较长，每个部署都会包含更多的代码变化，导致更多的缺陷和停机风险。在这种情况下，人们倾向于增加更多的评论，以降低发布的风险。事实上，除了大大增加部署时间外，对降低发布风险的影响很小。这是一个越来越糟糕的增强循环，我们需要通过高频持续部署来逆转这个恶性循环。
三 总结
敏捷开发可以缩短产品进入市场的时间，让消费者更快地获得他们想要的功能，让产品团队更快地获得消费者的反馈，并相应地迭代产品。为了解决敏捷开发下频繁发布带来的发布风险，本文介绍了各种发布策略，包括各种发布策略的优缺点和适用场景。这些模式可以在不同的场景下更快地交付高质量的产品。