Skip to main content

[DevOps] 代码更新方法

蓝绿部署

蓝绿部署,英文名 Blue Green Deployment,是一种可以保证系统在不间断提供服务的情况下上线代码的部署方式。

如何保证系统不间断提供服务呢?

蓝绿部署的模型中包含两个集群,就好比海豚的左脑和右脑。

在正常情况下(没有上线操作),集群 A 和集群 B 的代码版本是一致的,并且同时对外提供服务。

在有项目代码上线的时候,我们首先把一个集群(比如集群 A)从负载列表中摘除,进行新版本的部署。集群 B 仍然继续提供服务。

当集群 A 升级完毕,我们把负载均衡重新指向集群 A,再把集群 B 从负载列表中摘除,进行新版本的部署。集群 A 重新提供服务。

最后,当集群 B 也升级完成,我们把集群 B 也恢复到负载列表当中。这个时候,两个集群的版本都已经升级,并且对外的服务几乎没有间断过。

滚动更新

滚动更新,英文 Rolling update,同样是一种可以保证系统在不间断提供服务的情况下上线代码的部署方式。

和蓝绿部署不同的是,滚动部署对外提供服务的版本并不是非此即彼,而是在更细的粒度下平滑完成版本的升级。

如何做到细粒度平滑升级版本呢?

滚动部署只需要一个集群,集群下的不同节点可以独立进行版本升级。比如在一个 16 节点的集群中,我们选择每次升级 4 个节点:

以此类推,最终所有的节点都升级了版本。

灰度发布(A/B 测试、金丝雀部署)

灰度发布/金丝雀部署步骤:

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

  2. 从负载均衡列表中移除掉“金丝雀”服务器。

  3. 升级“金丝雀”应用(排掉原有流量并进行部署)。

  4. 对应用进行自动化测试。

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

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

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

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