Dubbo RPC 原理探究

Published: Creative Commons Licence

概述

最近稍微研究了一点Dubbo的RPC原理，在这里记录一下笔记。

主要是阅读源码：https://github.com/apache/incubator-dubbo，参考了Dubbo的官网开发者手册（写的非常好，就是内容略精简，初学者需要仔细消化）：http://dubbo.apache.org/zh-cn/docs/dev/design.html，还有一个非常生动易懂的教程视频：https://www.bilibili.com/video/av30612478。

本文首先介绍了Dubbo RPC中的核心概念与契约，虽然画了幅示意图，但我估计不熟悉Dubbo的人第一眼看到后还是会一脸懵逼的。不过把RPC的核心流程源码读过几遍后，再回过头来看这段契约，会有更加深入的理解。

由于大部分情境下Dubbo是通过Spring配置使用的，因此接下来首先简单介绍了下服务解析的逻辑，然后从源码的角度分析了Dubbo的RPC流程，包括：服务引用、服务暴露、服务调用三个部分，每一部分都配了核心流程图和代码路径。

核心概念与契约

在Dubbo中有这么两个概念是最核心的：

  • Invoker：是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用。
  • Protocol：是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。

支撑起Dubbo RPC的就是如下这一段话：

当用户调用 refer() 所返回的 Invoker 对象的 invoke() 方法时，Protocol 需相应执行同 URL 远端 export() 传入的 Invoker 对象的 invoke() 方法。

画了一幅图来辅助理解这句话：
Dubbo核心契约

服务解析

所谓服务解析，就是在 Dubbo 初始化时进行，把 的标签解析并注册为 Spring Bean 的过程。

基于 Spring 的 Schema 扩展机制，这里不再展开，可以参考这篇文章：https://www.jianshu.com/p/8639e5e9fba6。

基于 dubbo.jar 内的 META-INF/spring.handlers 配置：

http\://dubbo.apache.org/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandler
http\://code.alibabatech.com/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandler

Spring 在遇到 dubbo 名称空间时，会回调 DubboNamespaceHandler：

/**
* DubboNamespaceHandler
*
* @export
*/

public class DubboNamespaceHandler extends NamespaceHandlerSupport {

static {
       Version.checkDuplicate(DubboNamespaceHandler.class);
}

@Override
public void init() {
      registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfig.class, true));
      registerBeanDefinitionParser("module", new DubboBeanDefinitionParser(ModuleConfig.class, true));
      registerBeanDefinitionParser("registry", new DubboBeanDefinitionParser(RegistryConfig.class, true));
      registerBeanDefinitionParser("monitor", new DubboBeanDefinitionParser(MonitorConfig.class, true));
      registerBeanDefinitionParser("provider", new DubboBeanDefinitionParser(ProviderConfig.class, true));
      registerBeanDefinitionParser("consumer", new DubboBeanDefinitionParser(ConsumerConfig.class, true));
      registerBeanDefinitionParser("protocol", new DubboBeanDefinitionParser(ProtocolConfig.class, true));
      registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBean.class, true));
      registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBean.class, false));
      registerBeanDefinitionParser("annotation", new AnnotationBeanDefinitionParser());
}

}

所有 dubbo namespace下的的标签，都统一用 DubboBeanDefinitionParser 进行解析，基于一对一属性映射，将 XML 标签解析为对应的 Bean 对象，再注册到容器里。

和RPC核心流程密切相关的标签：

  • <dubbo:reference> 解析为 ReferenceBean
  • <dubbo:service> 解析为 ServiceBean

服务引用

所谓服务引用，就是服务的消费端从Protocol中拿到正确的Invoker的过程，对应核心契约图的左半部分，按照契约的说法，接下来消费端对这个Invoker发起调用，就会达到调用远端同URL暴露出来的Invoker的效果了。

服务引用核心时序图

关键代码路径：

  • ReferenceBean#getObject：ReferenceBean实现了Spring的FactoryBean接口，因此IOC容器想要获取ReferenceBean的实例时会去调用getObject方法来获取。
  • ReferenceConfig#get：第一次调用时会触发初始化逻辑，之后直接返回创建好的实例引用。
  • ReferenceConfig#createProxy

这里的两行代码分别解析：

  1. Dubbo基于扩展点的自适应机制（http://dubbo.apache.org/zh-cn/docs/dev/SPI.html），会自动识别URL中的协议类型，并调用合适的Protocol实现类，在这里我们默认用的是Dubbo协议，因此会调用DubboProtocol进行服务引用：
    DubboProtocol#refer

  2. ProxyFactory同样是扩展点，这里默认使用了JavassistProxyFactory的实现：
    JavassistProxyFactory#getProxy
    可以看到这里创建的代理，把对接口方法的调用交给了 InvokerInvocationHandler这个类去处理。这里先不展开，可以留待分析服务调用时再看。

服务暴露

所谓服务暴露，就是服务提供方把代理了真正实现类的Invoker暴露给Protocol的过程，对应核心契约的右半部分。

服务暴露核心时序图

关键代码路径：

  • ServiceBean#onApplicationEvent
  • ServiceConfig#export
  • ……
  • ServiceConfig#doExportUrlsFor1Protocol

展开看高亮出的两段逻辑：

  1. 同服务引用一样，这里的ProxyFactory依旧是扩展点，具体实现如下，可以看到这里创建一个AbstractProxyInvoker，当该Invoker的doInvoke方法被调用时，就会调用真正实现类 ref 里的方法：
    JavassistProxyFactory#getInvoker

2.同样，Protocol也是扩展点，默认采用Dubbo实现：
DubboProtocol#export

export方法干了两件事：

  • 将上一步拿到的Invoker export出去，然后创建 DubboExporter实例并存储在 exporterMap 里，Exporter并没有什么玄机，就是一个存储了Invoker实例及其他各种信息的容器，用于之后获取Invoker用。
  • 打开服务端口，并注册ExchangeHandler，用于后续响应客户端网络请求，响应逻辑这里先不展开。

服务调用

服务调用分两部分来分析：客户端发起调用、服务端响应调用。

客户端发起调用

服务调用时序图 - Consumer端

按照之前服务引用代码的分析，客户端对拿到的Bean发起调用时，会被 JavassistProxyFactory#getProxy 创建的代理接管，把请求交给InvokerInvocationHandler处理：

InvokerInvocationHandler#invoke

按照之前服务引用代码的分析，这里调用的Invoker是调用refprotocol#refer拿到的，是一个DubboInvoker，因此会进入下面的逻辑，其实就是发起一次网络请求，拿到返回值： DubboInvoker#doInvoke

这样，就通过代理机制，就把客户端发起的本地请求转换为了对服务端的网络请求。

服务端响应调用

上文里服务提供端暴露服务时，在openServer逻辑里，注册了一个ExchangeHandler用于响应客户端的网络请求 服务调用时序图 - Provider端

ExchangeHandler#reply

  • getInvoker方法是通过exporterMap获取之前暴露的 Invoker 实例，然后调用其invoke方法。

  • 由前文服务暴露部分（JavassistProxyFactory#getInvoker ）里的逻辑可知：当DubboInvoker的doInvoke方法被调用时，就会调用真正实现类 ref 里的方法，这样就触达到了服务的提供者。

结语

以上就是Dubbo RPC的核心流程逻辑了，这次研究时有很多逻辑被我当做了黑盒来处理，比如扩展点加载、负载均衡、网络请求、线程模型等……实际上一次RPC过程远比上述描述的复杂，按照官网的说明，RPC过程的流程如下所示：

什么时候真正吃透了这张图，才敢说自己懂了Dubbo RPC吧。