Fork me on GitHub
Google

聊聊几种常见的部署模型

聊聊几种常见的部署模型

上线这个事,不可避免,而且一定是承担风险的。尤其是一些用户量巨大的应用,一不留神,产生的影响也是小不了的。所有,在业界,有着很多种发布上线的策略或者说是机制,用来减少上线所带来的风险。

据了解,比较常见的几种部署方式有以下几种:

  • 蓝绿部署
  • 分批发布
  • 灰度发布

蓝绿部署

这种部署方式,目的是减少发布过程中服务不可用的时间,以及部署的新版本的正确性检测。

发布的流程如下:

  1. 首先,得要有2套基础设施。还得有load balance,不然流量无法隔离,也是难以实现蓝绿部署方案。

  2. 上面的2个集群,我们可以将绿色集群的状态称为’备用’集群. 当我们需要做蓝绿部署的事情,从同一接入模块将流量切掉 ,这样,绿色的集群将不接受用户的流量,可以用来新的服务。

  3. 在绿色集群里面,开始部署新的版本B。在这里,我们也会有一定的验收工作来保障新版本B一定是可用的。 引入一些自动化的测试流量进行验收。

  4. 当确认绿色集群的版本OK,可用将流量从蓝色集群切换到绿色集群。切换完成后,对蓝色集群进行新版本的部署、

  5. 等待蓝绿集群全部部署到B,整个流程就可以结束,全部集群可对外恢复服务。

分批部署(滚动部署)

依然是比较常见的一种部署方式,每次只更新一小部分服务器。(发布批次是可以调整的,但得保证在部署过程中,停止这部分服务,线上服务不会有较大的影响)

  1. 设置发布策略,10台服务器,分5批发布。
  2. 正式发布过程中,第一批先找出2台服务器进行部署B版本,其余8台对外提供服务。
  3. 第一批部署完成,又从版本A的机器列表中找2台进行部署,成功后提供服务。这个时候对外服务的是6台A版本,2台B版本。
  4. 依次循环下去,等待最终全部服务器部署完成。

灰度发布

灰度发布也称为金丝雀部署。(这个名字的来源是因为一个小股数,以前矿井工人发现,金丝雀对瓦斯极敏感,于是矿井工人在进行工作之前,会放出金丝雀下去矿井检查下瓦斯的情况,以便及时发发现危险,演变到后期就变成了一种系统稳定性保障的策略)

灰度发布其实算是一种验收测试,线上进行灰度版本测试,用来保障整体系统的稳定性。同时,也能与我们常见的AB testing的一种部署方式,线上AB版本共存,进行流量比较。

原有版本可用的情况下,同时部署的一个新版本应用作为“金丝雀”版本(灰度版本),测试新版本的性能和表现,可以尽早发现问题、调整问题。

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

  • 准备好部署各个阶段的工件,包括:构建组件,测试脚本,配置文件和部署清单文件。
  • 从负载均衡列表中移除掉“金丝雀”服务器。
  • 升级“金丝雀”应用(排掉原有流量并进行部署)。
  • 对应用进行自动化测试。
  • 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
  • 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)

小结

蓝绿部署 分批部署 灰度部署
特点 2套集群,新版本的发布,不会停止老版本服务 一次发布小部分服务器 增量发布,让一部分用户试用新版本,无问题则迁移
方法 部署新旧两个版本,流量从旧版本切换到新版本 停止一部分服务器进行更新 少量服务器部署新版本,和旧版本服务器共存
优缺点 应用始终在线,不改动旧版本。遇到问题切换回旧版本 比蓝绿更新节省资源。修改了内容,回滚麻烦 A/B版本共存

参考文档

comments powered by Disqus

top