编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》前往:https://developer.aliyun.com/topic/devops,下载完整版电子书,了解阿里十年DevOps实践经验。
DevOps 追求更短的迭代周期、更高频的发布。但发布的次数越多,引入故障的可能性就越大。更多的故障将会降低服务的可用性,进而影响到客户体验。所以,为了保证服务质量,守好发布这个最后一道关,阿里逐步发展出了适应 DevOps 要求的发布策略。
在开始讲述阿里的实践之前,我们先简单介绍下几种常见发布策略, 以及它们适用的场景和优缺点。
常见发布策略
停机发布
停机发布会在发布以前关闭服务,停止用户访问,然后一次性的升级所有服务。这种发布策略的发布频率往往比较低,且需要在发布之前做好充足的测试。
停机发布的特点有:
-
所有需要升级的组件被整合到一次发布中
-
一个项目中的大部分应用都会被更新
-
发布之前的研发流程和测试流程往往需要花很长的时间
-
发布时如果出现问题, 修复和回滚的成本很高
-
完成一次停机发布, 需要花费很久的时间, 且需要很多团队在一起才能完成
-
往往需要客户端和服务器端同步升级
停机发布并不适合互联网公司,因为两次发布的间隔很久,从功能特性提出到进入市场的时间太长,对市场反应不敏感,会在充分竞争的市场里处于下风。每次发布因为要停机,也会带来经济损失。
优势:
简单, 不太需要考虑新旧版本共存时的兼容性问题
劣势:
发布过程中,服务不可用
只能在业务低峰期 (往往是夜间)发布,并且需要很多团队在一起工作
出现故障后很难回滚
适合场景:
-
开发测试环境
-
非关键应用,用户影响面小
-
兼容性比较难管控的场景
金丝雀发布
金丝雀发布这个术语源自 20 世纪初期,当时英国的煤矿工人在下井采矿之前,会把笼养的金丝雀携带到矿井中,如果矿井中一氧化碳等有毒气体的浓度过高,在影响矿工之前,金丝雀相比人类表现的更加敏感快速,金丝雀中毒之后,煤矿工人就知道该立刻撤离。金丝雀发布是在将整个软件的新版本发布给所有用户之前,先发布给部分用户,用真实的客户流量来测试,以保证软件不会出现严重问题,降低发布风险。
在实践中,金丝雀发布一般会先发布到一个小比例的机器,