微服务部署：蓝绿部署、滚动部署、灰度部署（金丝雀部署）

简介

产品或者项目不可能一步到位，一次性推向用户，故而有版本的存在。在app版本更新或者项目迭代的过程中，不可避免需要发布。发布就是部署/重新部署；部署就是修改；修改则意味着风险。
目前有很多用于部署的技术，本文将目前常用的布署方案做一个总结。
备注：本文不具有多少原创性，多是网络资源的整理，加上个人的理解。
分类
蓝绿部署

Blue/Green Deployment
定义
蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。

特点
蓝绿部署无需停机，并且风险较小。

布署过程

    部署版本1的应用（一开始的状态）
    所有外部请求的流量都打到这个版本上。
    部署版本2的应用
    版本2的代码与版本1不同(新功能、Bug修复等)。
    利用负载均衡将流量从版本1切换到版本2。
    如版本2测试正常，就删除版本1正在使用的资源（例如实例），从此正式用版本2。

小结
在部署的过程中，应用始终在线，保证系统在不间断提供服务。新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上可以在任何时间回滚到老版本。

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

    可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。
    需要提前考虑数据库与应用部署同步迁移 /回滚的问题。
    蓝绿部署需要有基础设施支持。
    在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。

优势和不足
优势：升级切换和回退速度非常快。
不足：切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；需要两倍机器资源。

适用场合
对用户体验有一定容忍度的场景。
机器资源有富余或者可以按需分配（AWS 云，或自建容器云）。

为什么需要蓝绿发布系统？
新项目和新需求非常多。
新需求的上线过程是，先上线一台服务器然后观察会不会出问题，如果没有问题则全部上线。
分流是关键，但是动态分流是痛点。

老分流方案
外界请求到达nginx，nginx 负载均衡实现分流到配置的upstream1~3
该方案存在的问题点：
nginx.conf配置文件里各种if、set和rewrite，并且容易配置出错。
修改完配置文件后，重启或者reload后才能生效。
不能实现太复杂的逻辑。
不能实现一些特殊分流方式。

新分流方案

功能说明：
采用Redis存放分流策略；
分流策略包括按时间来分流，比如每分钟分流多少笔订单；还有按权重分流，比如新老系统之间的比例是1:9；
采用OpenResty+lua，整体性能优秀。
Rolling update（滚动发布）

定义
一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。

特点
这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数；滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。可以部分部署，例如每次只取出集群的20%进行升级。

部署过程

    滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。
    滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。
    每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
    一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。
    回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。

优势和不足
优势：用户体验影响小，体验较平滑。
不足：
(1) 没有一个确定OK的环境。使用蓝绿部署，确定老版本是OK的，滚动发布无法确定。
(2) 修改现有的环境。
(3) 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚，这个回滚却是一个痛苦，并且漫长的过程。
(4) 有时还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，还需判断到底哪个节点使用的是哪个代码。
(5) 因为是逐步更新，在上线代码版本时，就会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题。
发布和回退时间比较缓慢；发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力。
灰度发布/金丝雀部署

定义
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
金丝雀部署也就是灰度发布的一种方式，是增量发布的一种。在原有版本可用的情况下，同时部署一个新版本应用作为「金丝雀」服务器来测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。同时运行同一个软件产品的多个版本，需要软件针对配置和完美自动化部署进行特别设计。

A/B Testing
A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。 A/B 测试通常用在应用的前端上，不过当然需要后端来支持。
A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。

步骤：

    准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
    从负载均衡列表中移除掉“金丝雀”服务器。
    升级“金丝雀”应用（排掉原有流量并进行部署）。
    对应用进行自动化测试。
    将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
    如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。不同版本应用共存，经常与A/B测试一起使用，用于测试选择多种方案。灰度发布还应该可以动态调整不同的权重来进行新老版本的验证。
其它发布方式

上述都是偏传统的发布方式，能覆盖大部分应用发布场景。针对一些关键新功能的上线发布，或者一些特定的场景，还有一些特殊的发布方式。
功能开关发布

利用代码中的功能开关（Feature Flag/Toggle/Switch）来控制发布逻辑，一般不需要复杂的发布工具和智能 LB 配合，是一种低成本和简单的发布方式。这种方式也是支持现代 DevOps 理念，研发人员可以灵活定制和自助完成的发布方式。

部署过程

    功能开关发布需要一个配置中心或者开关中心这样的服务支持，这些都支持开关发布。业界还有专门的功能开关 SaaS 服务，例如 LaunchDarkly。通过配置中心，运维或研发人员可以在运行期动态配置功能开关的值。当然，功能开关发布只是配置中心的一种使用场景，配置中心还能支持其它很多动态配置场景。
    功能开关服务一般提供客户端 SDK，方便开发人员集成。在运行期，客户端 SDK 会同步最新的开关值，技术实现有推方式 (push)，也有拉方式 (pull)，或者推拉结合方式。
    新功能（V2）和老功能（V1）住在同一套代码中，新功能隐藏在开关后面，如果开关没有打开，则走老代码逻辑，如果开关打开，则走新代码逻辑。可以理解为一个简单的 if/else 逻辑。
    应用上线后，开关先不打开，然后运维或研发人员通过开关中心打开新功能，经过流量验证新功能没有问题，则发布完成；如果有问题，则随时可以通过开关中心切回老功能逻辑。

优势和不足
优势：
升级切换和回退速度非常快；
相对于复杂的发布工具，实施比较简单，成本相对低廉；
研发能够灵活定制发布逻辑，支持 DevOps 自助发布。
不足：
切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；
对代码有侵入，代码逻辑会变复杂，需要定期清理老版本逻辑，维护成本变高。
影子测试

影子测试：对于一些涉及核心业务的遗留系统的升级改造，为了确保万无一失，采用比较复杂的流量复制、回放和比对技术实现。架构图：

部署过程
影子测试一般适用于遗留系统的等价重构迁移，如 .net 转 Java，或者 SQLServer 升级为 MySQL，且外部依赖不能太多，否则需要开发很多 mock，测试部署成本会很高，且比对测试更加复杂和不稳定。
目标实现老的 legacy 服务迁移升级到新的 experimental 服务。
测试开始前，需要在测试环境部署一份 legacy 服务和 experimental 服务，同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来，一般可以通过 kafka 队列收集，然后通过类似 goreplay 这样的工具，消费 kafka 里头的请求日志，复制回放，将请求分发到 legacy 服务和 experimental 服务，收到响应后进行比对，如果所有响应比对成功，则可以认为 legacy 服务和 experimental 服务在功能逻辑上是等价的；如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复 experimental 并重新进行影子测试，直到全部比对成功。根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达半年之久。
影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响。

优势和不足
优势：
对生产用户体验完全无影响；
可以使用生产真实流量进行测试（复制比对）。
不足：
搭建复杂度很高，技术门槛高，数据库的导出复制是难点；
外部依赖不能太多，否则测试部署成本很高，且比对测试更加复杂和不稳定。
总结对比
部署方式     简述     优势     劣势
蓝绿部署     不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本     1.同一时间对外服务的只有一个版本，容易定位问题；2.升级和回滚以集群为粒度，操作相对简单     需要维护两个集群，成本高
滚动部署     按批次停止老版本实例，启动新版本实例     只需要维护一个集群，成本低     1. 上线过程中，两个版本同时对外服务，不易定位问题，且容易造成数据错乱；2.升级和回滚以节点为粒度，操作相对复杂
灰度发布/金丝雀部署     不停止老版本，额外搞一套新版本，按照用户设置路由权重，如90%的用户维持使用老版本，10%的用户尝鲜新版本     不同版本应用共存，常用于A/B测试；新版本尝鲜体验反馈；用户体验影响小，灰度发布过程出现问题只影响少量用户     实现方案相对复杂，需要实现发布自动化
参考/推荐阅读

微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布
金丝雀发布、滚动发布、蓝绿发布到底有什么差别？关键点是什么？
BlueGreenDeployment-Martin Fowler
在生产中使用金丝雀部署来进行测试
Blue-green Deployments, A/B Testing, and Canary Releases
基于Nginx+lua的蓝绿发布系统
Using Blue-Green Deployment to Reduce Downtime and Risk
蓝绿发布的整个部署过程
Kubernetes之蓝绿部署
————————————————
版权声明：本文为CSDN博主「johnny233」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lonelymanontheway/article/details/87911666