发布

 在有关微服务、devops、Cloud-Native、系统部署等的讨论中

蓝绿部署、AB测试、灰度发布、滚动发布、红黑部署辨析如下：

1、蓝绿部署

原理很简单，就是通过冗余来解决问题。通常生产环境需要两组配置（蓝和绿），一组是active配置，一组是inactive配置。

用户访问的时候，只会让用户访问active的服务集群。在active环境运行当前生产环境的应用，也就是旧版本的应用v1，当你想要升级到v2，在inactive中进行操作，即部署新版本应用，并进行测试，

测试没问题后，就可以把负载均衡器／反向代理指向新版本服务了。随后需要检测新版本应用是否有故障。如果运行良好，就可以删除v1的资源，如果出现问题，通过负载均衡器快速回滚到原来的v1

优点：

你可以放心的部署inactive环境，出错不影响生产环境，如果切换后发生问题，可以在很短的时间内切换回去，完成回滚。无需停机，风险较小。

缺点：

当切换到新版本时，需要处理旧版本未完成的业务，例如：数据库后端数据交互 

冗余产生的配置和维护成本

 

2、AB测试

A/B 测试跟蓝绿部署是两码事，是用来测试应用功能表现的方法，例如：可用性、受欢迎程度等

蓝绿部署目的是安全稳定地发布新版本应用，并在必要时进行回滚

A／B测试通过实验设计、采样、流量分割等方式来获取代表性的实验结论,确信后推广到全部流量。

3、灰度发布／金丝雀

是指在黑与白之间，能够平滑过度的一种发布方式。是在原有版本可用的情况下，同时部署一个新版本作为“金丝雀”，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现问题。

步骤：

准备好部署需要的文件：配置文件、测试脚本、部署清单文件

从负载列表移除掉金丝雀服务器

升级金丝雀服务器应用

对服务进行测试

将金丝雀服务重新添加到负载

如果上线后服务正常，升级剩余其他服务器

灰度发布可以保证系统的稳定，在初始灰度的时候就可以发现问题

场景：

不停止老版本，额外搞一套新版本

按照用户设置权重，例如90%用户使用老版本，10%用户使用新版本。

 

滚动发布

一般是取出一个或者多个服务器停止服务，执行更新，并将其投入使用，周而复始，直到集群中所有的实例都更新为新版本。这种部署方式相对于蓝绿部署，更加节约资源，不需要运行两个集群

两倍的实例。

这种方式也有很多缺点，例如：

(1) 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。

(2) 修改了现有的环境。

(3) 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚。此时，脾气不好的程序猿很可能想掀桌子，因为回滚是一个痛苦，并且漫长的过程。

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

红黑部署

这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，所以它利用AWS的特性，

在部署新的版本时，通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。

测试不通过，找到问题原因后，直接干掉新生成的服务器以及Autoscaling Group就可以，

测试通过，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。

红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署那样得保持冗余的服务始终在线。