整理自官网, 对整体理解 Dubbo 很有作用.

作用

Apache Dubbo 是一款高性能, 轻量级的 Java RPC 框架.

三大核心能力

面向接口的远程方法调用

智能容错和负载均衡

以及服务自动注册和发现

健壮性

监控中心宕掉不影响使用, 只是丢失部分采样数据.

数据库宕掉后, 注册中心仍能通过缓存提供服务列表查询, 但不能注册新服务.

注册中心对等集群, 任意一台宕掉后, 将自动切换到另一台.

注册中心全部宕掉后, 服务提供者 和 服务消费者 仍能通过本地缓存通讯.

服务提供者无状态, 任意一台宕掉后, 不影响使用.

服务提供者全部宕掉后, 服务消费者应用将无法使用, 并 无限次重连等待服务提供者恢复.

伸缩性

注册中心为对等集群, 可动态增加机器部署实例, 所有客户端将自动发现新的注册中心.

服务提供者无状态, 可动态增加机器部署实例, 注册中心将推送新的服务提供者信息给消费者.

协议

  • Dubbo 协议
    采用 NIO 复用单一长连接, 并使用线程池并发处理请求, 减少握手和加大并发效率, 性能较好(推荐使用)
    在大文件传输时, 单一连接会成为瓶颈
    可用于生产环境

  • Rmi 协议
    可与原生 RMI 互操作, 基于 TCP 协议
    偶尔会连接失败, 需重建 Stub 可用于生产环境

  • Hessian 协议
    可与原生 Hessian 互操作, 基于 HTTP 协议
    需 hessian.jar 支持, http 短连接的开销大 可用于生产环境

nio 框架

  • Netty Transporter
    JBoss 的 NIO 框架, 性能较好 (推荐使用)
    一次请求派发两种事件, 需屏蔽无用事件.

  • Mina Transporter
    老牌 NIO 框架, 稳定
    待发送消息队列派发不及时, 大压力下, 会出现 FullGC.

序列化

  • Hessian Serialization
    Stable 性能较好, 多语言支持 (推荐使用)
    Hessian 的各版本兼容性不好, 可能和应用使用的 Hessian 冲突, Dubbo 内嵌了 hessian3.2.1 的源码
    可用于生产环境

  • Dubbo Serialization
    Tested
    通过不传送 POJO 的类元信息, 在大量 POJO 传输时, 性能较好
    当参数对象增加字段时, 需外部文件声明 试用

  • Json Serialization
    纯文本, 可跨语言解析, 缺省采用 FastJson 解析
    性能较差 试用

  • Java Serialization
    Java 原生支持 性能较差
    可用于生产环境

生成代理类

  • Javassist ProxyFactory
    通过字节码生成代替反射, 性能比较好 (推荐使用)
    依赖于 javassist.jar 包, 占用 JVM 的 Perm 内存, Perm 可能要设大一些: java -XX:PermSize=128m
    可用于生产环境

  • Jdk ProxyFactory
    JDK 原生支持 性能较差 可用于生产环境

容错机制

  • Failover Cluster
    失败自动切换, 当出现失败, 重试其它服务器, 通常用于读操作 (推荐使用)
    重试会带来更长延迟

  • Failfast Cluster
    快速失败, 只发起一次调用, 失败立即报错, 通常用于非幂等性的写操作 如果有机器正在重启, 可能会出现调用失败 可用于生产环境

  • Failsafe Cluster
    失败安全, 出现异常时, 直接忽略, 通常用于写入审计日志等操作
    调用信息丢失
    可用于生产环境 Monitor

  • Failback Cluster
    失败自动恢复, 后台记录失败请求, 定时重发, 通常用于消息通知操作
    不可靠, 重启丢失
    可用于生产环境 Registry

  • Forking Cluster
    并行调用多个服务器, 只要一个成功即返回, 通常用于实时性要求较高的读操作
    需要浪费更多服务资源
    可用于生产环境

  • Broadcast Cluster
    广播调用所有提供者, 逐个调用, 任意一台报错则报错, 通常用于更新提供方本地状态
    速度慢, 任意一台报错则报错
    可用于生产环境

负载均衡算法

  • Random LoadBalance
    随机, 按权重设置随机概率 (推荐使用)
    在一个截面上碰撞的概率高, 重试时, 可能出现瞬间压力不均

  • RoundRobin LoadBalance
    轮询, 按公约后的权重设置轮询比率
    存在慢的机器累积请求问题, 极端情况可能产生雪崩

  • LeastActive LoadBalance
    最少活跃调用数, 相同活跃数的随机, 活跃数指调用前后计数差, 使慢的机器收到更少请求
    不支持权重, 在容量规划时, 不能通过权重把压力导向一台机器压测容量

  • ConsistentHash LoadBalance
    一致性 Hash, 相同参数的请求总是发到同一提供者, 当某一台提供者挂时, 原本发往该提供者的请求, 基于虚拟节点, 平摊到其它提供者, 不会引起剧烈变动
    压力分摊不均

线程模型

线程模型

IO 线程自行处理:
如果事件处理的逻辑能迅速完成, 并且不会发起新的 IO 请求, 比如只是在内存中记个标识, 则直接在 IO 线程上处理更快, 因为减少了线程池调度.

派发到线程池处理:
但如果事件处理逻辑较慢, 或者需要发起新的 IO 请求, 比如需要查询数据库, 则必须派发到线程池, 否则 IO 线程阻塞, 将导致不能接收其它请求.

如果用 IO 线程处理事件, 又在事件处理过程中发起新的 IO 请求, 比如在连接事件中发起登录请求, 会报 “可能引发死锁” 异常, 但不会真死锁.

分层

业务层: Service

RPC 层: Config, Proxy, Registry, Cluster, Monitor, Protocol

Remote 层: Exchange, Transport, Serialize

  • Service:
    业务层. 包括业务代码的接口与实现.

  • config 配置层:
    对外配置接口, 以 ServiceConfig(暴露的服务配置), ReferenceConfig(引用的服务配置) 为中心, 可以直接初始化配置类, 也可以通过 spring 解析配置生成配置类. 该层管理整个 dubbo 的配置.

  • proxy 服务代理层:
    服务代理层. 在 Dubbo 中, 无论 服务提供者 还是 服务消费者, 框架都会生成一个代理类, 整个过程对上层透明.
    当调用一个远程接口时, 看起来就像调用一个本地接口一样.
    代理层会自动做远程调用并返回结果, 即让业务层对远程调用完全无感知.
    服务接口透明代理, 生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心, 扩展接口为 ProxyFactory

  • registry 注册中心层:
    负责 Dubbo 框架的服务注册与发现. 当有新的服务加入或旧服务下线时, 注册中心都会感知并通知给所有订阅方. 以服务 URL 为中心, 扩展接口为 RegistryFactory, Registry, RegistryService

  • cluster 路由层:
    封装多个提供者的路由及负载均衡, 并桥接注册中心, 以 Invoker 为中心, 扩展接口为 Cluster, Directory, Router, LoadBalance.
    该层主要负责:
    远程调用失败时的容错策略 (如失败重试, 快速失败);
    选择具体调用节点时的负载均衡策略 (如随机, 一致性 Hash 等);
    特殊调用路径的路由策略 (如某个消费者只会调用某个 IP 的生产者)

  • monitor 监控层:
    RPC 调用次数和调用时间监控, 以 Statistics 为中心, 扩展接口为 MonitorFactory, Monitor, MonitorService

  • protocol 远程调用层:
    封装 RPC 调用具体过程., 以 Invocation, Result 为中心, 扩展接口为 Protocol, Invoker, Exporter.
    是服务域, 它是 Invoker 暴露和引用的主功能入口, 它负责 Invoker 的生命周期管理.
    Protocol 是核心层, 也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用, 然后在 Invoker 的主过程上 Filter 拦截点.
    Invoker 是 Dubbo 的核心模型, 框架中所有其他模型都向它靠拢, 或者转换成它, 它代表一个 可执行体.
    允许向它发起 invoke 调用, 它可能是执行一个本地的接口实现, 也可能是一个远程的实现, 还可能是一个集群实现.

  • exchange 信息交换层:
    建立 Request-Response 模型, 封装请求响应模式, 同步转异步, 以 Request, Response 为中心, 扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer

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

  • serialize 数据序列化层:
    若数据要通过网络进行发送, 则需要先做序列化, 变成二进制流.
    序列化层负责管理整个框架网络传输时的 序列化 / 反序列化 工作.
    可复用的一些工具, 扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

分层关系说明

在 RPC 中, Protocol 是核心层, 也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用, 然后在 Invoker 的主过程上 Filter 拦截点.

Consumer 和 Provider 是抽象概念, 只是想让看图者更直观的了解哪些类分属于客户端与服务器端, 不用 Client 和 Server 的原因是 Dubbo 在很多场景下都使用 Provider, Consumer, Registry, Monitor 划分逻辑拓普节点, 保持统一概念.

而 Cluster 是外围概念, 所以 Cluster 的目的是将多个 Invoker 伪装成一个 Invoker, 这样其它人只要关注 Protocol 层 Invoker 即可, 加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响, 因为只有一个提
供者时, 是不需要 Cluster 的.

Proxy 层封装了所有接口的透明化代理, 而在其它层都以 Invoker 为中心, 只有到了暴露给用户使用时, 才用 Proxy 将 Invoker 转成接口, 或将接口实现转成 Invoker, 也就是去掉 Proxy 层 RPC 是可以 Run 的, 只是不那么透明, 不那么看起来像调本地服务一样调远程服务.

而 Remoting 实现是 Dubbo 协议的实现, 如果你选择 RMI 协议, 整个 Remoting 都不会用上, Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层, Transport 层只负责单向消息传输, 是对 Mina, Netty, Grizzly 的抽象, 它也可以扩展 UDP 传输, 而 Exchange 层是在传输层之上封装了 Request-Response 语义.

Registry 和 Monitor 实际上不算一层, 而是一个独立的节点, 只是为了全局概览, 用层的方式画在一起.

包

  • dubbo-common
    公共逻辑模块: 包括 Util 类和通用模型.
    serialize 层放在 common 模块中, 以便更大程度复用.

  • dubbo-remoting
    远程通讯模块: 相当于 Dubbo 协议的实现, 如果 RPC 用 RMI 协议则不需要使用此包.
    transport 层和 exchange 层都放在 remoting 模块中, 为 rpc 调用的通讯基础.
    Remoting 实现是 Dubbo 协议的实现 , 如果你选择 RMI 协议, 整个 Remoting 都不会用上,Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层 ,
    Transport 层只负责单向消息传输 , 是对 Mina, Netty, Grizzly 的抽象, 它也可以扩展 UDP 传输, 而 Exchange 层是在传输层之上封装了 Request-Response 语义 .

  • dubbo-rpc
    远程调用模块: 抽象各种协议, 以及动态代理, 只包含一对一的调用, 不关心集群的管理.
    protocol 层和 proxy 层都放在 rpc 模块中, 这两层是 rpc 的核心, 在不需要集群也就是只有一个提供者时, 可以只使用这两层完成 rpc 调用.

  • dubbo-cluster
    集群模块: 将多个服务提供方伪装为一个提供方, 包括: 负载均衡, 容错, 路由等, 集群的地址列表可以是静态配置的, 也可以是由注册中心下发.

  • dubbo-registry
    注册中心模块: 基于注册中心下发地址的集群方式, 以及对各种注册中心的抽象.

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

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

  • dubbo-container
    容器模块: 是一个 Standlone 的容器, 以简单的 Main 加载 Spring 启动, 因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性, 没必要用 Web 容器去加载服务.
    整体上按照分层结构进行分包, 与分层的不同点在于:
    container 为服务容器, 用于部署运行服务, 没有在层中画出.
    protocol 层和 proxy 层都放在 rpc 模块中, 这两层是 rpc 的核心, 在不需要集群也就是只有一个提供者时, 可以只使用这两层完成 rpc 调用.
    transport 层和 exchange 层都放在 remoting 模块中, 为 rpc 调用的通讯基础.
    serialize 层放在 common 模块中, 以便更大程度复用.