前言

SOFA-RPC 中对服务地址的选择也抽象为了一条处理链,由每一个 Router 进行处理。同 Filter 一样, SOFA-RPC 对 Router 提供了同样的扩展能力。

那么就看看 SOFA 是如何处理的。

如何使用

官方教程如下:

@Extension(value = "customerRouter")
@AutoActive(consumerSide = true)
public class CustomerRouter extends Router { @Override
public void init(ConsumerBootstrap consumerBootstrap) { }
@Override
public boolean needToLoad(ConsumerBootstrap consumerBootstrap) {
return ture;
}
@Override
public List<ProviderInfo> route(SofaRequest request, List<ProviderInfo> providerInfos) {
return providerInfos;
}

新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router 。内容如下:

customerRouter=com.alipay.sofa.rpc.custom.CustomRouter

如上自定义了一个 CustomerRouter ,生效于所有消费者。其中 init 参数 ConsumerBootstrap 是引用服务的包装类,能够拿到 ConsumerConfig ,代理类,服务地址池等对象。 needToLoad 表示是否生效该 Router , route 方法即筛选地址的方法。

可以看到,Router 也是通过 SOFA 的扩展机制实现的,通过定义一个 SPI 文件,能够有效的解耦。

然后我们再来看看他的原理。

源码解析

在 SOFA 中, Router 是个抽象类,内部定义了 4 个方法:

//初始化
public void init(ConsumerBootstrap consumerBootstrap) {
} //是否自动加载
public boolean needToLoad(ConsumerBootstrap consumerBootstrap) {
return true;
}
// 筛选Provider
public abstract List<ProviderInfo> route(SofaRequest request, List<ProviderInfo> providerInfos); //记录路由路径记录
protected void recordRouterWay(String routerName) {
if (RpcInternalContext.isAttachmentEnable()) {
RpcInternalContext context = RpcInternalContext.getContext();
String record = (String) context.getAttachment(RpcConstants.INTERNAL_KEY_ROUTER_RECORD);
record = record == null ? routerName : record + ">" + routerName;
context.setAttachment(RpcConstants.INTERNAL_KEY_ROUTER_RECORD, record);
}
}

子类必须实现 route 方法,该方法的参数是 SofaRequest 和一个 ProviderInfo List。然后,返回值是筛选过的 ProviderInfo List。即用户可以在自定义的 Router 中筛选 Router 使用。负载均衡会从用户的 ProviderInfo List 中选择一个 ProviderInfo 进行调用。

路由顺序按照 Extension 注解的 order 进行从小到大排序。

同时, SOFA 上下文 RpcInternalContext 会记录此次调用的路径,也就是路由名字。

而目前框架中有 3 个实现类:

  1. DirectUrlRouter 直连路由,needToLoad 判断条件是客户端是否设置了只来路由。路由规则是:从地址保持器中选取直连地址,然后添加到 List 中。
  2. ExcludeRouter 要排除的过滤器,目前暂没有定义。用户可自己扩展。
  3. RegistryRouter 从注册中心获取地址进行路由。needToLoad 条件是:如果没有设置直连地址且从注册中心订阅服务。路由规则:从地址保持器中获取默认的(注册中心)服务列表,并添加进 List 返回。

其中,这个地址保持/管理器是什么鬼呢?

每个客户端都有一个地址管理器 —— AddressHolder。管理着服务的分组。SingleGroupAddressHolder 是 AddressHolder 的具体实现类,也是通过扩展机制实现的。他是一个只支持单个分组的地址选择器(额外存一个直连分组)。

他内部有 2 个 List, 一个是直连地址列表,另一个是注册中心的地址列表。

在 Cluster 初始化的时候,会先初始化 routerChain Router 链,该实例中包含了一个 Router 数组,用于保存路由实例。

同时还会初始化服务端列表,即调用 consumerBootstrap.subscribe() 方法,该方法在 DefaultConsumerBootstrap 中实现如下:

  1. 如果直连地址(逗号或者分号分割)不是空,则返回一个包装了直连地址的 List。
  2. 如果直连地址是空的,则从注册中心获取服务列表。

得到服务列表后,则添加到地址管理器中。同时向事件总线丢一个 ProviderInfoUpdateAllEvent 事件。包括建立长连接——也就是初始化 RpcClient,在调用 updateAllProviders 方法后,会异步的在一个 initPool 线程池中启动多个线程初始化长连接。

好了,现在地址管理器里面已经有连接了。

当客户端调用的时候,也就是 doInvoke 方法,会先从从 routerChain 中获取过滤后的 List ,然后,调用负载均衡的 select 方法,从这些可选的路由中选取一个 ProviderInfo 进行调用。

以上,就是自定义路由寻址,地址管理器的实现原理。

总结

SOFA 为框架用户定义了 Router ,用户可以实现 route 方法,并在该方法中实现过滤策略,从而返回一个用户设置的服务列表,值得注意的是,用户需要定义 order 属性,因为 Router 是从小到大排序的,顺序对于整体逻辑来说非常重要。

和 Router 息息相关的还有地址管理器 —— AddressHolder,该类会管理服务列表,客户端在初始化的时候,会将地址都保存到 AddressHolder 中,在之后的负载均衡选择服务的时候,会从地址管理器中获取服务列表(已经路由过滤的)进行选择。

还有一点需要注意:地址管理器每次 update 的时候,会全量更新连接管理器。如果有新增的服务,就会建立长连接。

SOFA 源码分析— 自定义路由寻址的更多相关文章

  1. SOFA 源码分析 — 自定义线程池原理

    前言 在 SOFA-RPC 的官方介绍里,介绍了自定义线程池,可以为指定服务设置一个独立的业务线程池,和 SOFARPC 自身的业务线程池是隔离的.多个服务可以共用一个独立的线程池. API使用方式如 ...

  2. SOFA 源码分析 —— 服务引用过程

    前言 在前面的 SOFA 源码分析 -- 服务发布过程 文章中,我们分析了 SOFA 的服务发布过程,一个完整的 RPC 除了发布服务,当然还需要引用服务. So,今天就一起来看看 SOFA 是如何引 ...

  3. SOFA 源码分析 — 调用方式

    前言 SOFARPC 提供了多种调用方式满足不同的场景. 例如,同步阻塞调用:异步 future 调用,Callback 回调调用,Oneway 调用. 每种调用模式都有对应的场景.类似于单进程中的调 ...

  4. SOFA 源码分析 — 链路数据透传

    前言 SOFA-RPC 支持数据链路透传功能,官方解释: 链路数据透传功能支持应用向调用上下文中存放数据,达到整个链路上的应用都可以操作该数据. 使用方式如下,可分别向链路的 request 和 re ...

  5. SOFA 源码分析 —— 过滤器设计

    前言 通常 Web 服务器在处理请求时,都会使用过滤器模式,无论是 Tomcat ,还是 Netty,过滤器的好处是能够将处理的流程进行分离和解耦,比如一个 Http 请求进入服务器,可能需要解析 h ...

  6. SOFA 源码分析 — 自动故障剔除

    前言 集群中通常一个服务有多个服务提供者.其中部分服务提供者可能由于网络,配置,长时间 fullgc ,线程池满,硬件故障等导致长连接还存活但是程序已经无法正常响应.单机故障剔除功能会将这部分异常的服 ...

  7. SOFA 源码分析 — 负载均衡和一致性 Hash

    前言 SOFA 内置负载均衡,支持 5 种负载均衡算法,随机(默认算法),本地优先,轮询算法,一致性 hash,按权重负载轮询(不推荐,已被标注废弃). 一起看看他们的实现(重点还是一致性 hash) ...

  8. SOFA 源码分析 — 预热权重

    前言 SOFA-RPC 支持根据权重对服务进行预热功能,具体地址:预热权重. 引用官方文档: 预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发.该功能也常被用于集群内少数机器的启动场景. ...

  9. SOFA 源码分析— 事件总线

    前言 大部分框架都是事件订阅功能,即观察者模式,或者叫事件机制.通过订阅某个事件,当触发事件时,回调某个方法.该功能非常的好用,而 SOFA 内部也设计了这个功能,并且内部大量使用了该功能.来看看是如 ...

随机推荐

  1. OJ题:将一个字符串顺序翻转

    题目描述 写出一个程序,接受一个字符串,然后输出该字符串反转后的字符串. 之前写过这样的一个程序,用位运算的方法去操作指针,但是那样的方法未免就有点复杂啦,不如用以下这种,简单明了. 程序如下: #i ...

  2. android studio2.0出现的gradle问题,instant Run即时运行不了.

    android studio 2.0出现的gradle问题: instant Run即时运行不了.经历了几乎9个preView版本的AS2.0,终于迎来了正式版,然而晴天我的霹雳,好不容易装好的2.0 ...

  3. JSP编译成Servlet(四)JSP与Java行关系映射

    我们知道java虚拟机只认识class文件,要在虚拟机上运行就必须要遵守class文件格式,所以JSP编译成servlet后还需要进一步编译成class文件,但从JSP文件到java文件再到class ...

  4. ZooKeeper实现分布式锁

    使用场景          一般的锁是指单进程多线程的锁,在多线程并发编程中,用于线程之间的数据同步,保证共享资源的访问.而分布式锁,指的是在分布式环境下,保证跨进程.跨主机.跨网络的共享资源,实现互 ...

  5. SMEM介绍

    SMEM :shared memory,是高通平台各子系统共享信息的一种机制,通过SMEM机制,PBL可以将信息传递给SBL1,SBL1可以将信息传递给RPM.LK.下面分析一个SMEM信息传递的具体 ...

  6. 【Android 应用开发】Android 网络编程 API笔记 - java.net 包相关 接口 api

    Android 网络编程相关的包 : 9 包, 20 接口, 103 类, 6 枚举, 14异常; -- Java包 : java.net 包 (6接口, 34类, 2枚举, 12异常); -- An ...

  7. java的参数传递与内存分配问题

    本文可作为北京尚学堂java课程的学习笔记. 看下面这段代码. class BirthDate { private int day; private int month; private int ye ...

  8. 关于SMALI语法

    dalvik字节码有两种类型,原始类型和引用类型.对象和数组是引用类型,其它都是原始类型.V  void,只能用于返回值类型Z  booleanB  byteS  shortC  charI  int ...

  9. androd输入管理系统机制解析

     android的输入管理系统主要完成按键.触摸板.鼠标等输入设备的事件输入,功能包括,输入设备的事件输入及向焦点窗口和焦点视图的事件派发,事件的插入,事件的过滤,事件的拦截等功能. 整个输入系统 ...

  10. LeetCode之“字符串”:Restore IP Addresses

    题目链接 题目要求: Given a string containing only digits, restore it by returning all possible valid IP addr ...