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


=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 条评论

  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分流。它们充其量也只是做到了流量精确分配的某几个特殊情况,而且还都是不很精确的分配。而如果结合使用场景就会发现,这几种在实际中是很难用起来的,因为没有流量的精确控制很难控制风险范围,如果风险都不可控,那还要灰度发布干什么呢?更不要提后面的监控数据收集和灵活的发布了。

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

  4. 一文读懂蓝绿发布、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.发布周期长。
    `

  5. 应用不停机发布的思考与初识
    https://mp.weixin.qq.com/s/OgOQtKmfBmCp7-uWkvmGtw
    `
    应用发布,简单来说就是将已开发完成的系统功能部署到生产环境,并可正常对用户提供服务。

    传统的应用发布步骤一般采用“三步曲”:
    第一步:停止应用
    第二步:更新应用
    第三步:启动应用

    那你肯定会问,从停止应用一直到启动应用期间,系统功能是不是无法正常使用?
    没错。在应用发布过程中,可能会出现页面白屏、访问超时等各种异常,而且一般会持续很久,所以发布时间基本上都集中在凌晨,讲究点的可能就配上一句友好提示“系统正在维护,请稍后访问!”。

    这种情况大部分都出现在传统行业,原因可能是觉得没有必要,因为:
    1.传统行业的业务一般都集中的日间,也就是说凌晨基本没有业务,或者非重要业务
    2.就算凌晨无法使用这些功能,觉得也没关系,第二天再来就是了,客户又不会跑了

    但真的是这样吗?如今越来越多的传统行业,都在向互联网服务模式转型,其服务主要特点:“全天”不间断为客户提供“优质”的“线上”服务,拆分一下关键词
    1.“全天”代表着任何时间
    2.“优质”代表着客户体验
    3.“线上”代表着线上自助

    所以说,一个优质的客户服务势必会对服务可用性提出更高的要求,而传统的停机发布不但会对客户造成使用影响,还会变向对企业造成非直接经济损失。
    例如:客户体验下降导致的客户流失
    仅此而已?非也!作为曾经也同样是一名运维工程师的我来说,凌晨发布家常便饭,还时不时来一次长达8小时的“长途之旅”,身体就直接被掏空,加上第二天还在“补血”中,还会被各种骚扰电话轰炸,这简直就是一场噩梦。
    由此可见,应用不停机发布的重要性,通过它可以帮助我们:一是在应用发布过程中线上服务持续可用,提升服务可用性,二是可在白天或是任何时间发布,提升运维人员的机动性。
    那么我们需要怎么做,才能实现应用不停机发布呢,那接下来就让我们进入正题。

    成熟度一级–应用发布过程服务不中断
    成熟度二级–应用发布过程服务不中断,单应用功能可先进行内部/小流量验证
    成熟度三级–应用发布过程服务不中断,多应用(联动)功能可先进行内部/小流量验证

    应用不停机发布是一项综合性能力,当明确好一种发布模式后,就需要逐步识别会涉及到哪些技术组件,以及明确技术组件在整个解决方案中所担任的职责边界,从而使它们能够相互协同工作。

    # 写在最后
    感谢你可以很耐心的读到这里,整篇文章主要围绕应用不停机发布进行了思考,从为什么要做,能带来什么价值,一直到应该怎么做,要关心哪些方面,进行了简要说明,主要目的是为了能让大家,对应用不停机发布有一个大概的框架认识。
    实现应用不停机发布的手段,也并非仅有文章中说的那些方式,涉及到的技术组件可能也不止这些,但其解决思路基本都差不多,具体的技术实现方式,可以结合自身的架构环境再进行适配和调整。
    今天就先写到这里,后续我会针对在应用不停机发布中所涉及的技术组件,逐一进行深入研究,敬请期待!
    `

回复 hi 取消回复

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