阿里巴巴发布最佳实践|阿里巴巴发布最佳实践 | 阿里巴巴DevOps实践指南
文章图片
编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》,扫描上方二维码或前往:https://developer.aliyun.com/...,下载完整版电子书,了解阿里十年DevOps实践经验。
DevOps 追求更短的迭代周期、更高频的发布。但发布的次数越多,引入故障的可能性就越大。更多的故障将会降低服务的可用性,进而影响到客户体验。所以,为了保证服务质量,守好发布这个最后一道关,阿里逐步发展出了适应 DevOps 要求的发布策略。
在开始讲述阿里的实践之前,我们先简单介绍下几种常见发布策略, 以及它们适用的场景和优缺点。
常见发布策略
停机发布
停机发布会在发布以前关闭服务,停止用户访问,然后一次性的升级所有服务。这种发布策略的发布频率往往比较低,且需要在发布之前做好充足的测试。
停机发布的特点有:
- 所有需要升级的组件被整合到一次发布中
- 一个项目中的大部分应用都会被更新
- 发布之前的研发流程和测试流程往往需要花很长的时间
- 发布时如果出现问题, 修复和回滚的成本很高
- 完成一次停机发布, 需要花费很久的时间, 且需要很多团队在一起才能完成
- 往往需要客户端和服务器端同步升级
停机发布并不适合互联网公司,因为两次发布的间隔很久,从功能特性提出到进入市场的时间太长,对市场反应不敏感,会在充分竞争的市场里处于下风。每次发布因为要停机,也会带来经济损失。
简单, 不太需要考虑新旧版本共存时的兼容性问题
劣势:
发布过程中,服务不可用
只能在业务低峰期 (往往是夜间)发布,并且需要很多团队在一起工作
出现故障后很难回滚
适合场景:
- 开发测试环境
- 非关键应用,用户影响面小
- 兼容性比较难管控的场景
在实践中,金丝雀发布一般会先发布到一个小比例的机器,比如 2% 的服务器做流量验证,然后从中快速获得反馈,根据反馈决定是扩大发布还是回滚。金丝雀发布通常会结合监控系统,通过监控指标,观察金丝雀机器的健康状况。如果金丝雀测试通过,则把剩余的机器全部升级成新版本,否者回滚代码。
文章图片
优势:
- 对用户体验影响较小,在金丝雀发布过程中,只有少量用户会受影响
- 发布安全能够得到保障
- 金丝雀的机器数量比较少, 有一些问题并不能够暴露出来
- 监控比较完备且与发布系统集成
灰度发布可以减小发布风险, 是一种零宕机时间的发布策略。它通过切换线上并存版本之间的路由权重,逐步从一个版本切换为另一个版本。整个发布过程会持续比较长的时间, 在这段时间内, 新旧代码共存, 所以在开发过程中, 需要考虑版本之间的兼容性, 新旧代码共存不能影响功能可用性和用户体验。当新版本代码出现问题时, 灰度发布能够比较快的回滚到老版本的代码上。
结合特性开关等技术,灰度发布可以实现更复杂灵活的发布策略。
文章图片
优势:
- 用户体验影响比较小, 不需要停机发布
- 能够控制发布风险
- 发布时间会比较长
- 需要复杂的发布系统和负载均衡器
- 需要考虑新旧版本共存时的兼容性
- 适合可用性较高的生产环境发布
文章图片
优势:
- 升级切换和回退速度非常快
- 零停机时间
- 一次性的全量切换, 如果发布出现问题, 会对用户产生比较大的影响
- 需要两倍的机器资源
- 需要中间件和应用自身支持热备集群的流量切换
- 机器资源比较富余或者按需分配 (背靠云厂商)
举个例子,某功能有两个实现版本 A 和 B,通过细粒度的流量控制,把 50% 的用户总是引导到 A 实现上,把剩下的 50% 用户总是引导到 B 实现上,通过比较 A 实现和 B 实现的转化率,最终选择转化率较高的 A 实现作为功能的最终版本。
文章图片
优势:
- 快速实验能力
- 用户体验影响小
- 可以使用生产环境流量做测试
- 可以针对某些特定用户做测试
- 需要较为复杂的业务流量识别和控制能力
- 需要考虑较为复杂的新旧版本兼容性问题
- 用来做业务探索和创新测试
- 需要对多个方案进行决策
如下图左侧的灰度发布,App1 的所有机器都有一定概率会路由到出现问题的红色 App2 机器上。 而右侧的隔离环境发布中,新版本的代码会先发布在全链路隔离环境中,即使发布中出现问题,也只会影响少量用户。
文章图片
优势:
- 能够发现一些复杂的, 涉及到多应用的问题
- 出现故障时, 只会影响很小一部分用户
- 需要对流量隔离环境进行独立监控
- 系统设计复杂, 需要中间件和链路上的所有应用能够识别业务流量
- 较为核心的生产业务场景
我们将按照发布的过程来介绍阿里巴巴发布的最佳实践。
发布计划 发布前要对待发布功能模块做充分验证,同时要思考假如本次发布引入故障该如何止血。所以在发布之前写出本次发布的计划清单是非常重要的,一个典型的发布计划如下:
a. 本次发布参与人
开发人
测试人
代码 Review 人
b. 发布内容
c. 测试过程
d. 风险描述
e. 线上验证方案
f. 线上出现问题的止血方案
g. 发布步骤
分 x 批发布, 前 x 批发布后暂停 x 小时
不同环境使用不同的发布策略 前面介绍的几种发布策略都有各自的优缺点,要根据自己的场景特点和需求选择合适的发布策略。
一般来说,测试环境是用来做初步功能测试,所以会频繁的更新代码和发布,如果采用灰度发布的方式且发布的批次设置的比较大,则开发效率会大打折扣。这个时候单机或多机的单批次停机发布其实是一个不做的选择。
对于预发环境,不仅要考虑自己测试的需要,还要考虑上下游其他开发者的测试需求,所以单批次停机发布就不再合适,可以设置两批发布。
对于线上环境,可以先发布隔离流量环境,再多批次发布线上环境。
发布中关注监控报警 仅靠发布策略是无法避免故障的发生的,在发布中和发布后仔细的观察应用的监控数据非常重要。应用的核心指标监控数据,比如 QPS、RT、成功率和报错数,能够帮助用户尽可能早的发现故障。此外,在生产环境中,如果批次数量设置的比较小,每批发布机器数量比较少,那么即使某些监控指标出现了问题,因为数据量比较小,可能会被淹没在整体的监控数据中,所以配置已发布机器的独立监控也是非常重要的。
金丝雀发布和无人值守 阿里内部绝大部分应用会在多机房/单元部署,可能存在一种场景,同一份代码和配置在某些机房/单元正常,在其他的的单元/机房下就会出现故障,所以有必要在分批发布的时候,把所有机房/单元的组合都在第一批发布时出现,这样问题可以及早暴露。此外研发人员往往会重点关注前几批发布,如果后面批次才出现问题,研发人员可能无法快速响应。
文章图片
单元化是为了解决容灾和扩展性问题, 上图是阿里巴巴的单元化部署架构。
此外,应用的监控项一般都很多,在发布周期比较长的情况下,不能要求研发人员时刻专注每一个监控项,需要一定的智能化方案帮助研发找出那些需要重点关注的监控项。
为了解决上面两个问题,阿里设计并实现了自己的金丝雀发布策略。金丝雀发布从应用的每个机房/单元下抽取 10% 的机器放到首批,无人值守智能监控系统会对这部分机器设置独立的监控,对于每个监控项,无人值守会对比已发布和未发布机器的监控指标数据,同时对比发布前和发布后的监控数据,如果发现异常,会推送给研发人员做进一步的判断。
这种金丝雀发布策略可以帮助研发尽可能早的发现问题, 并且减少研发人员的工作量,提高研发效率。
持续集成和发布 合理的选择发布策略,按照上面所述的最佳实践来发布,发布的风险可以被控制在很小的范围内,甚至比停机发布的风险还要小。实际上,发布周期短,每次发布仅包含少量代码是一个很好的发布实践。因为部署间隔时间长,将会导致每次的部署包含更多的代码变更,结果就是出现更多缺陷和宕机的风险。这种情况下,人们为了降低发布风险,会倾向于增加更多的评审,事实上这除了大大增加部署时间外,对降低发布风险的影响微乎其微。这是一个越来越差的增强回路,我们需要通过高频的持续部署,来颠覆这个恶性循环。
总结
敏捷开发能够缩短产品走向市场的时间, 让消费者更快的获得想要的功能, 也能让产品团队更快的拿到消费者的反馈并据此对产品做出迭代。为了解决敏捷开发下频繁发布带来的发布风险, 本文介绍了多种发布策略,包括各个发布策略的优缺点, 适用场景, 在不同场景下综合应用这些模式可以在更快速地交付高质量的产品。
【阿里巴巴发布最佳实践|阿里巴巴发布最佳实践 | 阿里巴巴DevOps实践指南】【关于云效】
云效,云原生时代一站式BizDevOps平台,支持公共云、专有云和混合云多种部署形态,通过云原生新技术和研发新模式,助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷,打造“双敏”组织,实现 10 倍效能提升。
立即体验
文章图片
推荐阅读
- 图文小编《杨浦、成毅》为你发布!无价之宝随意摆放的公园
- 用npm发布一个包的教程并编写一个vue的插件发布
- 【译】Rails|【译】Rails 5.0正式发布(Action Cable,API模式等)
- 最佳损友
- 运用flutter|运用flutter 构建一个发布版(release)APK
- Vue组件之事件总线和消息发布订阅详解
- K8S|K8S 生态周报| Istio 即将发布重大安全更新,多个版本受影响
- Redis——发布订阅/消息队列
- LOGO--完美世界Logo设计(三)
- 这款充电最快的5G手机就要发布了,你对它还一无所知()