蓝绿发布、滚动发布、灰度发布等部署方案对比与总结

在项目迭代的过程中,不可避免需要进行项目上线。上线对应着部署或者重新部署,部署对应着修改,修改则意味着风险。

目前有很多用于部署的技术,有的简单,有的复杂,有的得停机,有的不需要停机即可完成部署。本文将对目前常用的部署方案做一个简单的总结。

蓝绿发布(Blue/Green Deployment)

定义

蓝绿部署是不停老版本,部署新版本然后进行测试。确认OK后将流量切到新版本,然后老版本同时也升级到新版本。

特点

蓝绿部署无需停机,并且风险较小。

部署过程

部署版本 1 的应用(初始的状态)

所有外部请求的流量都打到这个版本上。

部署版本 2 的应用

版本 2 的代码与版本 1 不同(新功能、Bug修复等)。

将流量从版本 1 切换到版本 2。

如版本 2 测试正常,就删除版本 1 正在使用的资源(例如实例),从此正式用版本 2。

小结

从过程不难发现,在部署的过程中,我们的应用始终在线。并且新版本上线的过程中,并没有修改老版本的任何内容,在部署期间,老版本的状态不受影响,这样风险很小。并且只要老版本的资源不被删除,理论上,我们可以在任何时间回滚到老版本。

蓝绿发布的注意事项

当你切换到蓝色环境时,需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理,会是一个比较麻烦的问题。

可能会出现需要同时处理微服务架构应用和传统架构应用的情况,如果在蓝绿部署中协调不好这两者,还是有可能会导致服务停止。

需要提前考虑数据库与应用部署同步迁移/回滚的问题。

蓝绿部署需要有基础设施支持。

在非隔离基础架构( VM 、 Docker 等)上执行蓝绿部署,蓝色环境和绿色环境有被摧毁的风险。

优势和不足

优势

升级切换和回退速度非常快。

不足

切换是全量的,如果 V2 版本有问题,则对用户体验有直接影响。

需要两倍机器资源。

适用场合

对用户体验有一定容忍度的场景。

机器资源有富余或者可以按需分配(AWS 云,或自建容器云)。

灰度发布

定义

灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。AB Test 就是一种灰度发布方式,让一部分用户继续用 A,一部分用户开始用 B,如果用户对 B 没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。

灰度发布结构图

A/B Testing

A/B 测试是用来测试应用功能表现的方法,例如可用性、受欢迎程度、可见性等等。 A/B 测试通常用在应用的前端上,不过当然需要后端来支持。

A/B 测试与蓝绿部署的区别在于, A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论,并确信该结论在推广到全部流量可信;蓝绿部署的目的是安全稳定地发布新版本应用,并在必要时回滚。

金丝雀发布

我们平常所说的金丝雀部署也是灰度发布的一种方式,在原有版本可用的情况下,同时部署一个新版本应用作为「金丝雀」服务器来测试新版本的性能和表现,以保障整体系统稳定的情况下,尽早发现、调整问题。

矿井中的金丝雀:17 世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;当瓦斯含量超过一定限度时,虽然鲁钝的人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为瓦斯检测指标,以便在危险状况下紧急撤离。

灰度发布/金丝雀发布由以下几个步骤组成:

准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。

从负载均衡列表中移除掉「金丝雀」服务器。

升级「金丝雀」应用(排掉原有流量并进行部署)。

对应用进行自动化测试。

将「金丝雀」服务器重新添加到负载均衡列表中(连通性和健康检查)。

如果「金丝雀」在线使用测试成功,升级剩余的其他服务器(否则就回滚)。

除此之外灰度发布还可以设置路由权重,动态调整不同的权重来进行新老版本的验证。

优势和不足

优势

用户体验影响小,灰度发布过程出现问题只影响少量用户。

不足

发布自动化程度不够,发布期间可引发服务中断。

滚动发布(Rolling Update Deployment)

在金丝雀发布基础上的进一步优化改进,是一种自动化程度较高的发布方式,用户体验比较平滑,是目前成熟型技术组织所采用的主流发布方式。

定义

滚动发布:一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有的实例都更新成新版本。

特点

这种部署方式相对于蓝绿部署,更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署,例如每次只取出集群的 20% 进行升级。

部署过程

滚动式发布一般先发 1 台,或者一个小比例,如 2% 服务器,主要做流量验证用,类似金丝雀 (Canary) 测试。

滚动式发布需要比较复杂的发布工具和智能 LB,支持平滑的版本替换和流量拉入拉出。

每次发布时,先将老版本 V1 流量从 LB 上摘除,然后清除老版本,发新版本 V2,再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。

一次滚动式发布一般由若干个发布批次组成,每批的数量一般是可以配置的(可以通过发布模板定义)。例如第一批 1 台(金丝雀),第二批 10%,第三批 50%,第四批 100%。每个批次之间留观察间隔,通过手工验证或监控反馈确保没有问题再发下一批次,所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长,比如金丝雀 10 分钟,后续间隔 2 分钟)。

回退是发布的逆过程,将新版本流量从 LB 上摘除,清除新版本,发老版本,再将 LB 流量接入老版本。和发布过程一样,回退过程一般也比较慢的。

优势和不足

优势

用户体验影响小,体验较平滑。

不足

发布和回退时间比较缓慢。

发布工具比较复杂,LB 需要平滑的流量摘除和拉入能力。

其它发布方式

上述都是偏传统的发布方式,能覆盖大部分应用发布场景。针对一些关键新功能的上线发布,或者一些特定的场景,还有一些特殊的发布方式。

功能开关发布

利用代码中的功能开关(Feature Flag/Toggle/Switch)来控制发布逻辑,一般不需要复杂的发布工具和智能 LB 配合,是一种相对比较低成本和简单的发布方式。这种方式也是支持现代 DevOps 理念,研发人员可以灵活定制和自助完成的发布方式。功能开关的原理如下图所示:

部署过程

功能开关发布需要一个配置中心或者开关中心这样的服务支持,例如携程的 Apollo 配置中心或者开源的 FF4J,这些都支持开关发布。业界还有专门的功能开关 SaaS 服务,例如 LaunchDarkly。通过配置中心,运维或研发人员可以在运行期动态配置功能开关的值。当然,功能开关发布只是配置中心的一种使用场景,配置中心还能支持其它很多动态配置场景。

功能开关服务一般提供客户端 SDK,方便开发人员集成。在运行期,客户端 SDK 会同步最新的开关值,技术实现有推方式 (push),也有拉方式 (pull),或者推拉结合方式。

新功能(V2 new feature)和老功能(V1 old feature)住在同一套代码中,新功能隐藏在开关后面,如果开关没有打开,则走老代码逻辑,如果开关打开,则走新代码逻辑。技术实现上可以理解为一个简单的 if/else 逻辑。

应用上线后,开关先不打开,然后运维或研发人员通过开关中心打开新功能,经过流量验证新功能没有问题,则发布完成;如果有问题,则随时可以通过开关中心切回老功能逻辑。

优势和不足

优势

升级切换和回退速度非常快。

相对于复杂的发布工具,实施比较简单,成本相对低廉。

研发能够灵活定制发布逻辑,支持 DevOps 自助发布。

不足

切换是全量的,如果 V2 版本有问题,则对用户体验有直接影响。

对代码有侵入,代码逻辑会变复杂,需要定期清理老版本逻辑,维护成本变高。

影子测试

对于一些涉及核心业务的遗留系统的升级改造,为了确保万无一失,有一种称为影子测试的大招,采用比较复杂的流量复制、回放和比对技术实现。下面是影子测试的一个样例架构图:

部署过程

影子测试一般适用于遗留系统的等价重构迁移,例如 .net 转 Java,或者 SQLServer 数据库升级为 MySQL 数据库,且外部依赖不能太多,否则需要开发很多 mock,测试部署成本会很高,且比对测试更加复杂和不稳定。

目标实现老的 legacy 服务迁移升级到新的 experimental 服务。

测试开始前,需要在测试环境部署一份 legacy 服务和 experimental 服务,同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来,一般可以通过 kafka 队列收集,然后通过类似 goreplay 这样的工具,消费 kafka 里头的请求日志,复制回放,将请求分发到 legacy 服务和 experimental 服务,收到响应后进行比对,如果所有响应比对成功,则可以认为 legacy 服务和 experimental 服务在功能逻辑上是等价的;如果有响应比对失败,则认为两者在功能逻辑上不等价,需要修复 experimental 并重新进行影子测试,直到全部比对成功。根据系统复杂度和关键性不同,比对测试时间短的可能需要几周,长的可达半年之久。

影子测试因为旁路在独立测试环境中进行,可以对生产流量完全无影响。

优势和不足

优势

对生产用户体验完全无影响。

可以使用生产真实流量进行测试(复制比对)。

不足

搭建复杂度很高,技术门槛高,数据库的导出复制是难点。

外部依赖不能太多,否则测试部署成本很高,且比对测试更加复杂和不稳定。

参考文章

https://www.google.com

http://t.cn/RHV3riW

http://t.cn/RnD147P

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容