蓝绿部署(Blue Green Deployment):
布署过程:
- 集群A部署版本1的应用(一开始的状态)
所有外部请求的流量都打到集群A上。 - 集群B部署版本2的应用
版本2的代码与版本1不同(新功能、Bug修复等)。 - 利用负载均衡将所有流量从集群A切换到集群B, 即版本1切换到版本2。
- 如版本2测试正常,就删除版本1正在使用的资源(例如实例),从此正式用版本2。
实际使用方式:
方式一:
1. 平时, 集群A部署着版本1, 所有外部请求的流量都打到集群A上。集群B闲置。
2. 版本升级时, 集群B部署版本2的应用。
3. 利用负载均衡将所有流量从集群A切换到集群B, 即版本1切换到版本2。
4. 如版本2测试正常,则集群A就删除版本1正在使用的资源(例如实例),从此正式用集群B。集群A闲置。
5. 如版本2有问题, 利用负载均衡将所有流量从集群B切换回集群A, 版本回退非常快速;
相比方式二:
1. 优点: 部署期间可用节点不变, 页面最大并发量不下降。
2. 缺点: 需要维护两个集群,成本高。 平时一个集群闲置。平时需要10个节点, 部署需要20个节点。
方式二:
1. 平时, 集群A和集群B都部署着版本1, 根据负载均衡将流量分配到集群A和集群B。
2. 版本升级时, 将集群B从负载均衡列表中摘除, 集群B部署版本2的应用。这时所有流量都打到了集群A, 假设集群都是10个节点, 则可用节点从20个减小到10个。
3. 当集群B部署版本2完成, 我们重新把集群B添加到负载均衡列表中; 再把集群A从负载列表中摘除,进行新版本的部署。集群B重新提供服务(版本2)。
4. 如版本2测试正常,则集群A也部署版本2; 当集群a部署版本2完成, 我们重新把集群A添加到负载均衡列表中。
5. 如版本2有问题, 利用负载均衡将所有流量从集群B切换回集群A, 版本回退非常快速;
相比方式一:
1. 优点: 没有集群闲置。
2. 缺点: 需要维护两个集群,成本高。 部署期间可用节点减半, 页面最大并发量下降。
滚动部署:
布署过程:
- 滚动式发布一般由若干个发布批次组成。例如第一批 1 台节点,第二批 10%节点,第三批 50%,第四批 100%。
- 滚动式发布需要比较复杂的发布工具和智能 LB,支持平滑的版本替换和流量拉入拉出。
每次发布时,先将该批次的节点从 负载均衡列表 上摘除,然后清除老版本,发新版本 V2,再重新添加到 负载均衡列表 。这样可以尽量保证用户体验不受影响。
优点:
1. 只需要维护一个集群,成本低。
缺点:
1. 上线过程中,两个版本同时对外服务,不易定位问题,且容易造成数据错乱。
2. 升级和回滚以节点为粒度,操作相对复杂。
灰度部署(又名金丝雀发布):
灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。
在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。
布署过程:
1. 先将一个节点a冲负载均衡列表中摘除, 节点a部署版本2。
2. 当节点b部署版本2完成后, 将节点a重新添加到负载均衡列表中;
3. 与 滚动发布是流量随机有可能打到节点a 不同, 灰度发布根据配置将部分用户的流量指定打到节点a, 体验测试版本2。
4. 当确认新版本2运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的节点数量,以使得新版本2能够承受越来越大的流量压力。直到将100%的流量都切换到新版本2上,最后关闭剩下的老版本服务,完成灰度发布。
总结对比:
部署方式 | 简述 | 优势 | 劣势 |
蓝绿部署 | 不停止老版本,额外搞一套新版本,等测试发现新版本OK后,删除老版本 | 1.同一时间对外服务的只有一个版本,容易定位问题;2.升级和回滚以集群为粒度,操作相对简单 | 需要维护两个集群,成本高 |
滚动部署 | 按批次停止老版本实例,启动新版本实例 | 只需要维护一个集群,成本低 | 1. 上线过程中,两个版本同时对外服务,不易定位问题,且容易造成数据错乱;2.升级和回滚以节点为粒度,操作相对复杂 |
灰度发布/金丝雀部署 | 不停止老版本,额外搞一套新版本,按照用户设置路由权重,如90%的用户维持使用老版本,10%的用户尝鲜新版本 | 不同版本应用共存,常用于A/B测试;新版本尝鲜体验反馈;用户体验影响小,灰度发布过程出现问题只影响少量用户 | 实现方案相对复杂,需要实现发布自动化 |