《一》Dubbo之总体架构剖析

Posted 码农霓风

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《一》Dubbo之总体架构剖析相关的知识,希望对你有一定的参考价值。



一、架构剖析

Dubbo 总体采用微内核+插件体系,使得设计优雅,扩展性强 ,下面是各个层面的设计。

  1. Privoder服务提供者启动时,会向注册中心(默认zk)写入自己的元数据信息
  2. consumer服务消费者启动时,也会向注册中心(默认zk)写入自己的元数据信息,同时并订阅服务提供者、路由和配置元信息数据。pull 拉取模式获取全量的数据,并向zk注册一个watcher,同时zk客户端与zk注册中心保持TCP长连接方式。
  3. 消费者拉取到了注册中心的注册信息后会缓存起来(内存有一份。磁盘也会持久化一份),后面调用时候不用再经过注册中心(空间换时间)。
  4. Register注册中心当有服务新增或者离开时,会异步通知服务消费者。zk采用“事件通知”+“客户端拉取”的方式实现
  5. zk注册中心客户端:Apache Curator、zkClient
  6. 整个注册中心的逻辑部分使用了模板模式,AbstractRegistry实现了Registry接口中的注册、订阅、查询、通知等方法。FailbackRegistry又继承了AbstractRegistry添加了重试机制。

二、分层结构

  1. config 即配置层:对外配置接口,主要有 ServiceConfig, ReferenceConfig ,dubbo启动时会直接初始化相关配置类,当然也可以通过 spring 解析配置从而生成相应的配置类。

  2. proxy 即代理层:服务接口代理层,例如ServiceProxy 扩展接口为 ProxyFactory。

  3. cluster 即路由层:会封装多个provider的路由负载均衡,并桥接注册中心,例如Invoker ,扩展接口为 Cluster, Directory, Router, LoadBalance等。

  4. monitor 即监控层:会统计和RPC 调用次数和调用时间监控等。

  5. protocol 即远程调用层封装 RPC 的调用,以 Invocation为中心。

  6. exchange 即信息交换层:封装请求响应模式,同步转异步。

  7. transport 即网络传输层主要抽象 mina 和 netty 为统一接口,以 Message 为中心,扩展接口为 Channel, Transporter, Client, Server, Codec

  8. serialize  即序列化层主要扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool


三、关系说明
  1.  Protocol 是核心层,通过 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用。

  2. 其中 Consumer 和 Provider 是抽象概念,不采用C/S架构的原因是 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之总体架构剖析

模块说明:

  1. dubbo-common 公共逻辑模块:包括 工具类和通用模型

  2. dubbo-monitor 监控模块:统计服务调用次数,调用时间的,调用链跟踪的服务。

  3. dubbo-config 配置模块:是 Dubbo 对外的 API,用户通过 Config 使用Dubbo,隐藏 Dubbo 所有细节。

  4. dubbo-container 为服务容器,用于部署运行服务。spring、logback

  5. dubbo-rpc 为rpc通讯的核心里面包括很多扩展点实现包含dubbo、hession、thrift、webservice、xml等实现

  6. dubbo-remoting 主要是 rpc 调用的通讯基础包含netty、http、相关实现

  7. dubbo-serialize 序列化相关包括avro、fst、hessian2、protostuff等

六、Dubbo主要的调用链路

《一》Dubbo之总体架构剖析

七、服务export时序图


八、服务refer时序图


九、领域模型

  1. 在 Dubbo 的核心DDD中:

  2. Protocol 是服务域,它是 Invoker 暴露和引用的主功能入口,它负责 Invoker 的生命周期管理。

  3. Invoker 是实体域,它是 Dubbo 的核心模型,其它模型都向它靠扰,或转换成它,它代表一个可执行体,可向它发起 invoke 调用,它有可能是一个本地的实现,也可能是一个远程的实现,也可能一个集群实现。

  4. Invocation 是会话域,它持有调用过程中的变量,比如方法名,参数等。

十、基本设计原则

  1. 采用 Microkernel + Plugin 模式,Microkernel 只负责组装 Plugin,Dubbo 自身的功能也是通过扩展点实现的,也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。

  2. 采用 URL 作为配置信息的统一格式,所有扩展点都通过传递 URL 携带配置信息。

以上是关于《一》Dubbo之总体架构剖析的主要内容,如果未能解决你的问题,请参考以下文章

Dubbo的总体架构

深度剖析Dubbo源码

阿里资深JAVA架构带你深度剖析dubbo和zookeeper关系

Dubbo架构设计与源码解析 架构设计

来撸一撸Dubbo之SPI机制源码,SPI到底解决了什么问题?

推荐Dubbo架构与底层实现