全链路灰度在微盟的落地

一、设计背景

• 随着近几年微盟业务范围的快速拓展，商家用户不断增多对微盟业务研发团队提出更高的版本迭代速度与质量要求。在多环境推出之前，业务研发团队进行产品并行迭代开发时，因测试环境单一无法满足并行提测，而建设多套测试环境的维护与实际成本又过于高昂，遂转向对多环境灰度进行立项研发。

• 微盟业务线众多且存在相互依赖，而微盟所有应用均采用微服务模式。以上导致微盟一次发布迭代涉及的应用数众多，需要上下游人力协调进行发布，且发布过程中出现问题时需要挨个回滚。整个发布极不灵活且存在不可控风险。

二、全链路灰度带来的挑战

一次发布往往对应一次业务迭代，在单体架构盛行的时候，由于一次迭代往往都只涉及一个服务，灰度发布通常也只针对单个应用。但随着微服务的发展，单个服务的职责越来越单一，服务的拆分越来越细，服务的数量越来越多，一次业务迭代往往涉及到多个服务，这个时候为了实现一次迭代的灰度上线，我们需要考虑的不再是单个应用的灰度，而是满足了灰度策略的流量在全链路上的每个应用都需要进入对应的灰度环境，即：全链路灰度。二者区别如下所示：

相比传统的灰度发布，全链路灰度复杂度更高，需要解决的问题更多。

1、资源隔离

资源隔离的必要性在于

1. 实现全链路灰度的前提在于能够区分灰度环境跟生产环境，根据流量标签确保灰度流量进入灰度环境，这就要求我们对灰度环境内的资源进行隔离。当然这里说的隔离并不意味着要重新部署一套环境，而是基于各种资源的差异性、实际的需求以及成本各方面考虑决定的隔离方案，也有可能是逻辑上的隔离
2. 尽可能避免灰度环境影响生产环境的稳定性。隔离程度越高，对生产环境影响更低
3. 我们需要对灰度环境建立完善的监控。隔离程度越高，监控成本更低，更方便建立完善的监控机制
4. 合适的隔离机制，会让我们管理维护更加方便

K8s

对于K8s集群有两种隔离方式

1. 物理隔离，灰度环境跟生产环境使用两套不同的集群。

这种方案的缺陷在于在其中部署服务的灰度版本，由于与正式环境隔离，正式环境中的其他服务无法访问到需要灰度的服务，所以需要在灰度环境中冗余部署这些线上服务，以便整个调用链路正常进行流量转发。此外，注册中心等一些其他依赖的中间件组件也需要冗余部署在灰度环境中，保证微服务之间的可见性问题，确保获取的节点 IP 地址只属于当前的网络环境。

这个方案一般用于企业的测试、预发开发环境的搭建，对于线上灰度发布引流的场景来说其灵活性不够。况且，微服务多版本的存在在微服务架构中是家常便饭，需要为这些业务场景采用堆机器的方式来维护多套灰度环境。如果应用数目过多，会造成运维、机器成本过大，成本和代价远超收益

2. 目前业界常见的做法是通过标签对K8s中的资源：Deployment、Svc、Pod等做逻辑隔离，灰度跟生产使用同一套物理集群，如下图所示：

RPC

对于PRC来说，涉及Provider（服务提供者）、Cons