关于阿里云:阿里巴巴发布最佳实践-阿里巴巴DevOps实践指南

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

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

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

常见公布策略

停机公布

停机发布会在公布以前敞开服务，进行用户拜访，而后一次性的降级所有服务。这种公布策略的公布频率往往比拟低，且须要在公布之前做好短缺的测试。

停机公布的特点有：

• 所有须要降级的组件被整合到一次公布中
• 一个我的项目中的大部分利用都会被更新
• 公布之前的研发流程和测试流程往往须要花很长的工夫
• 公布时如果呈现问题, 修复和回滚的老本很高
• 实现一次停机公布, 须要破费很久的工夫, 且须要很多团队在一起能力实现
• 往往须要客户端和服务器端同步降级
  停机公布并不适宜互联网公司，因为两次公布的距离很久，从性能个性提出到进入市场的工夫太长，对市场反馈不敏感，会在充沛竞争的市场里处于下风。每次公布因为要停机，也会带来经济损失。

劣势：

简略, 不太须要思考新旧版本共存时的兼容性问题

劣势：

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

适宜场景：

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 小时

不同环境应用不同的公布策略

后面介绍的几种公布策略都有各自的优缺点，要依据本人的场景特点和需要抉择适合的公布策略。

一般来说，测试环境是用来做初步功能测试，所以会频繁的更新代码和公布，如果采纳灰度公布的形式且公布的批次设置的比拟大，则开发效率会大打折扣。这个时候单机或多机的单批次停机公布其实是一个不做的抉择。

对于预发环境，不仅要思考本人测试的须要，还要思考上下游其余开发者的测试需要，所以单批次停机公布就不再适合，能够设置两批公布。

对于线上环境，能够先公布隔离流量环境，再多批次公布线上环境。

公布中关注监控报警

仅靠公布策略是无奈防止故障的产生的，在公布中和公布后认真的察看利用的监控数据十分重要。利用的外围指标监控数据，比方 QPS、RT、成功率和报错数，可能帮忙用户尽可能早的发现故障。此外，在生产环境中，如果批次数量设置的比拟小，每批公布机器数量比拟少，那么即便某些监控指标呈现了问题，因为数据量比拟小，可能会被吞没在整体的监控数据中，所以配置已公布机器的独立监控也是十分重要的。

金丝雀公布和无人值守

阿里外部绝大部分利用会在多机房 / 单元部署，可能存在一种场景，同一份代码和配置在某些机房 / 单元失常，在其余的的单元 / 机房下就会呈现故障，所以有必要在分批公布的时候，把所有机房 / 单元的组合都在第一批公布时呈现，这样问题能够及早裸露。此外研发人员往往会重点关注前几批公布，如果前面批次才呈现问题，研发人员可能无奈疾速响应。

单元化是为了解决容灾和扩展性问题, 上图是阿里巴巴的单元化部署架构。

此外，利用的监控项个别都很多，在公布周期比拟长的状况下，不能要求研发人员时刻专一每一个监控项，须要肯定的智能化计划帮忙研发找出那些须要重点关注的监控项。

为了解决下面两个问题，阿里设计并实现了本人的金丝雀公布策略。金丝雀公布从利用的每个机房 / 单元下抽取 10% 的机器放到首批，无人值守智能监控零碎会对这部分机器设置独立的监控，对于每个监控项，无人值守会比照已公布和未公布机器的监控指标数据，同时对比公布前和公布后的监控数据，如果发现异常，会推送给研发人员做进一步的判断。

这种金丝雀公布策略能够帮忙研发尽可能早的发现问题, 并且缩小研发人员的工作量，进步研发效率。

继续集成和公布

正当的抉择公布策略，依照下面所述的最佳实际来公布，公布的危险能够被管制在很小的范畴内，甚至比停机公布的危险还要小。实际上，公布周期短，每次公布仅蕴含大量代码是一个很好的公布实际。因为部署间隔时间长，将会导致每次的部署蕴含更多的代码变更，后果就是呈现更多缺点和宕机的危险。这种状况下，人们为了升高公布危险，会偏向于减少更多的评审，事实上这除了大大增加部署工夫外，对升高公布危险的影响微不足道。这是一个越来越差的加强回路，咱们须要通过高频的继续部署，来颠覆这个恶性循环。

总结

麻利开发可能缩短产品走向市场的工夫, 让消费者更快的取得想要的性能, 也能让产品团队更快的拿到消费者的反馈并据此对产品做出迭代。为了解决麻利开发下频繁公布带来的公布危险, 本文介绍了多种公布策略, 包含各个公布策略的优缺点, 实用场景, 在不同场景下综合利用这些模式能够在更疾速地交付高质量的产品。

【对于云效】

云效，云原生时代一站式 BizDevOps 平台，反对公共云、专有云和混合云多种部署状态，通过云原生新技术和研发新模式，助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利，打造“双敏”组织，实现 10 倍效力晋升。

立刻体验