运维&测试人员必读 | 微服务架构下应用灰度部署策略

应用上线,对开发者而言是阶段性工作的结束,可对运维和测试人员来说,这只是挑战的开始。做过运维的朋友都知道,不管在发布前做过多么完备的自动化和人工测试,在发布时或多或少都会面临一些问题:


  • 生产环境中,微服务集群的某个实例出现问题,如何提前避免这种情况,在不下线的情况如何将其进行屏蔽;


  • 由于业务的快速迭代性,微服务集群下的实例发布不同版本。如何根据版本管理策略进行路由,提供给下游微服务区别调用,达到多版本灰度访问控制;


  • 对于测试负责人,有哪些工具可以支持他对微服务做 A/B 测试。


根据墨菲定律,可能会出错的版本发布一定会出错。那么,在无法百分百避免版本升级故障的情况下,需要通过一种平滑的方式进行可控版本的发布,把故障影响控制在可以接受的范围内,并可以快速回退,这也就是我们今天要谈的主题——灰度发布。


灰度发布,是指在黑与白之间,能够平滑过渡的一种发布方式。

通俗来说,即让产品的迭代能够按照不同的灰度策略对新版本进行线上环境的测试,灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以对新版本进行测试、发现和调整问题,以保证其影响度。


本文将会和大家分享 KubeSphere 基于 Istio 提供的蓝绿部署、金丝雀发布、流量镜像等三种主流灰度策略,希望可以对大家的工作有所帮助。

蓝绿部署




蓝绿发布提供了一种零宕机的部署方式,在保留旧版本的同时部署新版本,将两个版本同时在线,新版本和旧版本是相互热备的,通过切换路由权重 (weight) 的方式(非 0 即 100)实现应用的不同版本上线或者下线,如果有问题可以快速地回滚到老版本。

金丝雀发布


金丝雀部署和蓝绿有点像,但是它更加规避风险。你可以阶段性的进行,而不用一次性从蓝色版本切换到绿色版本。



采用金丝雀部署,会在生产环境运行的服务中引一部分实际流量对一个新版本进行测试,测试新版本的性能和表现,然后从这部分的新版本中快速获取用户反馈。

流量镜像





流量镜像功能通常用于在生产环境进行测试,是将生产流量镜像拷贝到测试集群或者新的版本中,在引导用户的真实流量之前对新版本进行测试,旨在有效地降低新版本上线的风险。

流量镜像可用于以下场景:

验证新版本:可以实时对比镜像流量与生产流量的输出结果。


测试:生产实例的真实流量可用于集群测试。


隔离测试数据库:与数据处理相关的业务,可使用空的数据存储并加载测试数据,针对该数据进行镜像流量操作,实现测试数据的隔离。


从以上不同策略来看,要实现一套灰度发布流程,需要应用程序和运维流程对该发布过程进行支持,工作量和难度的挑战是非常大的。

我们建议大家通过 KubeSphere 来完成此工作, KubeSphere 基于 Istio 搭建的三种灰度策略,使得运维和测试人员无需修改应用的服务代码,即可实现灰度、流量治理、Tracing、流量监控、调用链等服务治理功能,为企业的运维和测试人员节约大量成本。


再好的策略也不是万能的,部署了这些策略并不意味着百分百成功,因此部署后的工作负载监控必不可少,如何设置工作负载级别的告警策略、添加告警规则、通知规则等操作及实践,我们将会在下一篇文章和大家分享,敬请期待。


7 月 25 日,我们特邀业内技术专家为大家定制了一场『容器&微服务架构实践』论坛,精选出 5 场精彩演讲,从微服务改造、DevOps、服务监测分析、容器迁移及真实的用户实践出发,让所有参会者能系统化深入学习微服务以及容器相关技术,少走弯路。 准备好了吗?赶紧扫码报名吧!

立即报名




转载于:https://juejin.im/post/5cff8a0551882519371f2ce8

猜你喜欢

转载自blog.csdn.net/weixin_33938733/article/details/93163528