Dubbo架构学习整理 - 分析设计

TOP

Dubbo架构学习整理(一)

2019-09-17 18:09:18 【大中小】浏览:62次

一. Dubbo诞生背景

随着互联网的发展和网站规模的扩大，系统架构也从单点的垂直结构往分布式服务架构演进，如下图所示：

当服务比较少时，可以通过 RMI 或 Hession 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址来调用，通过F5等硬件负载均衡

当服务越来越多时，服务配置URL变的困难，F5硬件负载均衡的单点压力越来越大。此时需要服务注册中心，动态的注册和发现服务，使服务的位置透明。服务调用实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖

当服务间关系越来越复杂时，此时需要自动画出服务间的依赖关系图，来帮助架构师理清服务关系

当服务调用量越来越大时，服务需要多少台机器支撑，服务容量的问题就暴露出来了，此时需要统计服务每天的调用量、响应时间等性能指标作为容量规划的参考。其次，还可以动态调整权重，将某台机器权重一直加大，直到响应时间到阀值，按照此时的访问量反推服务的总容量

以上是Dubbo的基本需求，如下图所示：

Dubbo的整体架构设计如图所示：

Dubbo框架一共分10层，各层单向依赖。最上面的 Service 和 Config 为API，其他均为 SPI。左边淡蓝色的为 consumer 使用的接口，右边淡绿色的为 provider 使用的接口，中间的为双方都用到的接口。

黑色箭头代表层之间的依赖关系；蓝色虚线为初始化过程，即启动时组装链；红色实线为方法调用过程；紫线为继承关系。线上的文字为调用的方法。

1、接口服务层（Service）：该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现

2、配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心

3、服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和服务端的 Skeleton，以 ServiceProxy 为中心，扩展接口为 ProxyFactory

4、服务注册层（Registry）：封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry、RegistryService

5、路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心，以Invoker 为中心，扩展接口为 Cluster、Directory、Router和LoadBlancce

6、监控层（Monitor）：RPC调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory、Monitor和MonitorService

7、远程调用层（Protocal）：封装 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocal、Invoker和Exporter

8、信息交换层（Exchange）：封装请求响应模式，同步转异步。以 Request 和 Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer

9、网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为Channel、Transporter、Client、Server和Codec

10、数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool

各层关系说明：

Portocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点
Cluster 是外围概念，目的是将多个 Invoker 伪装为一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可。只有一个 provider 时，是不需要 Cluster 的
Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，看起来像调本地服务一样调远程服务
Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层：Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象；而 Exchange 层是在传输层之上封装了 Request-Response 语义

Dubbo核心领域模型：

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

Dubbo主要包括以下几个节点：

Consumer, Provider, Registry, Monitor代表逻辑部署节点。图中只包含 RPC 层，不包含 Remoting层，Remoting整体隐藏在 Protocol 中。

蓝色方框代表业务有交互，绿色方框代表只对Dubbo内部交互。蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用

0、服务在容器中启动，加载，运行Provider

1、Provider在启动时，向Registry注册自己提供的服务

2、Consumer在启动时，想Registry订阅自己所需的服务

3、Registry给Consumer返回Provider的地址列表，如果Provider地址有变更（上线/下线机器），Registry将基于长连接推动变更数据给Consumer

4、Consumer从Provider地址列表中，基于软负载均衡算法，选一台进行调用，如果失败，重试另一台调用

5、Consumer和Provider，在内存中累计调用次数和时间，定时每分钟一次将统计数据发送到Monitor

将上面的服务调用流程展开，如下图所示：

蓝色虚线为初始化过程，即启动时组装链；红色实线为方法调用过程，即运行时调用链；紫色实线为继承