您的位置: 首页  >  文章  >  Dubbo框架设计——摘自Dubbo官方文档

Dubbo框架设计——摘自Dubbo官方文档

分类: 文章 • 2023-03-23 23:56:57

框架设计

概念

       Dubbo是一种分布式框架，致力于提供性能和透明的RPC远程服务调用方案，以及SOA服务治理方案。

整体设计：

 

Dubbo拓扑结构

Dubbo框架设计——摘自Dubbo官方文档

名词解释

1、Registry：注册中心，一般是使用Zookeeper作为注册中心。用于服务的注册与发现。

2、Provider：暴露服务的服务提供方，会将服务注册到Registry注册中心。

3、Consumer：消费者，调用远程服务的一方，Registry会向消费者发送提醒，提醒已经注册的服务，Consumer负责询问，一旦有服务可用，会向Provider通过RPC的方式调用（invoke）Provider的服务。

4、Monitor，监控中心，统计服务的调用次数和调用时间。

5、Scheduler调度器，基于访问压力自增减服务提供者

6、Container服务运行容器

 

调用关系说明：

  1. 服务容器负责启动、加载、运行服务提供者；
  2. 服务提供者在启动时，向注册中心注册自己的服务；
  3. 服务消费者在启动时，向注册中心订阅自己所需要的服务；
  4. 注册中心返回服务提供者地址列表给服务消费者，如有变更，注册中心将基于长连接推送变更数据给消费者。
  5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
  6. 服务消费者和服务提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

 

 

特性一览：

  1. 面向接口代理的高性能RPC调用

提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用的底层细节。

2、服务自动注册与发现

提供多种服务注册中心机制，服务上下线实时感知。

3、运行期流量调度

内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。

4、智能负载均衡

内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。

5、高度可扩展能力

遵循微内核加插件设计的原则，所有核心能力如Protocol、Transport、Serialization被设计扩展点，平等对待内置实现和第三方实现。

6、可视化服务治理与运维

提供丰富治理与运维工具：随时查询服务元数据、服务健康状态以及调用统计、实施下发路由策略、调整配置参数。

 

整体设计：

 

Dubbo框架设计——摘自Dubbo官方文档

图例说明：

  1. 图中的蓝色背景为服务消费者方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
  2. 图中从上至下分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中Service层和Config层为API。其他各层为SPI（串行外设接口）。
  3. 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于联络各层的实现类。
  4. 图中蓝色虚线为初始化过程，即启动时组装链，红色实现为方法调用过程，即运行时调用链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

 

各层说明

  1. config配置层：对外设置接口，以ServiceConfig、ReferenceConfig为中心，可以直接初始化配置类，也可以通过spring解析服务配置生成配置类。
  2. proxy服务代理层：服务接口透明代理，生成服务的客户端stub和服务端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
  3. cluster路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router、LoadBalance
  4. monitor监控层：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor、MonitorService。
  5. protocol远程调用层：封装RPC调用，以Invocation、Result为中心，扩展接口为Protocol、Invoker、Exporter
  6. exchange信息交换层：封装请求响应模式，同步转异步，以Request、Response为中心，扩展接口为Exchange、ExchangeChannel、ExchangeClient、ExchangeServer
  7. transport网络传输层：抽象Mina和Netty为统一接口，以Message为中心，扩展为Channel 、Transport、Client、Server、Codec
  8. serialize数据序列化层：可复用一些工具，扩展接口为Serialization，ObjectInput、ObjectOutput、ThreadPool

 

关系说明

  1. 在RPC中，Protocol是核心层，也就是只要有Protocol+Invoker+Export就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。
  2. 图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些分类分属于客户端与服务器端，不用Client和Server的原因是Dubbo在很多场景下都使用Provider、Consumer、Registry、Monitor划分逻辑拓扑节点，保持概念统一。
  3. 而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其他人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其他曾都不会造成影响，因为只有一个提供者时，是不需要Cluster的。
  4. Proxy层封装了所有接口的透明代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将所有Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以RUN的，只是不那么透明，不那么看起来像调用本地服务一样调用远程服务。
  5. 而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划分为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mina、Netty、Grizzly的抽象，它可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
  6. Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。

 

模块分包

Dubbo框架设计——摘自Dubbo官方文档

模块说明：

  1. dubbo-common公共逻辑模块：包括Util类和通用模型
  2. dubbo-remoting远程通讯模块：相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包；
  3. dubbo-rpc远程调用模块：抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群管理。
  4. dubbo-cluster集群模块：将多个服务提供方伪装为一个提供方，包括负载均衡，容错。路由等。集群的地址可以是静态配置的，也可由注册中心下发；
  5. dubbo-registry注册中心模块：基于注册中心下发地址的集群方式，以及对各种注册中心的抽象；
  6. dubbo-monitor监控模块：统计服务调用次数，调用时间的，调用链跟踪的服务。
  7. dubbo-config配置模块：是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
  8. dubbo-container容器模块：是一个Standlone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/Jboss等Web容器的特性，没必要用Web容器去加载服务。

 

整体上按照分层结构进行分包，与分层的不同点在于：

  1. container为服务容器，用于部署运行服务，没有在层中划出；
  2. protocol层和proxy层都是放在rpc模块中，这两层是rpc的核心，在不需要集群也就是只有一个提供者时，可以只使用这两层完成rpc调用。
  3. transport层和exchange层 都放在Remoting模块中，为rpc调用的通讯基础；
  4. serialize层放在common模块中，以便更大程度复用。  

 

依赖关系

Dubbo框架设计——摘自Dubbo官方文档

图例说明：

  1. 图中小方块Protocol、Cluster、Proxy、Service、Container、Registry、Monitor代表层或模块，蓝色的表示与业务有交互，绿色的表示只对Dubbo内部交互。
  2. 图中背景方块Consumer、Provider、Registry、Monitor代表部署逻辑拓扑节点；
  3. 图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实现为运行时同步调用。
  4. 图中只包含RPC的层，不包含Remoting 的层，Remoting整体都隐含在Protocol中。

 

调用链

展开总设计图的红色调用链

 

Dubbo框架设计——摘自Dubbo官方文档

 

暴露服务时序

展开总设计图左边服务提供方暴露服务的蓝色初始化链，时序图如下：

Dubbo框架设计——摘自Dubbo官方文档

引用服务时序

展开总设计图右边服务消费方引用服务的蓝色初始化链，时序图如下：

Dubbo框架设计——摘自Dubbo官方文档

领域模型

在Dubbo的核心领域模型中：

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

 

基本设计原则

  1. 采用Microkernel+Plugin模式，Microkernel只负责组装Plugin，Dubbo自身的功能也是通过扩展点实现的，也就是Dubbo的所有功能点都可以被用户自定义扩展所替换。
  2. 采用URL作为配置信息的统一格式，所有扩展都可以通过传递URL携带配置信息。

官方文档：

https://dubbo.apache.org/zh-cn/docs/user/quick-start.html

相关推荐