线上平稳发布(部署)手段:
-
蓝绿部署
-
灰度发布(金丝雀发布)
-
滚动发布
-
红黑部署
蓝绿部署:
定义:
蓝绿部署是不停老版本,部署新版本然后进行测试。确认OK后将流量切到新版本,然后老版本同时也升级到新版本。
特点:
蓝绿部署无需停机,并且风险较小。
部署过程:
蓝绿发布的注意事项:
当你切换到蓝色环境时,需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理,会是一个比较麻烦的问题。
- 可能会出现需要同时处理微服务架构应用和传统架构应用的情况,如果在蓝绿部署中协调不好这两者,还是有可能会导致服务停止。
- 需要提前考虑数据库与应用部署同步迁移/回滚的问题。
- 蓝绿部署需要有基础设施支持。
- 在非隔离基础架构( VM 、 Docker 等)上执行蓝绿部署,蓝色环境和绿色环境有被摧毁的风险
优势和不足
- 优势
升级切换和回退速度非常快。
- 不足
切换是全量的,如果 V2 版本有问题,则对用户体验有直接影响。需要两倍机器资源。
适用场合
- 对用户体验有一定容忍度的场景。
- 机器资源有富余或者可以按需分配(AWS 云,或自建容器云)。
灰度发布(金丝雀发布)
我们平常所说的金丝雀部署也是灰度发布的一种方式,在原有版本可用的情况下,同时部署一个新版本应用作为「金丝雀」服务器来测试新版本的性能和表现,以保障整体系统稳定的情况下,尽早发现、调整问题。
灰度发布/金丝雀发布由以下几个步骤组成:
- 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。
- 从负载均衡列表中移除掉「金丝雀」服务器。
- 升级「金丝雀」应用(排掉原有流量并进行部署)。
- 对应用进行自动化测试。
- 将「金丝雀」服务器重新添加到负载均衡列表中(连通性和健康检查)。
- 如果「金丝雀」在线使用测试成功,升级剩余的其他服务器(否则就回滚)。
除此之外灰度发布还可以设置路由权重,动态调整不同的权重来进行新老版本的验证。
优势和不足
- 优势
用户体验影响小,灰度发布过程出现问题只影响少量用户。
- 不足
发布自动化程度不够,发布期间可引发服务中断。
滚动发布(Rolling Update Deployment)
在金丝雀发布基础上的进一步优化改进,是一种自动化程度较高的发布方式,用户体验比较平滑,是目前成熟型技术组织所采用的主流发布方式。
1. 定义
滚动发布:一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有的实例都更新成新版本。
2. 特点
这种部署方式相对于蓝绿部署,更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署,例如每次只取出集群的 20% 进行升级。
3. 部署过程
- 滚动式发布一般先发 1 台,或者一个小比例,如 2% 服务器,主要做流量验证用,类似金丝雀 (Canary) 测试。
- 滚动式发布需要比较复杂的发布工具和智能 LB,支持平滑的版本替换和流量拉入拉出。
- 每次发布时,先将老版本 V1 流量从 LB 上摘除,然后清除老版本,发新版本 V2,再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
- 一次滚动式发布一般由若干个发布批次组成,每批的数量一般是可以配置的(可以通过发布模板定义)。例如第一批 1 台(金丝雀),第二批 10%,第三批 50%,第四批 100%。每个批次之间留观察间隔,通过手工验证或监控反馈确保没有问题再发下一批次,所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长,比如金丝雀 10 分钟,后续间隔 2 分钟)。
- 回退是发布的逆过程,将新版本流量从 LB 上摘除,清除新版本,发老版本,再将 LB 流量接入老版本。和发布过程一样,回退过程一般也比较慢的。
4. 优势和不足
- 优势
用户体验影响小,体验较平滑。
- 不足
发布和回退时间比较缓慢。发布工具比较复杂,LB 需要平滑的流量摘除和拉入能力。