Java 杂谈Java

解密Dubbo ——深入解析Dubbo RPC 原理

2019-06-12  本文已影响2人  丨程序之道丨

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

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

核心概念与契约

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

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

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

画了一幅图来辅助理解这句话：

服务解析

所谓服务解析，就是在 Dubbo 初始化时进行，把 <xx style="box-sizing: border-box; outline-style: none;">的标签解析并注册为 Spring Bean 的过程。</xx>

基于 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核心流程密切相关的标签：

服务引用

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

关键代码路径：

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

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

  2. ProxyFactory同样是扩展点，这里默认使用了JavassistProxyFactory的实现：

    可以看到这里创建的代理，把对接口方法的调用交给了 InvokerInvocationHandler这个类去处理。这里先不展开，可以留待分析服务调用时再看。

服务暴露

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

关键代码路径：

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

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

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

export方法干了两件事：

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

客户端发起调用

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

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

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

服务端响应调用

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

结语

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

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

上一篇下一篇

猜你喜欢

热点阅读