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

浅析微服务全链路灰度解决方案 　　?先，我们先看?下在单体架构中，如何对应?中某个服务模块进?新版本发布。如下图，应?中的 Cart 服务模块有新版本迭代： 　　由于 Cart 服务是应?的?部分，所以新版本上线时需要对整个应?进?编译、打包以及部署。服务级别发布问题变成了应?级别的发布问题，我们需要对应?的新版本?不是服务来实施有效的发布策略。? 　　?前，业界已经有?常成熟的服务发布?案，例如蓝绿发布和灰度发布。蓝绿发布需要对服务的新版本进?冗余部署，?般新版本的机器规格和数量与旧版本保持?致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进?版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。我们的例?使?蓝绿发布的示意图如下，流量切换基于四层代理的流量?关即可完成。 　　在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占?的机器规模为新版本克隆?套环境，相当于要求原来 1 倍的机器资源。灰度发布的核?思想是根据请求内容或者请求流量的?例将线上流量的??部分转发?新版本，待灰度验证通过后，逐步调?新版本的请求流量，是?种循序渐进的发布?式。我们的例?使?灰度发布的示意图如下，基于内容或?例的流量控制需要借助于?个七层代理的微服务?关来完成。 　　其中，Traffic Routing 是基于内容的灰度?式，?如请求中含有头部 stag=gray 的流量路由到应? v2 版本；Traffic Shifting 是基于?例的灰度?式，以?差别的?式对线上流量按?重进?分流。相?蓝绿发布，灰度发布在机器资源成本以及流量控制能?上更胜?筹，但缺点就是发布周期过?，对运维基础设施要求较?。 　　在分布式微服务架构中，应?中被拆分出来的?服务都是独?部署、运?和迭代的。单个服务新版本上线时，我们再也不需要对应?整体进?发版，只需关注每个微服务?身的发布流程即可，如下： 　　为了验证服务 Cart 的新版本，流量在整个调?链路上能够通过某种?式有选择的路由到 Cart 的灰度版本，这属于微服务治理领域中流量治理问题。常?的治理策略包括基于 Provider 和基于 Consumer 的?式。? 　　基于 Provider 的治理策略。配置 Cart 的流量流?规则，User 路由到 Cart 时使? Cart 的流量流?规则。基于 Consumer 的治理策略。配置 User 的流量流出规则， User 路由到 Cart 时使? User 的流量流出规则。此外，使?这些治理策略时可以结合上?介绍的蓝绿发布和灰度发布?案来实施真正的服务级别的版本发布。 　　继续考虑上?微服务体系中对服务 Cart 进?发布的场景，如果此时服务 Order 也需要发布新版本，由于本次新功能涉及到服务 Cart 和 Order 的共同变动，所以要求在灰度验证时能够使得灰度流量同时经过服务 Cart 和 Order 的灰度版本。如下图： 　　按照上??节提出的两种治理策略，我们需要额外配置服务 Order 的治理规则，确保来?灰度环境的服务 Cart 的流量转发?服务 Order 的灰度版本。这样的做法看似符合正常的操作逻辑，但在真实业务场景中，业务的微服务规模和数量远超我们的例?，其中?条请求链路可能经过数?个微服务，新功能发布时也可能会涉及到多个微服务同时变更，并且业务的服务之间依赖错综复杂，频繁的服务发布、以及服务多版本并?开发导致流量治理规则?益膨胀，给整个系统的维护性和稳定性带来了不利因素。? 　　对于以上的问题，开发者结合实际业务场景和?产实践经验，提出了?种端到端的灰度发布?案，即全链路灰度。全链路灰度治理策略主要专注于整个调?链，它不关?链路上经过具体哪些微服务，流量控制视?从服务转移?请求链路上，仅需要少量的治理规则即可构建出从?关到整个后端服务的多个流量隔离环境，有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并?开发，进?步促进业务的快速发展。 　　如何在实际业务场景中去快速落地全链路灰度呢？?前，主要有两种解决思路，基于物理环境隔离和基于逻辑环境隔离。 　　物理环境隔离，顾名思义，通过增加机器的?式来搭建真正意义上的流量隔离。 　　这种?案需要为要灰度的服务搭建?套?络隔离、资源独?的环境，在其中部署服务的灰度版本。由于与正式环境隔离，正式环境中的其他服务?法访问到需要灰度的服务，所以需要在灰度环境中冗余部署这些线上服务，以便整个调?链路正常进?流量转发。此外，注册中?等?些其他依赖的中间件组件也 需要冗余部署在灰度环境中，保证微服务之间的可?性问题，确保获取的节点 IP 地址只属于当前的?络环境。? 　　这个?案?般?于企业的测试、预发开发环境的搭建，对于线上灰