dubbo
Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
dubbo 框架设计
基本设计原则
- 采用 Microkernel + Plugin 模式,Microkernel 只负责组装 Plugin,Dubbo 自身的功能也是通过扩展点实现的,也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
- 采用 URL 作为配置信息的统一格式,所有扩展点都通过传递 URL 携带配置信息。
整体设计

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

图例说明:
- 图中小方块 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表层或模块,蓝色的表示与业务有交互,绿色的表示只对 Dubbo 内部交互。
- 图中背景方块 Consumer, Provider, Registry, Monitor 代表部署逻辑拓扑节点。
- 图中蓝色虚线为初始化时调用,红色虚线为运行时异步调用,红色实线为运行时同步调用。
- 图中只包含 RPC 的层,不包含 Remoting 的层,Remoting 整体都隐含在 Protocol 中。
调用链
展开总设计图的红色调用链,如下:

dubbo 集群
集群容错机制
Dubbo的集群容错机制分为6种,分别是:FailOver,FailFast,FailSafe,FailBack,Forking,Broadcast。
FailOver
失败自动切换,当出现失败,重试其它服务器。(缺省)
通常用于读操作,但重试会带来更长延迟。
可通过retries=”2”来设置重试次数(不含第一次)。
1 | <dubbo:service retries="2" /> |
1 | <dubbo:reference retries="2" /> |
1 | <dubbo:reference> |
FailFast
快速失败,只发起一次调用,失败立即报错。
通常用于非幂等性的写操作,比如新增记录。
FailSafe
- 失败安全,出现异常时,直接忽略。
- 通常用于写入审计日志等操作。
FailBack
- 失败自动恢复,后台记录失败请求,定时重发。
- 通常用于消息通知操作。
Forking
- 并行调用多个服务器,只要一个成功即返回。
- 通常用于实时性要求较高的读操作,但需要浪费更多服务资源。
- 可通过forks=”2”来设置最大并行数。
Broadcast
- 广播调用所有提供者,逐个调用,任意一台报错则报错。(2.1.0开始支持)
- 通常用于通知所有提供者更新缓存或日志等本地资源信息。
Forking 与 Broadcast 的区别:
- Forking:同时并行调用多台服务器,有一台成功即为成功
- Broadcast:逐个调用所有提供者(Provider),任一台报错则报错
集群负载均衡策略
- Random LoadBalance: 随机选取提供者策略,有利于动态调整提供者权重。截面碰撞率高,调用次数越多,分布越均匀;默认策略;
- RoundRobin LoadBalance: 轮循选取提供者策略,平均分布,但是存在请求累积的问题;(平滑加权轮询算法)
- LeastActive LoadBalance: 最少活跃调用策略,解决慢提供者接收更少的请求;
- ConstantHash LoadBalance: 一致性Hash策略,使相同参数请求总是发到同一提供者,一台机器宕机,可以基于虚拟节点,分摊至其他提供者,避免引起提供者的剧烈变动。