客户端染色
流程简介
如概述所言,测试环境路由的开发工作分为三个阶段:
- 阶段一:实例打标。在多测试环境的场景中,需要对每个测试环境部署的实例进行区分,因此需要在实例上打类似标识实例测试环境类别的标签。
- 阶段二:部署应用。
- 阶段三:流量染色。流量染色即为每个请求打上目标测试环境标签,路由转发时根据请求标签匹配请求。
如下图所示,开发者给每个环境的应用实例进行打标(如 featureenv=f1
),标明其所在的环境类型。阶段二部署业务应用。阶段三中,开发者在请求头添加相应的流量标签,即可完成测试环境路由。
操作指引
阶段一
微服务框架服务注册场景
Spring Cloud Tencent 框架接入
Spring Cloud Tencent 中的 spring-cloud-tencent-featureenv-plugin
模块闭环了测试环境路由全部能力,所有服务只需要添加该依赖即可引入测试环境路由能力。spring-cloud-tencent-featureenv-plugin
默认以 featureenv
标签作为匹配标签,用户也可以通过系统内置的 system-feature-env-router-label=custom_feature_env_key
标签来指定测试环境路由使用的标签键。以下三种方式以默认的 featureenv
作为示例。设置方式详情参考Spring Cloud Tencent 元数据使用说明。
- 方式一:配置文件
在服务实例的配置文件中添加配置,如在 bootstrap.yml
添加如下所示即可:
spring:
cloud:
tencent:
metadata:
content:
featureenv: f1 # f1 替换为测试环境名称
- 方式二:环境变量
在服务实例所在的操作系统中添加环境变量也可进行打标,例如:SCT_METADATA_CONTENT_featureenv=f1
。
- 方式三:SPI 方式
自定义实现
InstanceMetadataProvider#getMetadata()
方法的返回值里里包含featureenv
即可。
注意:基线环境部署的服务实例不需要设置 featureenv
标签,表明其不属于任何测试环境,才可在请求没有匹配到对应测试环境的时候,匹配到基线环境。
kubernetes服务注册场景
北极星提供了polaris-controller,支持直接将pod labels同步为北极星上面的实例标签。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
做完上面2步后,polaris-controller默认会对集群中的服务数据进行全量同步,而pod中的labels也会同步为北极星的实例标签。
阶段二
在 VM 或者容器中部署业务应用,需要保证业务应用与北极星服务治理中心的网络连通性。
阶段三
开发者在客户端发出的 HTTP 请求里,新增 X-Polaris-Metadata-Transitive-featureenv=f1
请求头即可实现流量染色。
请求头
X-Polaris-Metadata-Transitive-featureenv=f1
是按照北极星定义的请求头格式设置的,其中X-Polaris-Metadata-Transitive-
是北极星需要读取请求头的前缀,例子中的featureenv
为实际的键值对的key,f1
为实际的键值对的value。
原理解析
-
标签筛选:用户传入的env=f1,spring cloud tencent会基于从北极星发现的实例数据,筛选出匹配env=f1的实例,并进行服务调用。
-
标签透传:在微服务的调用链路中,spring cloud tencent框架会将用户的请求标签逐级往下透传,使得每一层调用都可以优先调度都env=f1的实例上。