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

单体架构下的服务发布

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

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

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

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

其中，Traffic Routing 是基于内容的灰度⽅式，⽐如请求中含有头部 stag=gray 的流量路由到应⽤ v2 版本；Traffic Shifting 是基于⽐例的灰度⽅式，以⽆差别的⽅式对线上流量按⽐重进⾏分流。相⽐蓝绿发布，灰度发布在机器资源成本以及流量控制能⼒上更胜⼀筹，但缺点就是发布周期过⻓，对运维基础设施要求较⾼。

微服务架构下的服务发布

在分布式微服务架构中，应⽤中被拆分出来的⼦服务都是独⽴部署、运⾏和迭代的。单个服务新版本上线时，我们再也不需要对应⽤整体进⾏发版，只需关注每个微服务⾃身的发布流程即可，如下：