-
Notifications
You must be signed in to change notification settings - Fork 495
服务路由之就近路由
lepdou edited this page Nov 22, 2022
·
8 revisions
生产环境服务为了高可用、容灾等能力往往需要多机房、多城市、多地域部署。
如上图所示,范围从小到大依次为: Campus
< Zone
< Region
< All
其中 Campus
、Zone
、Region
在服务注册发现领域模型里统一定义为元数据,是一种特殊的位置元数据(Location Metadata
)。
以一个实际的部署模型为例:上海机房一、上海机房二、杭州机房一、杭州机房二、北京机房。
- 三层模型
-
Campus
(上海机房一) <Zone
(上海) <Region
(华东)
- 三层模型有时太过于复杂,也可简化成两层模型
-
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
通过环境变量打标是一种最简单的方式,但是公司内部可能有其它的方式打标,例如:
- 在机器上的某一个配置文件,例如:
/etc/metadata
- 通过调用 CMDB 获取位置信息
所以 SCT 定义了一个 InstanceMetadataProvider SPI
用于用户自定义实现获取位置信息。
就近路由插件默认匹配区间为 [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
。
- 根据服务名(user-service)获取目标服务全量实例地址集合
- 这一步中,SCT 只会返回健康的实例集合。细节可参考源码PolarisLoadBalancer.java
- 根据元数据路由规则从全量实例中挑出部分满足规则的实例子集
- 这一步中,SCT 会执行一次地址 Filter 链,输入是全量地址,输出是经过所有地址 Filter 之后的结果。其中一个 Filter 就是就近路由 Filter NearbyRouter。执行 Filter 链的调用代码请参考:PolarisLoadBalancerCompositeRule#doRouter
- 根据第二步的实例子集,执行负载均衡策略,选中其中一个实例。并替换请求 Url 例如:
http://192.168.1.1:8080/user/get
- 执行负载均衡调用代码请参考:PolarisLoadBalancerCompositeRule#choose
- 您在使用过程中遇到任何问题,请提 Issue 或者加入我们的开发者群告诉我们,我们会在第一时间反馈
- Spring Cloud Tencent 社区期待您的加入,一个 Star、PR 都是对我们最大的支持
- 项目介绍
- 使用指南
- 最佳实践
- 开发文档
- 学习资料