浅析微服务全链路灰度解决方案

简介：帮助应用发布版本过程中更精细化，提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制，有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发，进⼀步促进业务的快速发展。

作者：

十眠｜微服务引擎 MSE 研发工程师

扬少｜微服务引擎 MSE 研发工程师

本文摘选自《微服务治理技术白皮书》，该白皮书历经半年多筹备，长达 379 页。希望通过本书，能对高效解决云原生架构下的微服务治理难题，起到一点点作用，电子版免费下载地址：

微服务治理技术白皮书-藏经阁-阿里云开发者社区

单体架构下的服务发布

⾸先，我们先看⼀下在单体架构中，如何对应⽤中某个服务模块进⾏新版本发布。如下图，应⽤中的 Cart 服务模块有新版本迭代：

由于 Cart 服务是应⽤的⼀部分，所以新版本上线时需要对整个应⽤进⾏编译、打包以及部署。服务级别发布问题变成了应⽤级别的发布问题，我们需要对应⽤的新版本⽽不是服务来实施有效的发布策略。 

⽬前，业界已经有⾮常成熟的服务发布⽅案，例如蓝绿发布和灰度发布。蓝绿发布需要对服务的新版本进⾏冗余部署，⼀般新版本的机器规格和数量与旧版本保持⼀致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进⾏版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。我们的例⼦使⽤蓝绿发布的示意图如下，流量切换基于四层代理的流量⽹关即可完成。

在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占⽤的机器规模为新版本克隆⼀套环境，相当于要求原来 1 倍的机器资源。灰度发布的核⼼思想是根据请求内容或者请求流量的⽐例将线上流量的⼀⼩部分转发⾄新版本，待灰度验证通过后，逐步调⼤新版本的请求流量，是⼀种循序渐进的发布⽅式。我们的例⼦使⽤灰度发布的示意图如下，基于内容或⽐例的流量控制需要借助于⼀个七层代理的微服务⽹关来完成。