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