服务路由之就近路由

目录

• 就近路由简介
• 就近路由操作篇
  • 步骤一：基础操作
  • 步骤二：设置服务位置元数据标签
  • 步骤三：设置匹配 Level 区间
• 就近路由原理篇

就近路由简介

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

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

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

以一个实际的部署模型为例：上海机房一、上海机房二、杭州机房一、杭州机房二、北京机房。

1. 三层模型

• Campus(上海机房一) < Zone(上海) < Region（华东）

2. 三层模型有时太过于复杂，也可简化成两层模型

• Zone(上海机房一) < Region (上海)

就近路由顾名思义，服务调用时按照 同 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 定义了一个 InstanceMetadataProvider SPI 用于用户自定义实现获取位置信息。

步骤三：设置匹配 Level 区间

就近路由插件默认匹配区间为 [Zone, All]，也就是优先匹配 Zone，如果未匹配到，则继续匹配 Region，适用于简单的两层模型。

如果您的部署模型为三层模型（Campus、Zone、Region），则需要增加配置项从 Campus 开始匹配。

consumer:
  serviceRouter:
    plugin:
      nearbyBasedRouter:
        #描述: 就近路由的最小匹配级别。region(大区)、zone(区域)、campus(园区)
        matchLevel: campus
        #描述: 最大匹配级别
        maxMatchLevel: all

就近路由原理篇

就近路由的原理其实非常简单，以 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