服务消费者通过代理对象 Proxy 发起远程调用,
接着通过网络客户端 Client 将编码后的请求发送给服务提供方的网络层上,也就是 Server。
Server 在收到请求后,首先要做的事情是对数据包进行解码。
然后将解码后的请求发送至分发器 Dispatcher,再由分发器将请求派发到指定的线程池上,最后由线程池调用具体的服务。
这就是一个远程调用请求的发送与接收过程
淡绿色代表了 服务生产者的范围 淡蓝色 代表了服务消费者的范围 红色箭头代表了调用的方
向
业务逻辑层(Interface )
RPC层(远程过程调用)
Remoting (远程数据传输)
看官网的
http://dubbo.apache.org/zh-cn/docs/dev/design.html
左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于
中轴线上的为双方都用到的接口
Business 业务逻辑层
- service 业务层 包括我们的业务代码 比如 接口 实现类 直接面向开发者
RPC层 远程过程调用层 - config 配置层 对外提供配置 以ServiceConfig ReferenceConfig 为核心 可以直接初始化配置
类 也可以解析配置文件生成 - proxy 服务代理层 无论是生产者 还是消费者 框架都会产生一个代理类 整个过程对上层透明 就是
业务层对远程调用无感 - registry 注册中心层 封装服务地址的注册与发现 以服务的URL为中心
- cluster 路由层 (集群容错层) 提供了多个提供者的路由和负载均衡 并且它桥接注册中心 以
Invoker为核心 - monitor 监控层 RPC调用相关的信息 如 调用次数 成功失败的情况 调用时间等 在这一层完成
- protocol 远程调用层 封装RPC调用 无论是服务的暴露 还是 服务的引用 都是在Protocol中作为主
功能入口 负责Invoker的整个生命周期 Dubbo中所有的模型都向Invoker靠拢
Remoting层 远程数据传输层 - exchange 信息交换层 封装请求和响应的模式 如把请求由同步 转换成异步
- transport 网络传输层 统一网络传输的接口 比如 netty 和 mina 统一为一个网络传输接口
- serialize 数据序列化层 负责管理整个框架中的数据传输的序列化 和反序列化
- 消费都调用Interface接口
- 接口调用Proxy-Proxy使用ProxyFactory生成
- Proxy 经过Filter验证
- 调用Cluster-Invoker
- 调用Directory List访求从注册中心获取所有接口提供者的列表
- 调用Router规则过滤 提供都列表
- 使用LoadBalance 负载均衡策略找到一个合适的提供者
- 如果执行中出现错误 并且Consumer阶段配置了重试机制 则会重新尝试执行
- 再次调用Filter,MonitoryFilter,封装后,
- 调用Invoker,选择协议Protocol
- 封装为DubboInvoker,封装DubbotProtocol
- 调用Netty或者其它的向客户端
- 进行编码和序列化 然后发送数据 对应Codec 与serialization
10.服务收到消息后,进行返解码与反序列化 decode与deserialize
11.使用ChanneleHandler调用DubboHandler处理
12.封装为Exporter - 调用过滤器Filter验证
- 调用Invoker,-通过ProxyFActory创建的一个对象
- Invoker调用接口的Implement实现最终完成调用