蓝绿部署、金丝雀部署的含义和区别

=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=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4722.html

《蓝绿部署、金丝雀部署的含义和区别》上的3个想法

  1. 有赞灰度发布与蓝绿发布实践
    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/

  2. 微服务治理实践 | 金丝雀发布
    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 监听并在内存进行修改。
    `

  3. 怎样才是真正的灰度发布?
    https://mp.weixin.qq.com/s/NAegHaXJwDrkzjeCW8Ql-Q
    `
    究竟什么才是灰度发布其实并没有一个严格的标准,因为这个东西不是黑的也不是白的是个中间过渡地带,这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品,有意思的是他们实现的是完全不一样的功能,对外都说自己是灰度发布。我看到的有三种:
    1. 更新过程可以暂停,停在一个既有新版本又有旧版本的状态,然后选择升级或者回滚
    2. 支持流量比例分配,可以把百分之几的流量分配给一个服务,剩下的给另一个服务
    3. 支持 url 路径流量分配,一个路径下的流量给一个服务,另一个路径流量给另一个服务

    了解了需求,我们就很容易推导出所有人都在说的灰度发布真正是什么了
    1. 精确的流量分发控制
    2. 监控系统的支撑
    3. 灵活的发布系统

    说了这么写灰度系统要做的事情其实就是流量控制和数据收集,来控制风险并帮助产品做决策。再看一下最开始提出的三个所谓的灰度发布:更新过程可以暂停,流量比例分配,url分流。它们充其量也只是做到了流量精确分配的某几个特殊情况,而且还都是不很精确的分配。而如果结合使用场景就会发现,这几种在实际中是很难用起来的,因为没有流量的精确控制很难控制风险范围,如果风险都不可控,那还要灰度发布干什么呢?更不要提后面的监控数据收集和灵活的发布了。

    所以说一个真实好用的发布系统是十分复杂的,绝对不是页面上点两三下就可以完成的,而后面的实现更需要一整套体系来支撑。如果你想打造一个灰度发布系统,希望这篇文章能对你有所启发。
    `

发表评论

电子邮件地址不会被公开。 必填项已用*标注