微服务架构从入门到精通（四）微服务部署

       在微服务、DevOps、Cloud-native、系统部署等的讨论中，蓝绿发布、A/B 测试、灰度发布、滚动发布、红黑部署等概念经常被提到，它们究竟是什么呢？

一、蓝绿发布

1.1 什么是蓝绿发布

    蓝绿发布，英文名Blue Green Deployment，是一种最常见的0 downtime部署的方式，可以保证系统在不间断提供服务的情况下上线的部署方式。

    蓝绿部署原理上很简单，就是通过冗余来解决问题。通常生产环境需要两组配置（蓝绿配置），一组是active的生产环境的配置（绿配置），一组是inactive的配置（蓝绿配置）。用户访问的时候，只会让用户访问active的服务器集群。当蓝色环境（inactive）部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝色环境了。随后需要监测新版本应用，也就是version2 是否有故障和异常。如果运行良好，就可以删除version1 使用的资源。如果运行出现了问题，可以通过负载均衡器指向快速回滚到绿色环境。

1.2 蓝绿发布的弱点

使用蓝绿部署需要注意的一些细节包括：

1、当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果数据库后端无法处理，会是一个比较麻烦的问题。

2、有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止；

3、需要提前考虑数据库与应用部署同步迁移/回滚的问题。

4、蓝绿部署需要有基础设施支持。

5、在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。

6、另外，这种方式不好的地方还在于冗余产生的额外维护、配置的成本，以及服务器本身运行的开销。

1.3 蓝绿发布适用的场景

1、不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。

2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。

3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。

二、灰度发布/金丝雀发布

2.1 什么是灰度发布

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

灰度发布结构图：

灰度发布运行流程图：

2.2 灰度发布／金丝雀发布的几个步骤

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

2、从负载均衡列表中移除掉“金丝雀”服务器。

3、升级“金丝雀”应用（排掉原有流量并进行部署）。

4、对应用进行自动化测试。

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

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

灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

2.3 灰度发布/金丝雀部署适用的场景

1、不停止老版本，额外搞一套新版本，不同版本应用共存。

2、灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。

3、经常与A/B测试一起使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

三、滚动发布

3.1 什么是滚动发布

    滚动发布（rolling update）同样是一种可以保证系统在不间断提供服务的情况下上线的部署方式。和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。

3.2 滚动发布的步骤

        一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。

3.2 滚动发布的缺点

这种方式也有很多缺点，

(1) 上线过程中，两个版本同时对外提供服务，不容易定位问题，同时容易造成数据错乱。

(2) 升级或回滚以节点为粒度，操作相对复杂。

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

    总之，并不是说滚动发布不好，滚动发布也有它非常合适的场景。

四、红黑部署(Red-Black Deployment)

       这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，所以它利用AWS的特性，在部署新的版本时，通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。测试不通过，找到问题原因后，直接干掉新生成的服务器以及Autoscaling Group就可以，测试通过，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署一样得保持冗余的服务始终在线。

五、影子部署

       影子部署是指在版本A旁边发布版本B，将版本A进来的请求同时分发到版本B，同时对生产环境流量无影响。这是测试新特征在产品负载上表现的很好用的方式。当满足上线要求后，则触发发布新应用。

    这个技术配置非常复杂，而且需要特殊条件，尤其是分出请求。例如一个购物车平台，如果你想影子测试支付服务，你可能最终会是用户为他们的订单支付两次。这种情况下，可以通过创建一个仿真的服务来重复响应用户的请求。

---

    部署应用有很多种方法，实际采用哪种方式取决于需求和预算。当发布到开发或者模拟环境时，重建或者滚动部署是一个好选择。当发布到生产环境时，滚动部署或者蓝绿部署通常是一个好选择，但是新平台的主流程测试是必须的。

    蓝绿部署和影子部署对预算有更高的要求，因为需要双倍资源。如果应用缺乏测试或者对软件的功能和稳定性影响缺乏信心，那么可以使用金丝雀部署或者AB测试或者影子发布。如果业务需要根据地理位置、语言、操作系统或者浏览器特征等这样参数来给一些特定的用户测试，那么可以采用AB测试技术。

    切记，影子发布很复杂，且需要额外工作来模拟响应分支流量请求，当可变操作调用外部依赖时这是必须的，这个技术在升级新数据库是非常有用，使用影子流量来监控负载下的系统性能。