服务路由之就近路由

就近路由简介

生产环境服务为了高可用、容灾等能力往往需要多机柜、多机房、多地域部署。

如上图所示，范围从小到大依次为: Campus < Zone < Region < All

其中 Campus、Zone、Region 在服务注册发现领域模型里统一定义为元数据，是一种特殊的位置元数据（Location Metadata）。

就近路由顾名思义，服务调用时按照 同 Campus、同 Zone、同 Region 的优先级从高到低依次选取目标服务实例。核心是减少服务调用因物理距离增加的网络耗时。

本质上，就近路由是一种基于特定一组位置元数据的元数据路由。

就近路由操作篇

步骤一：基础操作

注意：1.5.0 版本后才支持元数据路由

请参考 服务路由基础操作 文档，引入依赖以及增加配置。

步骤二：设置服务位置元数据标签

方式一：环境变量

SCT（Spring Cloud Tencent 的缩写） 内置了一组位置元数据环境变量标签：

• SCT_METADATA_CAMPUS
• SCT_METADATA_ZONE
• SCT_METADATA_REGION

服务在启动时，SCT 会读取这一组环境变量作为元数据上报到注册中心，从而传递到主调端。

可以通过查看启动日志确认是否正确打标：

grep "Loaded static metadata info" xx.log

方式二：动态 SPI（待实现）

通过环境变量打标是一种最简单的方式，但是公司内部可能有其它的方式打标，例如：

• 在机器上的某一个配置文件，例如：/etc/metadata
• 通过调用 CMDB 获取位置信息

所以 SCT 定义了一个 SPI 用于用户自定义实现获取位置信息。

就近路由原理篇

就近路由的原理其实非常简单，以 feign 调用为例，例如调用 http://user-serivce/user/get。

1. 根据服务名（user-service）获取目标服务全量实例地址集合

• 这一步中，SCT 只会返回健康的实例集合。细节可参考源码PolarisLoadBalancer.java

2. 根据元数据路由规则从全量实例中挑出部分满足规则的实例子集

• 这一步中，SCT 会执行一次地址 Filter 链，输入是全量地址，输出是经过所有地址 Filter 之后的结果。其中一个 Filter 就是就近路由 Filter NearbyRouter。执行 Filter 链的调用代码请参考：PolarisLoadBalancerCompositeRule#doRouter

3. 根据第二步的实例子集，执行负载均衡策略，选中其中一个实例。并替换请求 Url 例如：http://192.168.1.1:8080/user/get

• 执行负载均衡调用代码请参考：PolarisLoadBalancerCompositeRule#choose