部署发布的几种思路：运维司机们，您都理解对了吗

《部署发布的几种思路：运维司机们，您都理解对了吗》要点：
本文介绍了部署发布的几种思路：运维司机们，您都理解对了吗，希望对您有用。如果有疑问，可以联系我们。

文章背景

1. 滚动部署、蓝绿部署、灰度发布/金丝雀发布、A/B测试等名词在讲述“微服务”、“DevOps”,甚至更抽象的“Cloud-native”的交付时可能会有所涉及,学习这几个名词作为基础打底；
2. 有几篇网络上浏览量较高的文章在这几者的所谓“对比说明”中,槽点太多,故而有了本文作为概念层面的纠正.

我们先明确一个概念,这些名词为两类：部署 VS 分布.

部署,针对环境而言；发布则是一种策略,需要在业务层面理解,包含如何发布、如何回滚、发布那些功能、哪些用户可以使用等等.

好了,先聊聊部署.

Blue/Green Deployment(蓝绿部署)

从过去到现在,蓝绿部署模式因为安全、可靠的实用特征,在很多大企业中落了地.

步骤：

1. 准备蓝、绿两个相同环境,蓝色跑旧版.
2. 部署v1(蓝),此时v1成为外部请求流量的靶子.
3. 部署v2(绿),此时v2状态为“备用”(负载均衡的池里把这些地址去掉),待v2启动成功,则自动测试备用集群的部署情况.
4. v2(绿)状态改成存货,蓝绿连接相同数据库,进入了存活负载均衡池,随后v1(蓝)同样操作.最终v2代码完成部署.
5. 视情况进行数据库迁移.

看似步骤麻烦,理解了还好.蓝绿部署无需停机,风险相对较小.

不过蓝绿部署在考虑到两个环境的在线服务随版本切换的特征,版本一致性和数据的一致性保证非常重要.

另外,在非隔离基础架构(VM、Docker等)上蓝绿部署有一定毁灭性风险,不是高手要慎用.

滚动部署

滚动发布,相对小众的市场,一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用.周而复始,直到集群中所有的实例都更新成新版本.

之所以小众,看缺点：

1. 没有一个环境确定ok,因为直接改了现有环境；
2. 既然没有环境确定ok,如果滚动发布到了第90个实例,需要回滚……程序猿可能会摔键盘；
3. 万一部署期间系统自动做了动态伸缩,不好判断哪个节点用了哪个代码.此时一款强大的自动化运维工具就派上用场了,but,有些运维部门没有呢；

灰度发布／金丝雀发布

灰度发布指版本在黑白之间平滑过渡,最传神写意的就是金丝雀部署.

“金丝雀部署”,在业界有两种策略形式：

1. 一种是部分服务器升级到新的版本.这种形式的重点在于,接入网关要精确的匹配某个特征的用户(灰度)流量导入到这批新版本集群中；
2. 另外一种是所有服务器升级新的版本.这种形式的重点在于,接入网关要精确的匹配某个特征的用户(灰度)流量使用到新接口；

A/B Testing(AB测试)

A/B测试和蓝绿部署是两码事,
A/B测试和蓝绿部署是两码事,
A/B测试和蓝绿部署是两码事,
重要的事情说三遍~

很多行业都有A/B测试的概念,A/B测试更像是用户侧的新旧版本机制,通过灰度一部分试验客户,使用A/B不同的效果,达到验证不同版本在可用性、受欢迎程度、可见性等等实际表现上的对比.

A/B测试是推广到全部流量可信新版前的科学验证方式,facebook改版就用过这个方式；蓝绿部署是直接发布到可信新版.

A/B测试和蓝绿部署可以同时使用,就像嵌套if,最后选定最受欢迎最靠谱的可信版本.

运维司机们,您看明白了吗?

原文来自微信公众号：DevOps研究院

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4304.html