上线这个事,不可避免,而且一定是承担风险的。尤其是一些用户量巨大的应用,一不留神,产生的影响也是小不了的。所有,在业界,有着很多种发布上线的策略或者说是机制,用来减少上线所带来的风险。 据了解,比较常见的几种部署方式有以下几种: 蓝绿部署这种部署方式,目的是减少发布过程中服务不可用的时间,以及部署的新版本的正确性检测。 发布的流程如下: 首先,得要有2套基础设施。还得有load balance,不然流量无法隔离,也是难以实现蓝绿部署方案。 上面的2个集群,我们可以将绿色集群的状态称为’备用’集群. 当我们需要做蓝绿部署的事情,从同一接入模块将流量切掉 ,这样,绿色的集群将不接受用户的流量,可以用来新的服务。 在绿色集群里面,开始部署新的版本B。在这里,我们也会有一定的验收工作来保障新版本B一定是可用的。 引入一些自动化的测试流量进行验收。 当确认绿色集群的版本OK,可用将流量从蓝色集群切换到绿色集群。切换完成后,对蓝色集群进行新版本的部署、 等待蓝绿集群全部部署到B,整个流程就可以结束,全部集群可对外恢复服务。
分批部署(滚动部署)依然是比较常见的一种部署方式,每次只更新一小部分服务器。(发布批次是可以调整的,但得保证在部署过程中,停止这部分服务,线上服务不会有较大的影响) 灰度发布灰度发布也称为金丝雀部署。(这个名字的来源是因为一个小股数,以前矿井工人发现,金丝雀对瓦斯极敏感,于是矿井工人在进行工作之前,会放出金丝雀下去矿井检查下瓦斯的情况,以便及时发发现危险,演变到后期就变成了一种系统稳定性保障的策略) 灰度发布其实算是一种验收测试,线上进行灰度版本测试,用来保障整体系统的稳定性。同时,也能与我们常见的AB testing的一种部署方式,线上AB版本共存,进行流量比较。 原有版本可用的情况下,同时部署的一个新版本应用作为“金丝雀”版本(灰度版本),测试新版本的性能和表现,可以尽早发现问题、调整问题。 灰度发布/金丝雀发布由以下几个步骤组成: 准备好部署各个阶段的工件,包括:构建组件,测试脚本,配置文件和部署清单文件。 从负载均衡列表中移除掉“金丝雀”服务器。 升级“金丝雀”应用(排掉原有流量并进行部署)。 对应用进行自动化测试。 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)
原创:metaboy
|