服务路由之元数据路由
服务实例有元数据信息，例如 idc、version 等。请求流量也有标签信息，例如 sourceService、version 等。通过匹配流量标签和实例标签来实现路由称之为元数据路由，例如请求流量带有 version=v1 的请求都转发到具有 version=v1 的服务实例。
元数据路由核心包含三个部分：
- 服务实例染色 （为服务实例设置标签信息）
- 流量染色（为请求设置标签信息）
- 服务路由（根据路由策略，把请求转发到目标实例）
接下去将会详细介绍三部分内容。
服务实例染色即服务实例启动的时候，通过某些方式获取到当前实例的元信息，并注册到注册中心时携带元信息。如何染色请参考 服务注册元数据以及元数据传递。
流量染色即为每个请求打上标签，路由转发时根据请求标签匹配请求。而流量染色可以分为以下几种方式：
前面小节介绍了可以为服务实例设置一系列的标签信息，例如 idc=shanghai、env=f1 等。在有些场景下，我们期望所有经过当前实例的请求都带上当前实例的标签信息。例如经过 env=f1 的实例的请求都携带 env=f1 的标签信息。
服务实例染色有三种方式，对应的定义哪些实例标签作为请求标签透传到链路上也有三种方式，核心思想就是定义需要全链路传递的标签键值对的键列表。
- 通过配置文件的
spring.cloud.tencent.metadata.content.transitive=["idc", "env"]配置项指定 - 通过
SCT_METADATA_CONTENT_TRANSITIVE=IDC,ENV环境变量指定 - 通过实现
InstanceMetadataProvider#getTransitiveMetadataKeys()方法指定
静态染色是把服务实例的某些标签作为请求标签，服务实例标签相对静态，应用启动后初始化一次之后就不再变更。但是在实际的应用场景下，不同的请求往往需要设置不同的标签信息。此时则需要通过动态染色的能力。
为请求动态染色也非常简单，只需增加以 X-Polaris-Metadata-Transitive- 为前缀的 HTTP 请求头即可，例如：X-Polaris-Metadata-Transitive-version=f1。此时 version=f1 就能够作为请求标签在链路上透传。
以一个模拟的业务场景为例，期望所有 app 过来的请求都转发到专门为 app 搭建的一套环境，而 web 过来的请求都转发到专门为 web 搭建的一套环境。
此时一个请求带有 source=app、system-metadata-router-keys=source 两个标签。app 组和 web 组部署的两套环境中的实例都带有相应的 source 标签。在网关转发流量时，根据 source 标签匹配流量和服务实例，即可完成需求。
需要额外说明 system-metadata-router-keys=source 的作用。请求流量可能具有很多标签，但是用于元数据路由匹配的标签是其中的一部分，所以我们需要在项目中添加 system-metadata-router-keys=key1,key2 声明特定的系统流量标签中的哪些 key 将作为元数据路由匹配的标签。你可以在配置文件中指定：
spring:
cloud:
tencent:
metadata:
content:
system-metadata-router-keys: label1,regionSCT中还支持其他方式可以设定system-metadata-router-keys，具体请参考元数据传输。
元数据路由的原理其实非常简单，以 feign 调用为例，例如调用 http://user-serivce/user/get。
- 根据服务名（user-service）获取目标服务全量实例地址集合
- 这一步中，SCT 只会返回健康的实例集合。细节可参考源码PolarisLoadBalancer.java
- 根据元数据路由规则从全量实例中挑出部分满足规则的实例子集
- 这一步中，SCT 会执行一次地址 Filter 链，输入是全量地址，输出是经过所有地址 Filter 之后的结果。其中一个 Filter 就是元数据路由 Filter MetadataRouter。执行 Filter 链的调用代码请参考：PolarisLoadBalancerCompositeRule#doRouter
- 根据第二步的实例子集，执行负载均衡策略，选中其中一个实例。并替换请求 Url 例如：
http://192.168.1.1:8080/user/get
- 执行负载均衡调用代码请参考：PolarisLoadBalancerCompositeRule#choose