隔离|浅析微服务全链路灰度解决方案机器|灰度发布|spring

文章图片

文章图片

文章图片

文章图片

文章图片

【隔离|浅析微服务全链路灰度解决方案】

文章图片

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

由于 Cart 服务是应?的?部分，所以新版本上线时需要对整个应?进?编译、打包以及部署。服务级别发布问题变成了应?级别的发布问题，我们需要对应?的新版本?不是服务来实施有效的发布策略。
?前，业界已经有?常成熟的服务发布?案，例如蓝绿发布和灰度发布。蓝绿发布需要对服务的新版本进?冗余部署， ?般新版本的机器规格和数量与旧版本保持?致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进?版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。我们的例?使?蓝绿发布的示意图如下，流量切换基于四层代理的流量?关即可完成。

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

其中， Traffic Routing 是基于内容的灰度?式， ?如请求中含有头部 stag=gray 的流量路由到应? v2 版本；Traffic Shifting 是基于?例的灰度?式，以?差别的?式对线上流量按?重进?分流。相?蓝绿发布，灰度发布在机器资源成本以及流量控制能?上更胜?筹，但缺点就是发布周期过? ，对运维基础设施要求较? 。
微服务架构下的服务发布在分布式微服务架构中，应?中被拆分出来的?服务都是独?部署、运?和迭代的。单个服务新版本上线时，我们再也不需要对应?整体进?发版，只需关注每个微服务?身的发布流程即可，如下：

为了验证服务 Cart 的新版本，流量在整个调?链路上能够通过某种?式有选择的路由到 Cart 的灰度版本，这属于微服务治理领域中流量治理问题。常?的治理策略包括基于 Provider 和基于 Consumer 的?式。