Dubbo架构整体设计详解

一、Dubbo调用关系说明

1.1 组成部分

在这里主要由四部分组成:

● Provider: 暴露服务的服务提供方
Protocol：负责提供者和消费者之间的协议交互数据
Service：真实的业务服务信息，可以理解成接口和实现
Container：Dubbo的运行环境
● Consumer：调用远程服务的服务消费方
Protocol：负责提供者和消费者之间的协议交互数据
Cluster：感知提供者端的列表信息
Proxy：可以理解成提供者的服务调用代理，由它接管Consumer中的接口调用逻辑
● Register：注册中心，用于作为服务发现和路由配置等工作，提供者和消费者都会在这里进行注册
● Monitor：用于提供者和消费者中的数据统计，比如调用频次、成功失败次数等信息

1.2 启动和执行流程说明

● 提供者端启动，容器负责把Service信息加载，并通过Protocol注册到注册中心；
● 消费者端启动，通过监听提供者列表来感知提供者信息，并在提供者发生改变时，通过 注册中心及时通知消费端
● 消费方通过Proxy模块发起请求；
● 消费者端利用Cluster模块选择真实的要调用的提供者；
● 消费者利用Consumer中的Protocol将信息发送给提供者；
● 提供者通过Protocol模块来处理消费者信息；
● 最后由提供者的Service来进行处理

二、整体调用链路

说明：淡绿色代表服务生产者的范围，淡蓝色代表服务消费者的范围，红色箭头代表调用的方向：业务逻辑层 -> RPC层（远程过程调用）-> Remoting（远程数据传输）

整体调用流程如下：

● 消费者通过Interface进行方法调用，统一交由消费者端的Proxy，通过ProxyFactory来进行代理对象的创建，这里使用jdk的javassist技术
● 交给Filter模块做统一的过滤请求
● 接下来就是最主要的Invoker调用逻辑了
○ 通过Directory去配置中读取信息，最终通过list方法获取所有的Invoker
○ 通过Cluster模块，根据选择的具体路由规则来选取Invoker列表
○ 通过LoadBalance模块，根据负载均衡策略选择一个具体的Invoker来处理请求
○ 如果执行中出现错误，并且Consumer阶段配置了重试机制，则会重新尝试执行
● 继续经过Filter进行执行功能的前后封装，Invoker选择具体的执行协议
● 客户端进行编码和序列化，然后发送数据
● 达到Provider中的Server层进行反编码和发序列化接收到的数据
● 使用Exporter选择执行器
● 交由Filter进行一个提供者端的过滤，到达Invoker执行器
● 通过Invoker调用接口的具体实现，然后返回结果

三、Dubbo整体设计

图例说明：

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

Dubbo源码整体设计与调用链路十分相似。只不过这里可以看到接口的一些具体实现以及左侧也有更为详细的层次划分，我们在后面的源码解析时也会着重介绍其中比较重要的模块实现。

接下来分层进行介绍

1、Business业务逻辑层
● Service业务层：包括业务代码比如接口和实现类
2、RPC层：远程过程调用层
● config配置层，对外提供配置，以ServiceConfig、ReferenceConfig为核心，可以直接初始化配置类，也可解析配置文件
● Proxy服务代理层，无论是生产者还是消费者，框架都会产生一个代理类，整个过程对上层透明，业务层对远程调用无感
● Register注册中心层，封装服务地址的注册与发现，以服务的URL位中心
● Cluster路由层（集群容错层），提供了多个提供者的路由和负载均衡，并且它桥接注册中心以Invoker为中心
● Monitor监控层，RPC调用相关的信息，如调用次数、失败情况、调用时间等统计信息都会在这一层完成统计
● Protocol远程调用层，封装RPC调用，无论是服务的暴露还是服务的引用，都是在Protocol中作为主功能入口负责Invoker的整个生命周期，Dubbo中的所有模型都向Invoker靠拢
3、Rmoting层：远程数据传输层
● Exchange信息交换层，封装请求和响应的模式，把请求由同步转为异步
● Transport网络传输层，统一网络传输的接口，比如Netty和mina统一为一个网络传输接口
● Serialize数据序列化层，负责管理整个框架中的数据传输的序列化和反序列化

到此这篇关于Dubbo架构整体设计详解的文章就介绍到这了,更多相关Dubbo架构设计内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论