`

微服务部署:蓝绿部署、滚动部署、灰度发布等部署方案对比与总结

 
阅读更多
http://www.itmuch.com/work/microservice-deploy/
在项目迭代的过程中,不可避免需要”上线“。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。

目前有很多用于部署的技术,有的简单,有的复杂;有的得停机,有的不需要停机即可完成部署。本文笔者简单讨论一下目前比较流行的几种部署方案,或者说策略。如有不足之处请指出,如有谬误,请指正^_^。

Blue/Green Deployment(蓝绿部署)

蓝绿部署无需停机,并且风险较小。

(1) 部署版本1的应用(一开始的状态)

所有外部请求的流量都打到这个版本上。

(2) 部署版本2的应用

版本2的代码与版本1不同(新功能、Bug修复等)。

(3) 将流量从版本1切换到版本2。

(4) 如版本2测试正常,就删除版本1正在使用的资源(例如实例),从此正式用版本2。

从过程不难发现,在部署的过程中,我们的应用始终在线。并且,新版本上线的过程中,并没有修改老版本的任何内容,在部署期间,老版本的状态不受影响。这样风险很小,并且,只要老版本的资源不被删除,理论上,我们可以在任何时间回滚到老版本。

rolling update(滚动发布)

滚动发布,一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有的实例都更新成新版本。

这种部署方式相对于蓝绿部署,更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署,例如每次只取出集群的20%进行升级。

这种方式也有很多缺点,例如:

(1) 没有一个确定OK的环境。使用蓝绿部署,我们能够清晰地知道老版本是OK的,而使用滚动发布,我们无法确定。

(2) 修改了现有的环境。

(3) 如果需要回滚,很困难。举个例子,在某一次发布中,我们需要更新100个实例,每次更新10个实例,每次部署需要5分钟。当滚动发布到第80个实例时,发现了问题,需要回滚。此时,脾气不好的程序猿很可能想掀桌子,因为回滚是一个痛苦,并且漫长的过程。

(4) 有的时候,我们还可能对系统进行动态伸缩,如果部署期间,系统自动扩容/缩容了,我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具,但是依然令人心惊胆战。

并不是说滚动发布不好,滚动发布也有它非常合适的场景。

灰度发布/金丝雀部署

先贴个百度百科:

灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部分用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。

很多人把灰度发布与蓝绿部署混为一谈,笔者认为,与灰度发布最类似的应该是金丝雀部署。

“金丝雀部署”是增量发布的一种类型,它的执行方式是在原有软件生产版本可用的情况下,同时部署一个新的版本。同时运行同一个软件产品的多个版本需要软件针对配置和完美自动化部署进行特别设计。

我们来看一下金丝雀部署的步骤:

(1) 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。

(2) 从负载均衡列表中移除掉“金丝雀”服务器。

(3) 升级“金丝雀”应用(排掉原有流量并进行部署)。

(4) 对应用进行自动化测试。

(5) 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。

(6) 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)

灰度发布中,常常按照用户设置路由权重,例如90%的用户维持使用老版本,10%的用户尝鲜新版本。不同版本应用共存,经常与A/B测试一起使用,用于测试选择多种方案。灰度发布比较典型的例子,是阿里云那个“新版本”,点击“进入新版本”,我们就成了金丝雀。

趣闻 :金丝雀部署(同理还有金丝雀测试),“金丝雀”的由来:17世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;而当瓦斯含量超过一定限度时,虽然鲁钝的人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”,以便在危险状况下紧急撤离。

总结

(1) 蓝绿部署:不停止老版本,额外搞一套新版本,等测试发现新版本OK后,删除老版本。

(2) 滚动发布:按批次停止老版本实例,启动新版本实例。

(3) 灰度发布/金丝雀部署:不停止老版本,额外搞一套新版本,常常按照用户设置路由权重,例如90%的用户维持使用老版本,10%的用户尝鲜新版本。不同版本应用共存,经常与A/B测试一起使用,用于测试选择多种方案。
分享到:
评论

相关推荐

    微服务部署发布模型分析.docx

    本文深入分析了当前业界常见的四种微服务部署模型:蓝绿部署、滚动发布、灰度发布及金丝雀发布,并探讨了它们在不同场景下的应用、优势及挑战。 ### 蓝绿部署 蓝绿部署模型通过维护两套并行的生产环境来降低部署...

    在线客服系统全链路灰度方案探索与实践

    常见的灰度发布类型有蓝绿发布、金丝雀发布和滚动发布。 蓝绿发布是指同时运行两个版本的系统,一个是新的版本,另一个是旧的版本。这种方式可以快速回退到旧的版本,但缺点是需要双倍的资源。 金丝雀发布是指将一...

    DevOps线上部署的最后一公里.docx

    下面我们将详细介绍三种常见的发布技术:蓝绿部署、滚动部署以及灰度/金丝雀发布。 ##### 蓝绿部署 **概念** 蓝绿部署是一种零停机部署方法,通过同时维护两个完全相同的应用环境(蓝色环境和绿色环境),其中一...

    持续集成与交付实践指南.pptx

    - **蓝绿部署**:同时部署两个环境,在新环境上进行验证后切换流量。 - **金丝雀发布**:逐步将新功能发布给一小部分用户,验证后再全面发布。 - **滚动发布**:逐步将新版本部署到所有服务器,确保业务稳定。 - **...

    Serverless入门与实战.pdf

    - **蓝绿部署**:平滑过渡新旧版本。 - **滚动更新**:渐进式更新应用。 **4.8 SAE的极致应用部署效率** - **快速启动**:秒级部署。 - **热更新**:无需重启服务即可更新代码。 **4.9 Serverless应用远程调试和...

    Knative Serving技术架构介绍.pptx

    它能够根据配置动态调整流量分配,实现灰度发布和蓝绿部署等策略。 2. **Revision**:Service 的每个版本被称为 Revision,它是服务的一个快照,记录了服务在某个时间点的状态。每次代码变更或配置更新都会创建一个...

    Nacos-develop

    3. **蓝绿部署和金丝雀发布**:利用Nacos的动态配置能力,可以实现无缝滚动升级,减少服务中断的风险。 4. **流量管理**:Nacos支持服务权重调整,可以实现灰度发布、流量控制等高级功能。 四、Nacos-develop源码...

    DevOps:DevOps的文件

    - **蓝绿部署和滚动更新**:减少服务中断,平滑升级。 - **灰度发布**:逐步将新版本推送给部分用户,观察效果后再全面推广。 - **微服务架构**:拆分大型应用为小而独立的服务,便于部署和维护。 - **DevSecOps...

    learning-istio:记录istio相关知识与实践

    Istio提供了精细的流量管理能力,可以控制请求如何在服务之间流动,如基于版本的蓝绿部署、金丝雀发布、熔断和超时设置等。 3.2 安全性 通过 Citadel,Istio实现了服务间的双向TLS认证,确保了服务通信的安全性。...

    Mastering-ServiceMesh:深入浅出服务网格,从入门到精通Istio

    6. **流量管理**:熟悉Istio的流量路由规则,以及如何进行滚动更新、蓝绿部署等。 7. **自定义策略和扩展**:了解如何通过 Istio 的 Mixer API 或直接在 Pilot 中编写自定义逻辑来扩展服务网格的功能。 掌握以上...

Global site tag (gtag.js) - Google Analytics