蓝绿部署

蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

然后对蓝色系统（新版本）然后进行测试。确认OK后将流量切到蓝色系统（新版本），监控系统运行，这个过程是必要的。因为没有人能够保证测试时100%的覆盖的，所以新集群可能会出现这样那样、或大或小的问题，如果评估需要回滚，就需要将全部流量切换到蓝色集群。也完成了版本回滚
优点：
服务文档，版本回退简单，适用于各种场景的升级，大版本不兼容升级的或迭代兼容升级
缺点：
浪费硬件资源，需要同时有两个集群，如果集群比较大，比如有1000个节点，这种方式几乎不可用
蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。

金丝雀发布（灰度发布）

我们平常所说的金丝雀部署也是灰度发布的一种方式，在原有版本可用的情况下，同时部署一个新版本应用作为「金丝雀」服务器来测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。

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

灰度发布／金丝雀发布由以下几个步骤组成：

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

从负载均衡列表中移除掉「金丝雀」服务器。

升级「金丝雀」应用（排掉原有流量并进行部署）。

对应用进行自动化测试。

将「金丝雀」服务器重新添加到负载均衡列表中（连通性和健康检查）。

如果「金丝雀」在线使用测试成功，升级剩余的其他服务器（否则就回滚）。

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

优势和不足

优点
小步快跑，快速迭代
用户体验影响小，灰度发布过程出现问题只影响少量用户。
缺点
只能适用于兼容迭代的方式，如果是大版本不兼容的场景，就没办法使用这种方式了

滚动发布

一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。

发布流程:

相对于蓝绿发布需要一套完备的机器不同, 滚动发布只需要一台机器, 我们只需要将部分功能部署在这台机器上, 然后去替换正在运行的机器, 如上图, 将更新后的功能部署在Server1 上, 然后Server1去替换正在运行的Server, 替换下来的物理机又可以继续部署Server2的新版本, 然后去替换正在工作的Server2 , 以此类推, 直到替换完所有的服务器, 至此 ,服务更新完成。

滚动发布特点
这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。

回滚困难

滚定发布注意事项
滚动发布没有一个确定可行的环境。使用蓝绿部署，我们能够清晰地知道老版本是可行的，而使用滚动发布，我们无法确定。

修改了现有的环境。

回滚困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚，这个回滚却是一个痛苦，并且漫长的过程。

有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。

因为是逐步更新，那么我们在上线代码的时候，就会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题。
优点

用户体验影响小，体验较平滑。

缺点

发布和回退时间比较缓慢。

发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力。

AB测试

A/B测试和蓝绿发布、金丝雀发布以及滚动发布，完全是两回事。

蓝绿发布、滚动发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。

A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。

A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。

A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本