Dubbo是一个高性能的RPC分布式框架,内部使用了 Netty、Zookeeper,保证了高性能高可用性。
默认协议是Dubbo
节点角色说明:
- Provider(生产者): 暴露服务的服务提供方。
- Consumer(消费者): 调用远程服务的服务消费方。
- Registry(注册中心): 服务注册与发现的注册中心。dubbo推荐的是zookeeper。什么是zookeeper?zookeeper是用于分布式中一致性处理的框架。
- Monitor: 统计服务的调用次调和调用时间的监控中心。
Dubbo内部使用的是自己定义的URL类,而不是java.net.url
如果注册的服务有多个实现类,还需要传版本(version)
流程图

0 服务容器负责启动,加载,运行服务提供者。
1. 服务提供者(生产者)在启动时,向注册中心注册自己提供的服务。
2. 服务消费者在启动时,向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
5. 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心


RPC over HTTP
RPC over TCP
dubbo底层可以使用netty(默认)或者tomcat服务器
面试题
Dubbo的好处
- 透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。
- 软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。
- 服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。(下面讲解)
- Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置即可,Dubbo基于Spring的Schema扩展进行加载。
Dubbo启动时如果依赖的服务不可用会怎样?
Dubbo 缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring 初始化完成,默认 check=”true”,可以通过 check=”false” 关闭检查。
当一个服务接口有多种实现时怎么做?
当一个接口有多种实现时,可以用 group 属性来分组,服务提供方和消费方都指定同一个 group 即可。
Dubbo支持分布式事务吗?
目前暂时不支持
