技术干货第一站
链接3000+技术总监/CTO,每天早上推送技术干货文章
转载声明：本文系蚂蚁团队原创，经授权转载于金融级分布式架构公众号
正文共：2769 字 11 图
预计阅读时间： 7 分钟
在前篇《素描单元化》中已经对单元化架构进行了总体介绍，单元化架构带来了很多好处，无论是伸缩性、高可用容灾还是日常运维方面，都能带来巨大的架构能力提升。本篇将聚集介绍蚂蚁金服在单元化架构下进行蓝绿发布的运维实践。
蓝绿发布 (Blue Green Deployment) 是一种平滑过渡的发布模式。蓝绿发布的操作模式上，首先依赖于能够将全站应用划分为对等的 A、B 两个单元，A 先发布新产品代码并引入少许用户流量，B 继续运行老产品代码；如果新代码 A 经线上运行观察没有迹象表明有问题，或者用户行为对 A 中的变化没有特别的反馈，那么逐步引入更多用户流量，直至所有用户都访问新产品。因此，蓝绿发布可以保证整体系统的稳定，在产品开放前期就可以发现、调整问题，以保证其影响面可控，这种能力为进行频繁的线上变更编织了一道强大的安全网，使得代码变更更加安全可靠。
在向大家介绍蓝绿发布实践之前，先简单回顾下支付宝系统的发布演化之路。
单台发布
在支付宝发展初期，全站只有一个应用叫 pay，几台服务器通过负载均衡策略组成一个服务集群。这个时期的发布非常简单，单台顺序发布，首先关闭 1 台服务器的流量，更新该台服务器上的产品代码，再打开该台流量，即完成了 1 台发布，重复以上步骤依次完成所有服务器的发布。
分组发布
随着业务量的上涨和 SOA 架构的演化，应用的服务器数慢慢增加，单应用的职责也被分解为由多个应用协作承担，一次发布包含的应用和服务器数越来越多，耗时也越来越长。为了提高发布速度，将一个应用的服务器划分为几组，以组为单位批量发布；另一方面，多个应用尽量并行，根据应用依赖关系排定发布的顺序，被依赖的应用先发布，再发布对它有依赖的应用，没有依赖关系的应用则可以并行发布。这个模式下的发布，新增了一个需要注意考量的复杂度，即应用发布的依赖次序。在发布前，需要事先评估好应用的发布顺序，如果评估有误，则可能造成发布期间业务出错。
随着支付宝业务的迅速发展以及第三代架构的全面落地，整体发布规模已发展为几百个应用、单应用服务器数千台、每周两次日常发布的庞大体系。应用间依赖关系错综复杂，发布顺序越来越难以协调，甚至可能出现循环依赖；另一方面，发布并行度无法上去也使得发布速度难以提升，一次日常发布几百个系统依次下来，往往需要耗时十几个小时，这在以敏捷为胜的互联网金融时代感觉简直令人难以接受。
beta发布
beta 发布是分组发布的一种特例形式，旨在控制项目上线的风险。对于某些风险高的项目，往往先发布少量服务器，观察较长一段时间，确认业务 OK 后，再发布剩下的服务器。与普通分组发布相比，beta 发布可以提前发现部分问题，如有问题只需要回滚少量服务器，对现有业务运转的影响小，但 beta 发布也有它的局限性：
beta 发布靠发布的服务器数量来控制新产品代码流量，无法自由调控流量。
beta 发布只有非常少量的流量，暴露问题的能力有限。
如果涉及多个系统间交互，A 和 B 同时 beta 少量服务器，A 需要调用 B，无法控制 A 的新代码服务器一定会调到 B 的新代码服务器，存在新老代码交叉调用；一是增加了观察人员对业务验证的困难，二是需要考虑各种兼容性问题。
所以，我们一直在积极探索如何让越趋庞大和复杂的系统代码变更能够又快又好的敏捷研发运维之路。在单元化架构能力达成之后，为这种探索带来了新的巨大的可能。单元化架构带来的这种新的发布能力，便是蓝绿发布模式。
单元化架构（下称 LDC）的演进带来了 2 项重要的能力，应用的单元化部署和灵活的流量调配能力。这使得我们可以将应用划分为能够独立支撑全站业务的闭合单元，用户流量能够在单元入口灵活地调配。借助 LDC 逻辑 ZONE 结构，按 ZONE 发布的蓝绿发布模式随之诞生，以突破先前发布所面临的困境。
蓝绿发布的原理
LDC 部署架构中，应用按 ZONE 划分为对等的蓝、绿两个单元，每个单元包含若干个 RZONE 和 1 个 GZONE，单元与单元之间隔离，业务引发的调用链路只存在单元内部。日常运行状态下，蓝、绿各承担线上 50% 的业务流量。
Step1. 发布前，将“蓝”流量调至 0%，对“蓝”的所有应用整体无序分 2 组发布。
Step2. “蓝”引流 1% 观察，如无异常，逐步上调分流比例至 100%。
Step3. “绿”流量为 0%，对“绿”所有应用整体无序分 2 组发布
Step4. 恢复日常运行状态，蓝、绿单元各承担线上 50% 的业务流量
新产品平滑上线
蓝绿发布能够有效降低新产品上线的风险，我们可以自由控制新产品的访问用户量，由零开始逐步放开访问量，在新产品开放前期就可以发现、调整问题，控制问题影响面。
对异常的快速回滚
普通发布模式下，对异常的处理速度往往依赖代码的回滚进度，少则需要数十分钟，多则数小时。而在蓝绿发布模式下，如果遇到重大异常，只需要关闭新产品的访问流量即可，这个过程可能仅需耗时数秒。隔离新产品的访问流量后，有充分的时间来讨论决策如何解决异常。
新老调用隔离
蓝绿发布模式下，应用调用控制在单元内部，隔离了单元间的调用。一个单元要么全部是新产品代码，要么全部是老产品代码，不存在新老代码交叉调用的情况，避免了发布期间的新老兼容性问题。
提高发布效率
蓝绿发布解决了发布顺序问题，由于发布期间完全没有流量，并且没有新老代码交叉调用问题，可以并行同时发布一个单元内所有系统，发布速度有质的提升。
业务正确性的监控与验证能力
如何在引入流量期间能够快速全面的发现问题，精细化的蓝绿分组监控会变得非常重要，包括更细颗粒度的业务健康度监控、DB 层面的监控等；另外，线上自动化测试验证，也能帮助我们在引流阶段发现由于线上线下环境差异而带来的问题。
大规模快速自动化应用部署能力
全站应用并行发布，颠覆了以住顺序发布的模式，对发布平台的资源分发等方面的性能也提出较大挑战。
自动精确的流量调度能力
通过强大的流量调度调控 PaaS 平台，能够根据不同的产品发布特性需求，进行多种模式的细粒度流量调度能力。
随着单元化架构的落地以及后续不断的演化和完善，随着运维 PaaS 平台的不断建设和增强，蓝绿发布模式在实现敏捷、高效、可靠完成生产环境代码变更和保障持续可用的战线上发挥了巨大的作用，是蚂蚁金服强健研发运维体系中的关键能力模块之一。
点击【阅读原文】获取招聘信息或发送简历到 sofa@cloud.alipay.com，期待您的加入！