蓝绿发布的目的是
减少发布时的中断时间
、
能够快速撤回发布
。
It’s basically a technique for releasing your application in a predictable manner with an goal of reducing any downtime associated with a release. It’s a quick way to prime your app before releasing, and also quickly roll back if you find issues.
蓝绿发布中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。
两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。
最初，没有任何系统，没有蓝绿之分。
然后，第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分。
后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统之外搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
蓝色系统不对外提供服务，用来做啥？
用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）
蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统：
切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。
当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。 原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。
蓝绿发布只是上线策略中的一种，它不是可以应对所有情况的万能方案。 蓝绿发布能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。
金丝雀发布（Canary）也是一种发布策略，和国内常说的
灰度发布
是同一类策略。
蓝绿发布是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。
譬如说，目标系统是一组无状态的Web服务器，但是数量非常多，假设有一万台。这时候，蓝绿发布就不能用了，因为你不可能申请一万台服务器专门用来部署蓝色系统（在蓝绿发布的定义中，蓝色的系统要能够承接所有访问）。
可以想到的一个方法是： 只准备几台服务器，在上面部署新版本的系统并测试验证。测试通过之后，担心出现意外，还不敢立即更新所有的服务器。 先将线上的一万台服务器中的10台更新为最新的系统，然后观察验证。确认没有异常之后，再将剩余的所有服务器更新。这个方法就是金丝雀发布。
金丝雀发布（canary release）的命名原因：
人们发现金丝雀这种生物对于有毒气体很敏感。因此矿工在下井采矿之前会把金丝雀鸟儿投入或携带到矿井中，如果鸟儿能够从矿井中飞出就表示井下有氧气，矿工就可以安心下井采矿了。
通过这个故事，我们就可以看出金丝雀部署就是先把新版本试水的一部分就叫金丝雀发布。金丝雀发布可以快速而有效地发现软件新版本存在的问题。
它的原理就是部署的时候让一小部分用户先试用功能 ，通过日志监控或者服务器监控，看下新用户的反馈。如果没有严重问题，尽快部署这个新版本，否则快速会退。小代价去试错
金丝雀发布（canary release）实际操作中还可以做更多控制，譬如说给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。
这个控制叫做“
流量切分
”，既可以用于金丝雀发布，也可以用于后面的A/B测试。
金丝雀部署也就是灰度发布的一种方式。
蓝绿发布和金丝雀发布是两种发布策略，都不是万能的。
有时候两者都可以使用，有时候只能用其中一种。
上面的例子中可以用金丝雀，不能用蓝绿，那么什么时候可以用蓝绿呢？整个系统只有一台服务器的时候。或者说有足够的资源，同时支撑运行两套系统的时候。
金丝雀发布缺点： 自动化流程不够，发布期间需要人为去操作，可能会引起服务中断等。
滚动发布是在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。
一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。
例如，第一批1台（金丝雀），第二批10%，第三批 50%，第四批100%。
每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀10 分钟，后续间隔 2分钟)。
首先需要明确的是，A/B测试和蓝绿发布以及金丝雀，完全是两回事。
蓝绿发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿发布的方式）。
A/B测试关注的是不同版本的服务的实际效果
，譬如说转化率、订单情况等。
A/B版本
一般A/B版本用在创业公司第一次发布新版本时，不清楚顾客更喜欢哪一个新版本的时候用的。
同时部署A和B两个版本，通过后台统计数据，分析顾客更喜欢哪一个版本，然后选择这个版本上线。在新产品抢占市场份额时作用巨大。
A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。
在A/B测试中，需要能够控制流量的分配，譬如说，为A版本分配10%的流量，为B版本分配10%的流量，为C版本分配80%的流量。
spring cloud 灰度的实操方案比较多：
方案一
：spring cloud gateway也可以实现灰度发布，
方案二
：还有一款 spring cloud 的Discovery增强组件，可以实现灰度、蓝绿等功能（https://github.com/Nepxion/Discovery）
简单来说，灰度发布实质是让指定用户访问指定版本的服务。
spring cloud gateway也可以实现灰度发布大概的思路：
首先，需要指定用户匹配到指定的路由规则。
其次，服务的版本号信息可以通过HTTP请求头字段来指定。
最后，负载均衡算法需要能够根据版本号信息来做服务实例的选择。
在实操层面，spring cloud gateway 灰度发布的实现思路应该比较简单：
1、首先编写自己的Predicate，实现指定用户匹配到指定的路由规则中；
2、动态修改请求，添加版本号信息，版本号信息可以放在HTTP Header中（此处可以通过原生AddRequestHeaderGatewayFilterFactory来实现，无需自己写代码）；
3、自定义路由规则，重写负载均衡算法，根据版本号信息从注册中心的服务实例上选择相应的服务版本进行请求的转发。
具体的方案，后面在尼恩的《SpringCloud 学习圣经》PDF中，进行补充。
Kubernetes 中常见的发布策略主要有如下六种：
重建
（recreate) ：即停止一个原有的容器，然后进行容器的新建。
滚动更新
（rollingUpdate) ：停掉一个容器，然后更新一个容器。
蓝绿布署
（blue/green ）：准备一套蓝色的容器和一套绿色的容器，进行流量切换。
金丝雀发布
（canary) ：更新部分容器，没有问题后进行逐步替换，直到切完。
A/B测试发布
：即将发布的结果面向部分用户，这块没有现成的组件，需要进行自行处理，比如使用 Istio、Linkerd、Traefik 等。这种方式采用在 Http 的 Header 上进行处理。
无损发布
：现在很多发布都是将容器停掉，当没有请求的时候发布，实现无损发布。
