Dubbo

最新推荐文章于 2024-08-04 17:04:24 发布

原创最新推荐文章于 2024-08-04 17:04:24 发布 · 195 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#dubbo #rpc #java

java 同时被 3 个专栏收录

10 篇文章

订阅专栏

微服务

8 篇文章

订阅专栏

microservice

7 篇文章

订阅专栏

本文深入剖析Dubbo架构，包括SPI机制、服务注册与发现流程、负载均衡策略等内容。介绍了Dubbo如何利用ExtensionLoader实现插件化及动态加载，探讨了核心组件如ServiceConfig、RegistryProtocol的作用，以及注册中心的选择与实现。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这个是Dubbo的源码目录，dubbo源码非常清晰，每个子项目对应一个模块，在子项目下会有不同模块来对不同的技术作支撑。dubbo通过ExtensionLoader加载SPI，实现了对技术选择插件化、动态加载、懒加载、单利加载、动态注入，AOP，ExtensionLoader创建时会创建ExtensionFactory（同样用ExtensionLoader实例化）类，用于注入Extension（injectExtension），该类有两个实现类SpiExtensionFactory（默认）和SpringExtensionFactory（从spring加载），默认动态适配的是AdaptiveExtensionFactory，该类保存其他的ExtensionFactory实现类，调用getExtension时会遍历从实现类获取Extension实例。

下面这个是Dubbo官方提供的架构图。

1、Dubbo registry

dubbo registry支持四种注册中心：default（simple）、multicast（广播）、redis、zookeeper。官方建议使用zookeeper注册中心。

Dubbo的服务注册过程（核心类：ServiceConfig、RegistryProtocol、Registry）：

一个服务配置解析后最终会对应一个ServiceConfig/ServiceBean对象，解析后dubbo会调用ServiceConfig的export方法进行服务注册，ServiceConfig中加载了一个扩展Protocol RegistryProtocol，该Protocol在org.apache.dubbo.rpc.Protocol中定义。ServiceConfig最终会调用protocol（RegistryProtocol）的export方法进行服务注册，在这里通过相应类型的registryFactory进行注册（这里的registryFactory在通过ExtensionLoader进行set注入）。

Dubbo的服务发现过程 (核心类：ReferenceConfig、RegistryProtocol、RegistryDirectory等）：

首先通过dubbo consumer的配置文件或其他方法生成ReferenceConfig类，然后调用get获取到相应的代理类，这里调用的核心是init函数，init会创建ref（proxy）对象，ref也是最终返回的rpc代理，返回代理由ExtensionLoader的proxyFactory的getProxy方法提供，默认的ProxyFactory是JavassistProxyFactory。这里以JavassistProxyFactory为例他会调用Proxy类的getProxy方法生成代理对象，代理的缓存也在此处实现，getProxy代理主要使用javassist生成两个动态类，org.apache.dubbo.common.bytecode.proxy$id类和org.apache.dubbo.common.bytecode.Proxy$id类，这里设为proxy0和Proxy0，两个类都实现DC动态标记类，都包含一个无参数构造函数和有一个InvocationHandler参数的构造函数，此外Proxy0类继承自Proxy类，实现其方法newInstance（创建的就是proxy0类，即DemoService类），proxy0实现我们的实际代理接口这里是DemoService，id为自增Long型，proxy0为代理的实现类，实现类中的api使用handler（InvocationHandler）实现远程RPC，从这里可以看出，Dubbo Rpc（应该是支持的各种RPC技术）的核心是InvocationHandler的调用。

接下来看看InvocationHandler的来龙去脉

InvocationHandler是在JavassistProxyFactory中直接显示new出来的，他直接继承自InvocationHandler，采用了标准的java动态代理处理类。这里看同步的rpc，dubbo支持CompletableFuture的异步回调。在InvocationHandler中最终调用的是构造时传入的Invoker对象的invoke函数，值得注意的是，Invoker类是dubbo rpc模块下的类，这意味着在这里基本上都是交由RPC去处理请求了。因此这里再次回到ReferenceConfig类，来看看Invoker对象的创建，其实Invoker是在获取代理最开始的时候创建的，在createProxy中我们可以看到，这里调用的是默认Protocol的refer方法，可以看到默认的Protocol是RegistryProtocol，然后通过默认的Cluster（MockClusterWrapper）的join new 一个invoker（MockClusterInvoker），当然在这过程还有很多处理，暂时没太搞清楚。调用InvocationHandler的invoke时，实际上invoker的实现类是MockClusterInvoker的invoke，在MockClusterInvoker.invoke时调用FailoverClusterInvoker等这些类型的实现类的invoke，这里获取RegistryDirectory的所有Invokers然后根据loadBalance的规则选择一个invoker执行（所有Invoker的invoke方法传递的是一个Invocation对象，这类似与一个请求的封装，在InvokerInvocationHandler中创建的是RpcInvocation的实现）。

Dubbo注册中心

Registry类是dubbo注册中心的抽象，由其工厂类创建，在这里要首先介绍一个Dubbo的设计思想，我也不知道叫啥。。

首先这个设计思想起始于RegistryFactory注册中心的工厂类，这个类是一个SPI，默认返回的是bubbo注册中心（default），注册中心工厂类有一个Adaptive注解的方法，并且没有Adaptive注解的工厂类，因此ExtensionLoader会帮我们动态编译一个RegistryFactory$Adaptive类，这个类类似一个包装类，他实际上根据url protocol来在ExtensionLoader中查找ConcreteRegistryFactory，由他创建ConcreteRegistry。我们可以看看生成的默认RegistryFactory$Adaptive类的源码，思路很清晰就不在解释了：

public class RegistryFactory$Adaptive implements RegistryFactory {

private static final Logger logger = LoggerFactory.getLogger(ExtensionLoader.class);

private AtomicInteger count = new AtomicInteger(0);

public Registry getRegistry(URL var1) {

if (var1 == null) {

throw new IllegalArgumentException("url == null");

} else {

String var3 = var1.getProtocol() == null ? "dubbo" : var1.getProtocol();

if (var3 == null) {

throw new IllegalStateException("Fail to get extension(org.apache.dubbo.registry.RegistryFactory) name from url(" + var1.toString() + ") use keys([protocol])");

} else {

RegistryFactory var4 = null;

try {

var4 = (RegistryFactory)ExtensionLoader.getExtensionLoader(RegistryFactory.class).getExtension(var3);

} catch (Exception var6) {

if (this.count.incrementAndGet() == 1) {

logger.warn("Failed to find extension named " + var3 + " for type org.apache.dubbo.registry.RegistryFactory, will use default extension dubbo instead.", var6);

}

var4 = (RegistryFactory)ExtensionLoader.getExtensionLoader(RegistryFactory.class).getExtension("dubbo");

}

return var4.getRegistry(var1);

}

}

}

public RegistryFactory$Adaptive() {

}

}

通过暴露的服务（also consumer）url的protocol可以找到对应的Registry工厂类，并从缓存中获取或者创建注册中心。有了注册中心后，我们就看看注册中心的大体框架。

这里RegistryService声明了Registry的职责，有五个方法register、unregister、subscribe、unsubscribe、lookup。这里重要的一个（实现）类是AbstractRegistry，这里实现了注册中心的一些通用逻辑。首先看其实现的RegistryService里面的方法，register和unregister就是普通的在一个Set中添加和删除对应的服务的url，subscribe和unsubscribe是找到对应url的NotifyListener Set（Map<URL,Set<NotifyListener>>）,进行添加或删除该listener。lookup查询出所有匹配的已经通知的服务。

未完

Dubbo LoadBalance

Random、RoundRobin、LeastActive、ConsistentHash