=Start=
缘由：
前段时间看到有人问蓝绿部署、灰度部署、金丝雀部署的概念和他们之间的区别，刚好我也不清楚，所以顺便搜索学习一下。在此整理、学习一下相关概念，方便以后参考。
正文：
参考解答：
在一般情况下，升级服务器端应用，需要将应用源码或程序包上传到服务器，然后停止掉老版本服务，再启动新版本。但是这种简单的发布方式存在两个问题，一方面，在新版本升级过程中，服务是暂时中断的，另一方面，如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。为了解决这些（服务中断、失败回滚、……）问题，人们研究出了多种发布策略。
1、蓝绿部署 – BlueGreenDeployment
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.
蓝绿部署的目的是——减少因发布导致的服务中断时间，同时它也支持发布失败时的快速回滚。
蓝绿部署需要在发布过程中，同时运行两套程序。对硬件的要求也是当前所需的2倍，比如当前运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置20台服务器。
2、滚动发布/更新
所谓滚动发布，就是在发布过程中，并不一下子启动所有新版本，而是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到全部发布完成，这样的话，如果当前需要10台服务器支撑服务，那么升级过程中一共只需要11台就行了。
滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。
但是滚动发布有一个问题，在开始滚动发布后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定稳定/符合预期的，可能需要进一步的测试才能确认。那么在滚动发布期间，整个系统就处于较为不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。
为了解决这个问题，我们需要为滚动发布实现流量控制能力。也就是下面的金丝雀发布/灰度发布。
2.1、金丝雀发布 – CanaryRelease (也叫灰度发布)
17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
金丝雀发布(Canary Releases)名称的由来
金丝雀发布指的是在生产环境中分阶段逐步更新后端应用的版本（需要具备流量控制能力），在小范围验证符合预期之后，再推广至整个生产环境。
金丝雀发布的好处在于可以用真实环境测试新版本，当新版本存在问题时最多只影响部分用户，且支持安全快速的回滚策略（将路由到新版本上的流量切换到其它的老版本机器上即可）。
但金丝雀发布并不是完美的，如果新版本有问题，那么路由到新版本的小部分流量会有问题，就跟矿井中毒发身亡的金丝雀一样。这种做法在非常敏感的业务中几乎无法接受，但是当系统复杂的到一定程度，错误无法完全避免的时候，为了避免出现更大的问题，牺牲一小部分流量，就可以将大部分错误的影响控制在一定范围内。
A/B测试 – A/B Testing
首先需要明确的是，A/B测试和蓝绿部署以及金丝雀发布，完全是不同类型的概念。
蓝绿部署和金丝雀发布是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。
A/B测试是效果测试（一般用来验证某个想法是否符合预期），同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分。它关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。
A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，以选出效果最好的版本。
参考链接：
BlueGreenDeployment
https://martinfowler.com/bliki/BlueGreenDeployment.html
CanaryRelease
https://martinfowler.com/bliki/CanaryRelease.html
Continuous Integration
https://martinfowler.com/articles/continuousIntegration.html
Continuous Delivery
https://martinfowler.com/books/continuousDelivery.html
Blue-green Deployments, A/B Testing, and Canary Releases
https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/
蓝绿部署、金丝雀发布（灰度发布）、A/B测试的准确定义
https://www.lijiaocn.com/%E6%96%B9%E6%B3%95/2018/10/23/devops-blue-green-deployment-ab-test-canary.html
部署策略对比：蓝绿部署、金丝雀发布及其他
https://www.infoq.cn/article/LEI4vSFPiw5A6eN-ASo4
https://rollbar.com/blog/deployment-strategies/
金丝雀发布
http://blog.lfyzjck.com/14807508681806.html
首富带你畅谈:蓝绿部署、滚动发布、灰度发布/金丝雀发布
https://www.cnblogs.com/gao88/p/11276925.html
蓝绿部署、金丝雀发布（灰度发布）、AB测试
https://www.howardliu.cn/blue-green-deployments-a-b-testing-and-canary-releases/
第十六章 灰度发布（直译：金丝雀部署）
https://jdsre.gitbook.io/sre2/di-shi-liu-zhang
灰度发布、滚动发布、蓝绿部署和两种测试方法
http://www.bewindoweb.com/231.html
蓝绿部署、A/B测试以及灰度发布
https://www.v2ex.com/t/344341
蓝绿部署、金丝雀发布（灰度发布）、A/B测试的准确定义
https://www.cnblogs.com/lijiaocn/p/9986880.html
微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布
https://www.jianshu.com/p/022685baba7d
金丝雀发布、滚动发布、蓝绿发布到底有什么差别？关键点是什么？
https://mp.weixin.qq.com/s/Qm17HKA86WOOSG_UIm3xkA
蓝绿发布、滚动发布、灰度发布等部署方案对比与总结
http://www.yunweipai.com/archives/25338.html
一文搞懂蓝绿发布、灰度发布和滚动发布
https://blog.51cto.com/lizhenliang/2400452
什么是蓝绿部署、滚动发布和灰度发布？
https://zhuanlan.zhihu.com/p/42671353
Colorful deployments: An introduction to blue-green, canary, and rolling deployments
https://opensource.com/article/17/5/colorful-deployments
Blue Green Deployments vs Rolling Deployments?
https://stackoverflow.com/questions/42358118/blue-green-deployments-vs-rolling-deployments
=END=
《 “蓝绿部署、金丝雀部署的含义和区别” 》 有 6 条评论
有赞灰度发布与蓝绿发布实践
https://mp.weixin.qq.com/s/8SFtHdivnHAbQ4qq6diN5Q
什么是蓝绿部署？
https://www.zhihu.com/question/50713290
`
1. 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。
2. 灰度是选择部分部署新版本，将部分流量引入到新版本，新老版本同时提供服务。等待灰度的版本OK，可全量覆盖老版本。
灰度是不同版本共存，蓝绿是新旧版本切换，2种模式的出发点不一样。
`
灰度部署、滚动部署与蓝绿部署
https://juejin.im/post/5cb1e40a6fb9a068846b877a
微服务部署：蓝绿部署、滚动部署、灰度发布等部署方案对比与总结
http://www.itmuch.com/work/microservice-deploy/
微服务治理实践 | 金丝雀发布
https://mp.weixin.qq.com/s/T6mn1Pydhv6zRWUTzihf9A
`
# 金丝雀发布实现细节
Apache Dubbo 金丝雀底层实现的原理是通过 Java Agent 技术动态添加一个 Router，该 Router 内部使用了 Spring 的表达式 SPEL 进行参数，表达式解析结果判断是否需要对 Invoker 列表进行修改。如果是常规请求，删除灰度节点；如果是灰度请求，删除正常节点。
Spring Cloud 金丝雀底层的实现细节是对 ILoadBalancer 接口对应的实现类返回的 Server 列表进行修改。如果是常规请求，删除灰度节点；如果是灰度请求，删除正常节点。
这里如何判断哪些节点是灰度节点呢？这会跟应用发布流程绑定，当使用 ECS 集群需要选择灰度分组，K8s 集群需要填写灰度 Pod 个数。这些灰度实例或灰度 Pod 启动的时候会带上一个灰度标表示自己是一个灰度实例或 Pod(Spring Cloud 写入到 metadata 持久化到注册中心；Apache Dubbo 写入到 custom parameter 持久化到注册中心)。
另外一个问题: 灰度规则如何保存呢？我们在 Agent 里通过 Nacos Configuration 的监听去监听对应 dataId 的数据变化，这里的 dataId 跟每个应用 id 绑定(应用 id 也通过跟灰度标一样的机制持久化到注册中心)。每次应用发布都会在 id 对应的 dataId 中写入灰度规则，Agent 监听并在内存进行修改。
`
怎样才是真正的灰度发布？
https://mp.weixin.qq.com/s/NAegHaXJwDrkzjeCW8Ql-Q
`
究竟什么才是灰度发布其实并没有一个严格的标准，因为这个东西不是黑的也不是白的是个中间过渡地带，这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品，有意思的是他们实现的是完全不一样的功能，对外都说自己是灰度发布。我看到的有三种：
1. 更新过程可以暂停，停在一个既有新版本又有旧版本的状态，然后选择升级或者回滚
2. 支持流量比例分配，可以把百分之几的流量分配给一个服务，剩下的给另一个服务
3. 支持 url 路径流量分配，一个路径下的流量给一个服务，另一个路径流量给另一个服务
了解了需求，我们就很容易推导出所有人都在说的灰度发布真正是什么了
1. 精确的流量分发控制
2. 监控系统的支撑
3. 灵活的发布系统
说了这么写灰度系统要做的事情其实就是流量控制和数据收集，来控制风险并帮助产品做决策。再看一下最开始提出的三个所谓的灰度发布：更新过程可以暂停，流量比例分配，url分流。它们充其量也只是做到了流量精确分配的某几个特殊情况，而且还都是不很精确的分配。而如果结合使用场景就会发现，这几种在实际中是很难用起来的，因为没有流量的精确控制很难控制风险范围，如果风险都不可控，那还要灰度发布干什么呢？更不要提后面的监控数据收集和灵活的发布了。
所以说一个真实好用的发布系统是十分复杂的，绝对不是页面上点两三下就可以完成的，而后面的实现更需要一整套体系来支撑。如果你想打造一个灰度发布系统，希望这篇文章能对你有所启发。
`
一文读懂蓝绿发布、A/B 测试和金丝雀发布的优缺点
https://mp.weixin.qq.com/s/KBxQEqUT-4lROBMvWv-W5A
`
被业界广泛采用的服务发布策略包括蓝绿发布、A/B 测试以及金丝雀发布。
一.蓝绿发布
蓝绿发布需要对服务的新版本进行冗余部署，一般新版本的机器规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进行版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。由于冗余部署的缘故，所以不必担心新版本的资源不够。如果新版本上线后出现严重的程序 BUG，那么我们只需将流量全部切回至旧版本，大大缩短故障恢复的时间。待新版本完成 BUG 修复并重新部署之后，再将旧版本的流量切换到新版本。
蓝绿部署的优点：
1.部署结构简单，运维方便；
2.服务升级过程操作简单，周期短。
蓝绿部署的缺点：
1.资源冗余，需要部署两套生产环境；
2.新版本故障影响范围大。
二.A/B 测试
相比于蓝绿发布的流量切换方式，A/B 测试基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于 Http Header 和 Cookie。基于 Http Header 方式的例子，例如 User-Agent 的值为 Android 的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。基于 Cookie 方式的例子，Cookie 中通常包含具有业务语义的用户信息，例如普通用户可以访问新版本，VIP 用户仍然访问旧版本。
A/B 测试的优点：
1.可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；
2.需要构建完备的监控平台，用于对比不同版本之间请求状态的差异。
A/B 测试的缺点：
1.仍然存在资源冗余，因为无法准确评估请求容量；
2.发布周期长。
三.金丝雀发布
在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占用的机器规模为新版本克隆一套环境，相当于要求原来1倍的机器资源。在 A/B 测试中，只要能够预估中匹配特定规则的请求规模，我们可以按需为新版本分配额外的机器资源。相比于前两种发布策略，金丝雀发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。
金丝雀发布的优点：
1.按比例将流量无差别地导向新版本，新版本故障影响范围小；
2.发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。
金丝雀发布的缺点：
1.流量无差别地导向新版本，可能会影响重要用户的体验；
2.发布周期长。
`
[…] reference：https://ixyzero.com/blog/archives/4722.html […]
应用不停机发布的思考与初识
https://mp.weixin.qq.com/s/OgOQtKmfBmCp7-uWkvmGtw
`
应用发布，简单来说就是将已开发完成的系统功能部署到生产环境，并可正常对用户提供服务。
传统的应用发布步骤一般采用“三步曲”：
第一步：停止应用
第二步：更新应用
第三步：启动应用
那你肯定会问，从停止应用一直到启动应用期间，系统功能是不是无法正常使用？
没错。在应用发布过程中，可能会出现页面白屏、访问超时等各种异常，而且一般会持续很久，所以发布时间基本上都集中在凌晨，讲究点的可能就配上一句友好提示“系统正在维护，请稍后访问！”。
这种情况大部分都出现在传统行业，原因可能是觉得没有必要，因为：
1.传统行业的业务一般都集中的日间，也就是说凌晨基本没有业务，或者非重要业务
2.就算凌晨无法使用这些功能，觉得也没关系，第二天再来就是了，客户又不会跑了
但真的是这样吗？如今越来越多的传统行业，都在向互联网服务模式转型，其服务主要特点：“全天”不间断为客户提供“优质”的“线上”服务，拆分一下关键词
1.“全天”代表着任何时间
2.“优质”代表着客户体验
3.“线上”代表着线上自助
所以说，一个优质的客户服务势必会对服务可用性提出更高的要求，而传统的停机发布不但会对客户造成使用影响，还会变向对企业造成非直接经济损失。
例如：客户体验下降导致的客户流失
仅此而已？非也！作为曾经也同样是一名运维工程师的我来说，凌晨发布家常便饭，还时不时来一次长达8小时的“长途之旅”，身体就直接被掏空，加上第二天还在“补血”中，还会被各种骚扰电话轰炸，这简直就是一场噩梦。
由此可见，应用不停机发布的重要性，通过它可以帮助我们：一是在应用发布过程中线上服务持续可用，提升服务可用性，二是可在白天或是任何时间发布，提升运维人员的机动性。
那么我们需要怎么做，才能实现应用不停机发布呢，那接下来就让我们进入正题。
成熟度一级–应用发布过程服务不中断
成熟度二级–应用发布过程服务不中断，单应用功能可先进行内部/小流量验证
成熟度三级–应用发布过程服务不中断，多应用（联动）功能可先进行内部/小流量验证
应用不停机发布是一项综合性能力，当明确好一种发布模式后，就需要逐步识别会涉及到哪些技术组件，以及明确技术组件在整个解决方案中所担任的职责边界，从而使它们能够相互协同工作。
# 写在最后
感谢你可以很耐心的读到这里，整篇文章主要围绕应用不停机发布进行了思考，从为什么要做，能带来什么价值，一直到应该怎么做，要关心哪些方面，进行了简要说明，主要目的是为了能让大家，对应用不停机发布有一个大概的框架认识。
实现应用不停机发布的手段，也并非仅有文章中说的那些方式，涉及到的技术组件可能也不止这些，但其解决思路基本都差不多，具体的技术实现方式，可以结合自身的架构环境再进行适配和调整。
今天就先写到这里，后续我会针对在应用不停机发布中所涉及的技术组件，逐一进行深入研究，敬请期待！
`