前言

dubbo整体的结构分层次还是很清晰的，这里给出下整体的设计思路。参考一下文档得来。

整体设计

image.png

注：具体说明见参考

各层说明

  • service层：这里暴漏出来的dubbo接口，方便我们使用的。这个interface 就是我们开发时使用的jar，需要provider和consumer都引用。
  • config层：这里的ServiceConfig 和 ReferenceConfig 就是就是dubbo暴漏引用的接口信息。也可以手动初始化，完成手动的dubbo注册。
  • proxy层：服务接口的透明代理，生成出客户端的Stub和服务端的Skeleton。

注：proxy层封装了所有的透明化代理，这样我们就可以直接用我们提供的接口 interface 来进行远程调用，不然还需要手动拿到ServiceConfig 等信息来调用，它可以将我们调用的invoker接口转化为interface来调用。

  • register层：服务地址的注册和发现接口。
  • cluster层：将多个提供者进行封装起来，提供路由和负载均衡。

注：custer只是将多个invoker伪装成一个invoker进行调用，这样可以提供路由负载等等信息。平时我们直接关注Protocol层的invoker即可。

  • monitor层：RPC的调用次数和时间的监控。
  • protocol层：封装了RPC的调用，以 Invocation, Result 为中心，扩展数据。
  • exchange层：封装请求响应模式，同步请求转化为异步请求。

注：将我们发送的数据转化成Request-Response 语义信息，达到消息的一应一答模式。

  • transport层：抽象了mina和netty为统一接口，以 Message 为中心，扩展数据。

注：此层就是对数据进行发送传输即可，传输出去消息。

  • serialize层：序列化层，提供了对象的序列化操作。

暴露服务时序

暴露服务时，我们都是拿到 serviceConfig.export() 进行服务的暴露，代码如下：

  1.   ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
  2.   service.setInterface(DemoService.class);
  3.   service.setRef(new DemoServiceImpl());
  4.   service.setApplication(new ApplicationConfig("dubbo-demo-api-provider"));
  5.   service.setRegistry(new RegistryConfig("zookeeper://127.0.0.1:2181"));
  6.   service.export();

整体的时序图如下：
image.png

引用服务时序

引用服务时，我们都是拿到 reference.get() 进行引用的，代码如下：

  1. ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
  2. reference.setApplication(new ApplicationConfig("dubbo-demo-api-consumer"));
  3. reference.setRegistry(new RegistryConfig("zookeeper://127.0.0.1:2181"));
  4. reference.setInterface(DemoService.class);
  5. DemoService service = reference.get();

整体时序图如下：
image.png

领域模型

在 Dubbo 的核心领域模型中：

  • Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
  • Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
  • Invocation 是会话域，它持有调用过程中的变量，比如方法名，参数等。

参考