作者： 倪海峰（海迩）
前言
随着企业规模的不断扩大，传统单体利用已很难进一步反对业务的倒退，业务的迭代速度曾经难以满足业务的增长，此时企业会对利用零碎做微服务化的革新，升高业务的耦合度，晋升开发迭代的效率，让开发更加麻利。
零碎架构微服务化的，本来的愿景是心愿通过将零碎的颗粒度变小，晋升业务的迭代效率。然而在实际微服务架构的过程中，尤其是在服务数量越来越多之后，那么引发的效率问题可能会大于微服务架构自身所带来的架构红利。
微服务架构下的公布挑战
零碎拆分为微服务之后，其中一项业务指标便是心愿通过将服务粒度变小，实现业务的高频交付。然而在实际微服务架构的过程中，将上下游服务齐全解耦简直可能存在于现实状态下。常见的状况是，频繁地对微服务做变更公布，通常都会导致业务流量呈现大量损失，于是研发人员不得不在早晨业务低峰期做变更。并且在公布过程中，波及到的上下游团队必须全程待命，以便于在公布阶段发现问题之后，立即修复，极大地升高了研发人员的幸福感。
如何落地可灰度、可观测、可回滚的平安生产能力，满足业务高速倒退状况下疾速迭代和小新验证的诉求，是企业在微服务化深刻过程中必须面对的问题。
本文将重点讲述在阿里云 EDAS ACK 环境下，对 Spring Cloud 微服务利用进行全链路流量管制的整体计划。通过全链路流量管制性能，能够疾速创立流量管制环境，将具备肯定特色的流量路由到指标版本利用。
灰度公布实际准则
在微服务架构下，灰度公布实际的关键在于：分层、隔离、兼容 这三大因素，在此基础之上，具备业务 可观测 的能力。分层是在设计灰度公布计划前的后期筹备，而隔离和兼容则是实现灰度的次要伎俩。
在实现全链路灰度场景的流量隔离有两种实现思路：基于 物理环境隔离 和基于 逻辑环境隔离 两种。
基于物理环境的隔离，须要为要灰度的服务搭建一套网络隔离、资源独立的环境，在其中部署服务的灰度版本。因为正式环境与灰度环境绝对隔离，正式环境无法访问到灰度环境的服务，因而即使是未做版本更新的服务以及各组件，同样也须要在灰度环境中部署。从实现原理上来讲，常见的蓝绿部署便是其中一种技术实现。然而在线上服务足够多的场景下，基于物理环境隔离的计划灵便度绝对有余，同时会造成大量的冗余节点以及额定的资源开销。
逻辑环境隔离计划的外围在于对流量染色，当流量在调用链上转发申请时，通过网关以及各个中间件及微服务来辨认到被染色的灰度流量，并将申请动静转发至对应的灰度版本。再依据规定作出动静决策。因而当版本发生变化时，调用链路的转发规定同样也会实时作出扭转。相比于通过搭建一套物理上隔离的灰度环境，基于逻辑动静调整策略的形式可能节俭大量的资源及运维老本，并能够帮忙开发者实现更为简单的全链路管制场景。
标签路由通过标签将一个或多个服务的提供者划分到同一个分组，从而束缚流量只在指定分组中流转，实现流量隔离的目标。标签路由能够作为多版本开发测试、同利用的多版本流量隔离以及 A/B Testing 等场景的能力根底。实际上，标签路由的应用场景还有许多，例如实现全链路流控、同 AZ 优先、全链路压测、容灾多活等等。
最初，在具体的工程实际中，并非所有组件通过隔离便可能无效地实现流量的精细化管制，例如数据库等有状态组件，无论是从施行老本还是从技术视角，都不会在每次上线时都从新搭建一套全新的表库，对数据同步之后再刷新对应版本后的 SQL 脚本。因而，在特定场景下的新老版本兼容就成为了必要的前置条件。
架构剖析
该我的项目中后端架构技术栈为 Spring Cloud Alibaba，应用了一整套的阿里云云原生的最佳实际，其中也包含 EDAS、MSE 云原生网关。前端利用应用 VUE 开发，其资源均为动态资源。从利用架构中能够得悉，动态资源以 Nginx 为 HTTP 服务对外提供。
在此次架构设计中，业务需要如下：
- 前端到后端可能依照依照不同的简单规定（如 header 中的城市、UserID 等）做精细化路由管制，同时当上游服务灰度版本存在异样或不存在时，可能降级至基线服务解决申请。
- 依照肯定百分比随机对线上流量做灰度公布。
- 反对对音讯队列中音讯打标，并由对应的 Consumer 生产。
- 尽可能的零代码革新。
- 须要对音讯队列中的音讯做灰度分组，并由对应的 Consumer 将音讯生产。
- 须要具备灰度流量的可观测问题。
EDAS 流量管制
EDAS 是利用托管和微服务治理的云原生 PaaS 平台，提供利用开发、部署、监控、运维等全栈式解决方案，同时反对 Spring Cloud 和 Apache Dubbo 等微服务运行环境。
在 EDAS 平台中，用户能够通过 WAR 包、JAR 包或镜像等多种形式疾速部署利用到多种底层服务器集群，轻松部署利用的基线版本和灰度版本。同时，EDAS 可能无缝接入 MSE 的服务治理能力，无需额定装置 Agent 即可零代码入侵取得利用无损高低线、金丝雀公布、全链路流量管制等高级个性。
MSE 云原生网关是阿里云推出的新一代网关，将传统流量网关和微服务网关合并，升高资源老本的同时为用户提供精细化的流量治理能力，反对 ACK 容器服务、Nacos、Eureka、固定地址、FaaS 等多种服务发现形式，反对多种认证登录形式疾速构建平安防线，提供全方面、多视角的监控体系，如指标监控、日志剖析以及链路追踪。
利用 EDAS 微服务治理能力，配合云原生网关，能够轻松利用多套逻辑环境实现全链路灰度。EDAS 实现了基于字节码加强技术在编译时对开发框架进行性能拓展，这种计划业务无感知，不须要批改任何一行业务代码，即可领有全链路灰度的治理能力。
全链路流量灰度
流量入口： 入口利用微服务体系内的流量入口，该场景下对应的是 MSE 云原生网关。
泳道： 为雷同版本利用定义的一套隔离环境。只有满足了流控路由规定的申请流量才会路由到对应泳道里的打标利用。一个利用能够属于多个泳道，一个泳道能够蕴含多个利用，利用和泳道是多对多的关系。
基线环境： 未打标的利用属于基线稳固版本的利用，即稳固的线上环境。
流量回退： 泳道中所部署的服务数量并非要求与基线环境完全一致，当泳道中并不存在调用链中所依赖的其余服务时，流量须要回退至基线环境，进一步在必要的时候路由回对应标签的泳道。
泳道组： 泳道的汇合。泳道组的作用次要是为了辨别不同团队或不同场景。
入口利用： 将合乎流控规定的流量打上对应的灰度标识，并使该流量在上游利用中走到对应的利用版本中。因为在本案例中理论应用场景中为 MSE 云原生网关 +EDAS，其打标能力全副集中在 MSE 云原生网关上。
从上图中能够看到，用户别离创立了泳道 A 与泳道 B，外面波及了交易中心、商品核心两个利用，别离是标签标签 2，其中 A 泳道分流了线上 30% 的流量，B 泳道分流了线上 20% 的流量，基线环境 (即未打标的环境) 分流了线上 50% 的流量。
通过在 deployment 上配置注解 alicloud.service.tag: gray 标识利用灰度版本，并带标注册到注册核心中，在灰度版本利用上开启全链路泳道(通过机器的流量主动染色)，反对灰度流量主动增加灰度 x-mse-tag: gray 标签，通过扩大 consumer 的路由能力将带有灰度标签的流量转发到指标灰度利用。
创立泳道组和泳道
在创立泳道时须要抉择入口类型，目前仅反对部署在 EDAS 中的入口利用作为泳道入口利用，须要将泳道中波及的基线版本和灰度版本增加到泳道组波及利用中。
创立分流泳道，定义泳道名称，配置泳道流控规定。
创立实现后会生成新泳道，点击泳道名称，将泳道标签值记录下来，本示例为 f2bb906。
灰度利用部署
通过 edas 将利用克隆出灰度（gray）版本，选中所有须要灰度的利用。
给所有灰度利用重命名，命名规定是在基线利用名称的前面加上 -gray 作辨别，点击确定，期待利用克隆实现。
当看到所有利用（包含灰度版本利用）曾经处于运行中状态且实例数失常，即可进行下一步。
退出泳道组及泳道
回到全链路流量管制页面，找到之前创立的泳道组，点击编辑，将基线和灰度利用都增加进泳道组中，而后点击确定。
在创立实现的灰度泳道中增加灰度利用，找到灰度泳道，点击编辑，增加泳道利用，抉择 gray 版的利用。
MSE 云原生网关路由配置
在 EDAS 控制台左侧菜单栏中选中流量治理 - 利用路由 -MSE 网关路由，点击创立路由。
定义路由名称，抉择 MSE 网关实例，配置关联域名、匹配规定、申请办法等，这里的路由是到基线利用，无需配置申请头（即无需匹配灰度规定）。
服务起源抉择 EDAS 注册核心，指标填入基线利用 a 的配置。注：这里如果抉择利用后没有可选的服务，须要查看 k8s 集群上的 agent 状态。
创立 MSE 云原生网关灰度路由
再创立一条 MSE 网关路由用于灰度版本利用，定义路由名称，抉择 MSE 网关，增加申请头，key=tag，value=gray，在指标服务中抉择灰度利用版本的 a 利用。
给灰度路由增加策略配置，增加 Header 规定，其中 header key:x-mse-tag，header value: 的值为在第 4 步获取的泳道标签，增加规定后并将开启状态开关关上。
增加实现后将对应 base 以及 gray 路由公布上线。
在实现路由策略配置后，对网关后对应的下一跳服务路由，设置 fallback 指标服务到基线服务。
音讯灰度
流量入口： 入口利用微服务体系内的流量入口，该场景下对应的是 MSE 云原生网关。
RocketMQ 的订阅关系（Subscription）是零碎中消费者获取音讯、解决音讯的规定和状态配置。订阅关系由消费者分组动静注册到服务端零碎，并在后续的音讯传输中依照订阅关系定义的过滤规定进行音讯匹配和生产进度保护。音讯队列 RocketMQ 的订阅关系依照消费者分组和主题粒度设计，因而一个订阅关系指的是某个消费者分组对于某个主题的订阅。
- 不同消费者分组对于同一个主题的订阅互相独立。
- 同一个消费者分组对于不同主题的订阅也互相独立。
在音讯队列 RocketMQ 的畛域模型中，音讯由生产者初始化并发送到音讯队列 RocketMQ 的服务端，音讯依照达到音讯队列服务端的顺序存储到对应 Topic 的指定队列中，消费者再依照指定的订阅关系从音讯队列 RocketMQ 中获取音讯并生产。
在理论业务场景中，同一个主题下的音讯往往会被多个不同的上游业务方解决，各上游的解决逻辑不同，只关注本身逻辑须要的音讯子集。针对这类场景，RocketMQ 的订阅关系反对在音讯传输中依照订阅关系定义过滤规定进行音讯匹配和生产进行保护。例如管制消费者在生产音讯时，抉择主题内的哪些音讯进行生产，设置生产过滤规定能够高效地过滤消费者须要的音讯汇合，灵便依据不同业务场景设置不同的音讯承受范畴。
音讯过滤次要通过以下几个要害流程实现：
- 生产者：生产者在初始化音讯时事后为音讯设置一些属性和标签，用于后续生产时指定过滤指标。
- 消费者：消费者在初始化及后续生产流程中通过调用订阅关系注册接口，向服务端上报须要订阅指定主题的哪些音讯，即过滤条件。
- 服务端：消费者获取音讯时会触发服务端的动静过滤计算，音讯队列 RocketMQ 版服务端依据消费者上报的过滤条件的表达式进行匹配，并将符合条件的音讯投递给消费者。
RocketMQ 反对 Tag 标签过滤 和 SQL 属性过滤 两种场景。因为一条音讯只能打一个 string 类型的标签，因而更适宜一些简略过滤场景，而后者是通过生产者为音讯设置 K / V 键值对作为属性，并设置 SQL92 语法的过滤表达式过滤多个属性，因而更适宜一些简单过滤场景。此外，Tag 自身也是音讯的零碎属性，因而 SQL 过滤也兼容 Tag 过滤。在 SQL 语法中，Tag 的属性名称为 TAGS。
在介绍完了 RocketMQ 订阅模式之后，再一起看下音讯灰度的实现计划。灰度公布的实质是解决环境隔离的问题。通过不同音讯者分组辨别失常和灰度版本。在不扭转代码及利用配置的状况下，通过服务治理层的 agent 实现音讯从发送到订阅的解决逻辑，整体计划思路如下：
1. 创立对应消费者组 ： 首先须要用户对以后每个消费者分组预创立的对应的消费者分组 _grayID。例：serviceA_group 对应的分组名为 service_A_group_grayID。（备注：命名必须依照 _gray 的标准创立，否则 agent 在获取到对应的灰度标识之后，无奈将 service 同消费者分组建设关联，或间接报错消费者分组不存在）
2. 音讯染色： 通过用户定义的灰度环境分组，为对应的服务染色并打上环境标识。当服务开始失常发送音讯到对应的 Topic 时，通过服务的 agent 劫持到对应的音讯后，打上自定义标签 putUserProerty(“__gray_tag__”, “$ 灰度标识 ”)，并将音讯放到对应的 Topic。
3. 动静建设订阅关系： 当消费者被增加到对应的环境之后，会基于环境标识被调配到对应的消费者分组中。并基于消费者组同 Topic 动静建设订阅关系。
4. 音讯过滤： 因为生产者会将无论是灰度环境还是生产环境的音讯推送到同一个 Topic 中，因而不同的消费者组须要基于对应环境的音讯过滤进行生产。在技术实现上，RocketMQ 基于 Tag 和音讯属性两种形式均能满足业务场景。计划中之所以采纳自定义音讯属性的形式，更多的是出于工程实际的思考。因为音讯 Tag 对于一条音讯仅反对增加一个 string 类型的音讯，在一些业务场景下，可能 Tag 会被利用的业务场景所占用，从而呈现不可控的场景，因而通过自定义音讯属性，再消费者的 agent 端基于 SQL92 语法实现音讯过滤，从容错性上绝对更优，因而举荐应用自定义音讯属性实现音讯分组。
该计划的次要劣势在于对于治理和应用人员来说，没有太高的应用老本，在理论实现灰度公布过程中，无需频繁批改代码及对应配置信息。
音讯灰度配置
在泳道列表中查问到已创立利用的基线、灰度泳道，点击泳道名称查看泳道详情，并获取泳道标签。
如上图，获得 dev1 泳道标签为 9e4be42，dev2 泳道标签为 e396fee。登录音讯服务 RocketMQ 控制台，依据上一步骤获取的泳道标签创立灰度消费者组。如图所示，依据步骤 3 获取的泳道标别离创立生产组 MyConsumerGroup_e396fee 和 MyConsumerGroup_9e4be42。
在 EDAS 控制台抉择利用治理，进入利用列表。找到（须要进行灰度流控的音讯生产者和消费者）利用 B、利用 B-dev1、利用 B-dev2、利用 C、利用 C-dev1、利用 C-dev2，进入利用详情页进行部署并增加以下环境变量：所有利用均配置环境变量：
profiler.micro.service.mq.gray.enable=trueprofiler.micro.service.mq.gray.enable=true
profiler.micro.service.mq.gray.cunsumer.base.excluded.tags=9e4be42,e396fee基线利用 C 额定配置环境变量：
注： profiler.micro.service.mq.gray.cunsumer.base.excluded.tags 的值通过步骤 3 获取的泳道标签通过逗号“,”拼接失去，若仅有一个灰度环境不须要用逗号拼接。需按理论泳道批改。
音讯服务订阅关系查看
登录音讯服务 RocketMQ 控制台，查看生产组的订阅关系，如下图：
默认生产组 MyConsumerGroup 由基线利用 C 订阅，并过滤带有灰度标的音讯。
灰度生产组 MyConsumerGroup_e396fee 和 MyConsumerGroup_9e4be42 别离只订阅带有对应灰度标的音讯。
基于客户端申请实现前端灰度
基于客户端申请 IP 实现前端灰度策略通常的做法是通过 nginx 配置，在用户流量达到 nginx 时，检查用户申请中 http_x_forwarded_for 中的关键字，依据关键字值的不同，重定向申请到不同的前端版本，如下图所示：
Nginx 配置代码如下：
set $canary_flag main; # 定义目录变量
set $flag_page 0; # 定义灰度条件的初始判断值
if ($http_x_forwarded_for ~ "(xxx.xxx.xxx.01|xxx.xxx.xxx.02|xxx.xxx.xxx.03") { # 判断起源 IP，设置灰度条件的初始值
set $flag_page "${flag_page}1";
}在理论我的项目中，基于 http_x_forwarded_for 的灰度申请，因为须要枚举出对应的申请 IP，对于客户端有明确的指向性，次要可能解决开发测试人员在公布实现后，在生产环境做业务验证的场景。
基于 IP 的灰度策略也有其本身的局限性，在生产环境下，显然无奈满足需要实在随时流量做业务验证的场景。比拟通用的形式可通过城市、省份信息做灰度规定判断。在此次方案设计中，前端站点应用阿里云 CDN 做动态减速，而通过阿里云 CDN 的边缘脚本，可能将客户端申请 IP 转换为对应的城市信息。
边缘脚本（EdgeScript，简称 ES）是一个可疾速实现 CDN 定制配置的工具箱，当 CDN 管制台上的标准配置无奈满足业务需要时，能够尝试应用边缘脚本简略编程实现。
边缘脚本内置了 CDN 节点能够辨认的变量、简略的判断语句，同时提供了大量阿里云 CDN 封装好的函数供用户间接调用。通过简略的变量判断并调用现成的函数，即可满足绝大部分定制的鉴权、缓存、限速、申请头增减等定制配置需要，能够无效地解决定制化配置需要无奈实现、业务变更不麻利的问题。
边缘脚本的执行地位如图所示，当客户端申请达到 CDN 节点后，节点网关会依据在管制台上设置的标准配置、边缘脚本规定对申请进行解决。以 CDN 管制台上的标准配置为参照物，边缘脚本可抉择在申请解决的最后面或最初面失效。
基于省份城市对流量打标，可通过 IP 地址库辨认到申请 IP 所在城市。以后链路后端 API 应用到了阿里云 CDN。
EdgeScript 规定代码如下：
cou = $ali_hook_ip_country_en
pro = $ali_hook_ip_region_en
city = $ali_hook_ip_city_en
regiont = concat(city,',',pro,',',cou)
region = lower(regiont)
add_req_header('X-Client-Ip-City',region)
add_rsp_header('X-Client-Ip-City',region)在 Nginx 上对 X-Client-Ip-City 所获取的值做判断，当满足灰度规定时，将申请带上灰度 header，申请到对应网关的灰度规定。
最初，在 MSE 云原生网关控制台，抉择对应的 MSE 云原生网关，进入路由治理 - 路由配置中找到对应的路由进行编辑。
申请头（Header）中设置为：x-client-ip-city 正则匹配 .guangdong.，如下图所示：
灰度流量观测与告警
在全链路灰度公布场景下，因为生产环境会存在两个利用版本，具备较高的运维复杂度。为了可能在呈现流量逃逸问题时尽早辨认，须要具备灰度流量的可观测能力与逃逸告警能力，当呈现非预期流量申请的状况下，开发人员可能通过监控视图对逃逸状况疾速剖析，并在第一工夫告诉到相应职能团队对告警进行解决。
基于上述可观测需要，在流量通过 MSE 云原生网关的同时，在路由配置中对应 Header 以满足对所有流量走向的可观测需要。
具体的断定规定为：若 base 路由存在灰度流量、或灰度路由中匹配到基线流量，此时便认为存在流量逃逸。
总结
本文残缺介绍了基于物理环境隔离和基于逻辑环境隔离两种计划，其中对基于逻辑环境隔离计划进行详细分析对波及到的各个技术点做了相干介绍，并基于 EDAS 及 MSE 云原生网关的落地计划，并给出相干产品配置用例。
其中 MSE 为微服务提供了云原生网关、注册和配置核心、微服务治理等丰盛的微服务相干能力，EDAS 以利用为视角，深度交融集成 MSE 的各个原子能力，为微服务利用治理提供了一个最佳实际参考，欢送大家体验交换。