Tars | 第4篇 Subset路由规则业务分析与源码探索
前言
通过中期汇报交流会,笔者对Subset业务流程有了一个较为深刻的了解;同时也对前期的一些误区有了认识。本篇为更新Subset业务分析,以及纠正误区。
1. Subset不是负载均衡
简单描述前期工作的误区;
1.1 任务需求
在项目开展之初,笔者只知道Subset路由规则是建立在原有负载均衡逻辑之上,因此花了大量时间在负债均衡上:

1.2 负载均衡源码结构图
通过源码分析(详情参照往期文章),可以得到TarsJava里负载均衡的的源码结构图,(基于TarsJava SpringBoot):
@EnableTarsServer注解:表明这是一个Tars服务;
- @Import(TarsServerConfiguration.class):引入Tars服务相关配置文件;
- Communcator:通信器;
- getServantProxyFactory():获取代理工厂管理者;
- getObjectProxyFactory():获取对象代理工厂;
- createLoadBalance():创建客户端负载均衡调用器;
- select():选择负载均衡调用器(有四种模式可以选择);
- invoker:调用器;
- invoke():具体的执行方法;
- doInvokeServant():最底层的执行方法;
- invoke():具体的执行方法;
- invoker:调用器;
- refresh():更新负载均衡调用器;
- select():选择负载均衡调用器(有四种模式可以选择);
- createProtocolInvoker():创建协议调用器;
- createLoadBalance():创建客户端负载均衡调用器;
- Communcator:通信器;
1.3 负载均衡四种调用器
其中负载均衡跟流量分配与路由强相关,而在TarsJava里,负载均衡有四种调用器可供选择:
- ConsistentHashLoadBalance:一致hash选择器;
- HashLoadBalance:hash选择器;
- RoundRobinLoadBalance: 轮询选择器;
- DefaultLoadBalance:默认的选择器(由源码可知先ConsistentHashLoadBalance,HashLoadBalance,RoundRobinLoadBalance);
1.4 新增两种负载均衡调用器
结合需求文档,笔者以为Subset就是增加两个负载均衡调用器:
- ProportionLoadBalance:按比例路由;
- DyeLoadBalance:按染色路由;
新的业务流程是是:
- 首先判断是否为按比例 / 染色路由,并调用对应负载均衡调用器;
- 接着进行原负载均衡逻辑;
- 将路由结果封装到status里;
1.5 Subset应该是“过滤”节点而不是“选择”节点
这样理解并没有错,因为Subset路由规则就是在负载均衡之前;但准确来说,这样理解其实是有误的,因为Subset不是负载均衡。
subset是set的子集,所以是如果subset字段有设置的话,是在负责均衡之前,需要先根据subset字段类似于set选择活跃节点的那里,根据规则选出subset的活跃节点。
也就是说,Subset更多的起到的作用不是负载均衡那样的选择节点(返回一个),而是更像过滤器那样的过滤节点(返回多个)。
因此有必要重新分析源码,找到客户端获取服务节点的源码位置,并分析理解。
2. 从头开始源码分析
我们需要找到获取服务端节点的地方。
由于有前面的源码基础,我们可以很快定位到源码的这个位置:
@EnableTarsServer注解:表明这是一个Tars服务;
- @Import(TarsServerConfiguration.class):引入Tars服务相关配置文件;
- Communcator:通信器;
- getServantProxyFactory():获取代理工厂管理者;
- getObjectProxyFactory():获取对象代理工厂;
- Communcator:通信器;
2.1 getObjectProxyFactory()源码分析
protected ObjectProxyFactory getObjectProxyFactory() {
return objectProxyFactory;
}
getObjectProxyFactory()方法返回一个ObjectProxyFactory对象代理工厂,我们点进去看看这个工厂干了什么:
public <T> ObjectProxy<T> getObjectProxy(Class<T> api, String objName, String setDivision, ServantProxyConfig servantProxyConfig,
LoadBalance<T> loadBalance, ProtocolInvoker<T> protocolInvoker) throws ClientException {
//服务代理配置
if (servantProxyConfig == null) {
servantProxyConfig = createServantProxyConfig(objName, setDivision);
} else {
servantProxyConfig.setCommunicatorId(communicator.getId());
servantProxyConfig.setModuleName(communicator.getCommunicatorConfig().getModuleName(), communicator.getCommunicatorConfig().isEnableSet(), communicator.getCommunicatorConfig().getSetDivision());
servantProxyConfig.setLocator(communicator.getCommunicatorConfig().getLocator());
addSetDivisionInfo(servantProxyConfig, setDivision);
servantProxyConfig.setRefreshInterval(communicator.getCommunicatorConfig().getRefreshEndpointInterval());
servantProxyConfig.setReportInterval(communicator.getCommunicatorConfig().getReportInterval());
}
//更新服务端节点
updateServantEndpoints(servantProxyConfig);
//创建负载均衡
if (loadBalance == null) {
loadBalance = createLoadBalance(servantProxyConfig);
}
//创建协议调用
if (protocolInvoker == null) {
protocolInvoker = createProtocolInvoker(api, servantProxyConfig);
}
return new ObjectProxy<T>(api, servantProxyConfig, loadBalance, protocolInvoker, communicator);
}
工厂的核心作用是生成代理对象,在这里,先是进行服务配置,更新服务端节点,然后创建负载均衡与协议调用,最后将配置好的代理对象返回。
2.2 updateServantEndpoints()更新服务端节点源码分析
我们需要关注和的地方就在updateServantEndpoints()更新服务端节点方法里,我们找到这个方法的源码如下:
private void updateServantEndpoints(ServantProxyConfig cfg) {
CommunicatorConfig communicatorConfig = communicator.getCommunicatorConfig();
String endpoints = null;
if (!ParseTools.hasServerNode(cfg.getObjectName()) && !cfg.isDirectConnection() && !communicatorConfig.getLocator().startsWith(cfg.getSimpleObjectName())) {
try {
/** 从注册表服务器查询服务器节点 */
if (RegisterManager.getInstance().getHandler() != null) {
//解析出服务端节点,用“:”隔离
endpoints = ParseTools.parse(RegisterManager.getInstance().getHandler().query(cfg.getSimpleObjectName()),
cfg.getSimpleObjectName());
} else {
endpoints = communicator.getQueryHelper().getServerNodes(cfg);
}
if (StringUtils.isEmpty(endpoints)) {
throw new CommunicatorConfigException(cfg.getSimpleObjectName(), "servant node is empty on get by registry! communicator id=" + communicator.getId());
}
ServantCacheManager.getInstance().save(communicator.getId(), cfg.getSimpleObjectName(), endpoints, communicatorConfig.getDataPath());
} catch (CommunicatorConfigException e) {
/** 如果失败,将其从本地缓存文件中取出 */
endpoints = ServantCacheManager.getInstance().get(communicator.getId(), cfg.getSimpleObjectName(), communicatorConfig.getDataPath());
logger.error(cfg.getSimpleObjectName() + " error occurred on get by registry, use by local cache=" + endpoints + "|" + e.getLocalizedMessage(), e);
}
if (StringUtils.isEmpty(endpoints)) {
throw new CommunicatorConfigException(cfg.getSimpleObjectName(), "error occurred on create proxy, servant endpoint is empty! locator =" + communicatorConfig.getLocator() + "|communicator id=" + communicator.getId());
}
//将服务端节点信息保存进CommunicatorConfig配置项的ObjectName属性里
cfg.setObjectName(endpoints);
}
if (StringUtils.isEmpty(cfg.getObjectName())) {
throw new CommunicatorConfigException(cfg.getSimpleObjectName(), "error occurred on create proxy, servant endpoint is empty!");
}
}
方法的核心功能在try语句那里,就是去获取服务端的所有结点,获取的逻辑是:
- 如果服务器没有实例化,就从
CommunicatorConfig通信器配置项中通过getServerNodes()方法获取服务节点列表; - 如果服务器已经实例化,就根据挂载的服务名获取服务节点列表;
- 如果上述操作失败,就从缓存中获取服务节点列表;
2.3 getServerNodes()获取服务端节点源码分析
可以看出获取服务端节点的核心方法是getServerNodes(),源码如下:
public String getServerNodes(ServantProxyConfig config) {
QueryFPrx queryProxy = getPrx();
String name = config.getSimpleObjectName();
//存活的节点
Holder<List<EndpointF>> activeEp = new Holder<List<EndpointF>>(new ArrayList<EndpointF>());
//挂掉的节点
Holder<List<EndpointF>> inactiveEp = new Holder<List<EndpointF>>(new ArrayList<EndpointF>());
int ret = TarsHelper.SERVERSUCCESS;
//判断是否为启用集
if (config.isEnableSet()) {
ret = queryProxy.findObjectByIdInSameSet(name, config.getSetDivision(), activeEp, inactiveEp);
} else {
ret = queryProxy.findObjectByIdInSameGroup(name, activeEp, inactiveEp);
}
if (ret != TarsHelper.SERVERSUCCESS) {
return null;
}
Collections.sort(activeEp.getValue());
//value就是最后的节点参数
//将获取到的节点列表格式化为一个字符串格式
StringBuilder value = new StringBuilder();
if (activeEp.value != null && !activeEp.value.isEmpty()) {
for (EndpointF endpointF : activeEp.value) {
if (value.length() > 0) {
value.append(":");
}
value.append(ParseTools.toFormatString(endpointF, true));
}
}
//个格式化后的字符串加上Tars的服务名
if (value.length() < 1) {
return null;
}
value.insert(0, Constants.TARS_AT);
value.insert(0, name);
return value.toString();
}
getServerNodes()的处理逻辑是:
getServerNodes()首先创建两个Holder对象,用来保存存活节点列表activeEp与不存活节点列表inactiveEp的值;- 接着判断是否为启用集,使用对象代理的方式,调用
findObjectByIdInSameSet()或findObjectByIdInSameGroup()方法获取到存活与不存活节点列表的值封装进activeEp与inactiveEp里; - 将获取到的节点列表格式化为一个字符串格式
value; - 进行后续格式化操作;
2.4 endpoints的格式
通过以下测试方法我们可以知道格式化后是字符串格式如下:
abc@tcp -h host1 -p 1 -t 3000 -a 1 -g 4 -s setId1 -v 10 -w 9:tcp -h host2 -p 1 -t 3000 -a 1 -g 4 -s setId2 -v 10 -w 9

3. Subset应该添加在哪
Subset应该在节点列表格式化之前。
3.1 获取服务端节点的源码结构图
通过上述分析,我们可得出获取服务端节点getServerNodes()的源码结构图:
@EnableTarsServer注解:表明这是一个Tars服务;
- @Import(TarsServerConfiguration.class):引入Tars服务相关配置文件;
- Communcator:通信器;
- getServantProxyFactory():获取代理工厂管理者;
- getObjectProxyFactory():获取对象代理工厂;
- updateServantEndpoints(): 更新服务端节点;
- getServerNodes():获取服务节点列表;
- updateServantEndpoints(): 更新服务端节点;
- Communcator:通信器;
3.2 修改getServerNodes()方法
由上述分析,我们可以知道:getServerNodes()的处理逻辑是:
- 首先创建两个Holder对象;
- 接着获取到存活与不存活节点列表的值封装进
activeEp与inactiveEp里; - 将获取到的节点列表格式化为一个字符串格式
value; - 进行后续格式化操作;
我们要在数据格式化前将列表里的节点进行过滤,不然如果先格式化字符串再过滤,将会涉及字符串的操作,当服务的节点过多是,这部分字符串的校验与判断将会十分消耗性能,因此要在格式化前通过Subset规则过滤节点,修改后的getServerNodes()方法如下:
public String getServerNodes(ServantProxyConfig config) {
QueryFPrx queryProxy = getPrx();
String name = config.getSimpleObjectName();
//存活的节点
Holder<List<EndpointF>> activeEp = new Holder<List<EndpointF>>(new ArrayList<EndpointF>());
//挂掉的节点
Holder<List<EndpointF>> inactiveEp = new Holder<List<EndpointF>>(new ArrayList<EndpointF>());
int ret = TarsHelper.SERVERSUCCESS;
//判断是否为启用集
if (config.isEnableSet()) {
ret = queryProxy.findObjectByIdInSameSet(name, config.getSetDivision(), activeEp, inactiveEp);
} else {
ret = queryProxy.findObjectByIdInSameGroup(name, activeEp, inactiveEp);
}
if (ret != TarsHelper.SERVERSUCCESS) {
return null;
}
Collections.sort(activeEp.getValue());
//value就是最后的节点参数
// //将获取到的节点列表格式化为一个字符串格式
// StringBuilder value = new StringBuilder();
// if (activeEp.value != null && !activeEp.value.isEmpty()) {
// for (EndpointF endpointF : activeEp.value) {
// if (value.length() > 0) {
// value.append(":");
// }
// value.append(ParseTools.toFormatString(endpointF, true));
// }
// }
//对上述注释代码做抽取,增加按subset规则过滤节点
StringBuilder value = filterEndpointsBySubset(activeEp, config);
//个格式化后的字符串加上Tars的服务名
if (value.length() < 1) {
return null;
}
value.insert(0, Constants.TARS_AT);
value.insert(0, name);
return value.toString();
}
修改的逻辑是:
- 抽取将节点列表格式化为一个字符串格式
value的代码; - 添加
filterEndpointsBySubset(activeEp, config)根据Subset规则过滤节点方法;- 该方法的参数为存活节点列表与路由规则;
- 该方法的逻辑是先进行Subset规则判断,再进行节点列表的数据格式;
3.3 添加的filterEndpointsBySubset()方法
该方法的实现逻辑代码如下:
public StringBuilder filterEndpointsBySubset(Holder<List<EndpointF>> activeEp, ServantProxyConfig config){
StringBuilder value = new StringBuilder();
//config的非空判断
if(config == null){
return null;
}
String ruleType = config.getRuleType();
Map<String, String> ruleData = config.getRuleData();
String routeKey = config.getRouteKey();
if(ruleData.size() < 1 || ruleType == null){
return null;
}
//按比例路由
if(Constants.TARS_SUBSET_PROPORTION.equals(ruleType)){
int totalWeight = 0;
int supWeight = 0;
String subset = null;
//获得总权重
for(String weight : ruleData.values()){
totalWeight+=Integer.parseInt(weight);
}
//获取随机数
Random random = new Random();
int r = random.nextInt(totalWeight);
//根据随机数找到subset
for (Map.Entry<String, String> entry : ruleData.entrySet()){
supWeight+=Integer.parseInt(entry.getValue());
if( r < supWeight){
subset = entry.getKey();
break;
}
}
//利用subset过滤不符合条件的节点
if (activeEp.value != null && !activeEp.value.isEmpty()) {
for (EndpointF endpointF : activeEp.value) {
//subset判断
if(endpointF != null && endpointF.getSubset().equals(subset)){
if (value.length() > 0) {
value.append(":");
}
value.append(ParseTools.toFormatString(endpointF, true));
}
}
}
return value;
}
//按请求参数路由
if(Constants.TARS_SUBSET_PARAMETER.equals(ruleType)){
//获取将要路由到的路径
String route = ruleData.get("route");
if( route == null ){
return null;
}
//判断是否含有键“equal”;“match”,并获取染色Key
String key;
if(ruleData.containsKey("equal")){
//精确路由
key = ruleData.get("equal");
//对染色Key做非空校验
if(key == null || "".equals(key)){
return null;
}
//利用subset过滤不符合条件的节点
if (activeEp.value != null && !activeEp.value.isEmpty()) {
for (EndpointF endpointF : activeEp.value) {
//subset判断,精确判断
if(endpointF != null && routeKey.equals(key) && route.equals(endpointF.getSubset())){
if (value.length() > 0) {
value.append(":");
}
value.append(ParseTools.toFormatString(endpointF, true));
}
}
}
} else if( ruleData.containsKey("match")){
//正则路由
key = ruleData.get("match");
//对染色Key做非空校验
if(key == null || "".equals(key)){
return null;
}
//利用subset过滤不符合条件的节点
if (activeEp.value != null && !activeEp.value.isEmpty()) {
for (EndpointF endpointF : activeEp.value) {
//subset判断,正则规则
if(endpointF != null && StringUtils.matches(key, routeKey) && route.equals(endpointF.getSubset())){
if (value.length() > 0) {
value.append(":");
}
value.append(ParseTools.toFormatString(endpointF, true));
}
}
}
} else {
//【报错】
return null;
}
return value;
}
//无规则路由
if(Constants.TARS_SUBSET_DEFAULT.equals(ruleType)){
//获取将要路由到的路径
String route = ruleData.get("default");
if( route == null ){
return null;
}
//利用subset过滤不符合条件的节点
if (activeEp.value != null && !activeEp.value.isEmpty()) {
for (EndpointF endpointF : activeEp.value) {
//subset判断
if(endpointF != null && endpointF.getSubset().equals(route)){
if (value.length() > 0) {
value.append(":");
}
value.append(ParseTools.toFormatString(endpointF, true));
}
}
}
return value;
}
return value;
}
由于方法比较冗余,但思路没错,测试跑的通,后期需要进一步修改简化、优化。
4. 总结
4.1 Subset不是负载均衡
Subset流量路由应该在负载均衡之前,相当于一个过滤器。
4.2 getServerNodes()的源码结构图
可以知道获取服务端节点的思想逻辑,获取服务端节点getServerNodes()的源码结构图:
@EnableTarsServer注解:表明这是一个Tars服务;
- @Import(TarsServerConfiguration.class):引入Tars服务相关配置文件;
- Communcator:通信器;
- getServantProxyFactory():获取代理工厂管理者;
- getObjectProxyFactory():获取对象代理工厂;
- updateServantEndpoints(): 更新服务端节点;
- getServerNodes():获取服务节点列表;
- updateServantEndpoints(): 更新服务端节点;
- Communcator:通信器;
4.3 核心在filterEndpointsBySubset()方法
该方法的主要作用为根据Subset规则过滤节点,并且进行节点列表的格式化操作。
最后
新人制作,如有错误,欢迎指出,感激不尽!
欢迎关注公众号,会分享一些更日常的东西!
如需转载,请标注出处!

Tars | 第4篇 Subset路由规则业务分析与源码探索的更多相关文章
- Tars | 第2篇 TarsJava SpingBoot启动与负载均衡源码初探
目录 前言 1. Tars客户端启动 @EnableTarsServer 2. Communicator通信器 3. 客户端的负载均衡调用器LoadBalance 最后 前言 通过源码分析可以得出这样 ...
- Tars | 第6篇 基于TarsGo Subset路由规则的Java JDK实现方式(下)
目录 前言 1. 修改.tars协议文件 1.1 Java源码位置及逻辑分析 1.2 Java语言实现方式 1.3 通过协议文件自动生成代码 1.4 变更代码的路径 2. [核心]增添Subset核心 ...
- Tars | 第3篇 Tars中期汇报测试文档(Java语言实现Subset路由规则)
目录 前言 1. 任务介绍 2. 测试模拟方案 2.0 *前置工作 2.1 添加路由规则 2.2 添加存活节点 2.3 [输出]遍历输出当前存活节点 2.4 [核心]对存活节点按subset规则过滤 ...
- Tars | 第5篇 基于TarsGo Subset路由规则的Java JDK实现方式(上)
目录 前言 1. 修改.tars协议文件 1.1 Go语言修改部分 1.2 修改地方的逻辑 1.3 通过协议文件自动生成代码 2. [核心]增添Subset核心功能 2.1 Go语言修改部分 2.2 ...
- 鸿蒙内核源码分析(寄存器篇) | 小强乃宇宙最忙存储器 | 百篇博客分析OpenHarmony源码 | v38.02
百篇博客系列篇.本篇为: v38.xx 鸿蒙内核源码分析(寄存器篇) | 小强乃宇宙最忙存储器 | 51.c.h .o 硬件架构相关篇为: v22.xx 鸿蒙内核源码分析(汇编基础篇) | CPU在哪 ...
- 鸿蒙内核源码分析(工作模式篇) | CPU是韦小宝,七个老婆 | 百篇博客分析OpenHarmony源码 | v36.04
百篇博客系列篇.本篇为: v36.xx 鸿蒙内核源码分析(工作模式篇) | CPU是韦小宝,七个老婆 | 51.c.h .o 硬件架构相关篇为: v22.xx 鸿蒙内核源码分析(汇编基础篇) | CP ...
- 鸿蒙内核源码分析(定时器篇) | 哪个任务的优先级最高 | 百篇博客分析OpenHarmony源码 | v31.02
百篇博客系列篇.本篇为: v31.xx 鸿蒙内核源码分析(定时器篇) | 哪个任务的优先级最高 | 51.c.h .o 本篇说清楚定时器的实现 读本篇之前建议先读鸿蒙内核源码分析(总目录)其余篇. 运 ...
- 鸿蒙内核源码分析(进程概念篇) | 进程在管理哪些资源 | 百篇博客分析OpenHarmony源码 | v24.01
百篇博客系列篇.本篇为: v24.xx 鸿蒙内核源码分析(进程概念篇) | 进程在管理哪些资源 | 51.c.h .o 进程管理相关篇为: v02.xx 鸿蒙内核源码分析(进程管理篇) | 谁在管理内 ...
- 鸿蒙内核源码分析(内存规则篇) | 内存管理到底在管什么 | 百篇博客分析OpenHarmony源码 | v16.02
百篇博客系列篇.本篇为: v16.xx 鸿蒙内核源码分析(内存规则篇) | 内存管理到底在管什么 | 51.c.h .o 内存管理相关篇为: v11.xx 鸿蒙内核源码分析(内存分配篇) | 内存有哪 ...
随机推荐
- empty(), is_null(), isset()真值表(区别)
- noip模拟30[毛毛毛探探探]
\(noip模拟30\;solutions\) 所以说,这次被初中的大神给爆了????? 其实真的不甘心,这次考场上的遗憾太多,浪费的时间过多,心情非常不好 用这篇题解来结束这场让人伤心的考试吧 \( ...
- Synology群晖100TB万兆文件云服务器NAS存储池类别 RAID 6 (有数据保护)2021年7月29日 - Copy
Synology群晖100TB万兆文件云服务器NAS存储池类别 RAID 6 (有数据保护)2021年7月29日 - Copy https://www.autoahk.com/archives/367 ...
- “百度杯”CTF比赛 十月场-Getflag(md5碰撞+sql注入+网站绝对路径)
进去md5碰撞,贴一下脚本代码 import hashlib def md5(value): return hashlib.md5(str(value).encode("utf-8" ...
- C++ //继承中的对象模型 //利用开发人员命令提示工具查看对象模型 //父类中所有非静态成员属性都会被 子类继承下去 //父类中私有成员属性 是被编译器给隐藏了 因此是访问不到 但是确实被继承下去了
1 //继承方式 2 //语法:class 子类 :继承方式 父类 3 //继承方式 三种: 4 //1.公共继承 5 //2.保护继承 6 //3.私有继承 7 8 /* 9 #include &l ...
- Spring学习笔记--面向切面编程(AOP)
什么是AOP AOP(Aspect Oriented Programming),意为面向切面编程,通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术.AOP是OOP的延续,是软件开发中的 ...
- Linux 基础学习篇 序篇
读序篇可以知道的: 1.有些指令知道前和知道后,自己的操作是完全不同的,可能知道前,会用reset把系统重新启动一遍,而知道后会使用ps和kill来关闭进程. 2.如果对Linus的学习知识" ...
- Qt项目简易开发原理及常见问题解决
一.资源下载地址 https://www.aliyundrive.com/s/jBU2wBS8poH 本项目路径:项目->免费->QtDev 注释:为了方便qt全功能开发,QtDev中包含 ...
- S3C2440—9.复制程序到SDRAM中执行
文章目录 一.S3C2440的启动方式 二.代码 一.S3C2440的启动方式 S3C2440的MMU有一种"steppingstone".技术,是协助MCU从无法执行程序的NAN ...
- 在java程序中使用protobuf
目录 简介 为什么使用protobuf 定义.proto文件 编译协议文件 详解生成的文件 Builders 和 Messages 序列化和反序列化 协议扩展 总结 简介 Protocol Buffe ...