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