Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。

dubbo是一个分布式框架，远程服务调用的分布式框架，其核心部分包含：

集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

远程通讯：提供对多种长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

自动发现：基于注册中心目录服务，使消费提供方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

因为是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。内部使用了 Netty、Zookeeper，保证了高性能高可用性。

使用 Dubbo 可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。

透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需要简单配置，没有任何API入侵。软负载均衡及容错机制，可以在内网替代F5等硬件负载均衡器。降低成本，减少单点。服务自动注册与发现，不在需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

两个没关联，如果硬要说区别，有以下几点。

1）通信方式不同

Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。

2）组成部分不同

不需要，如果硬要用 Web 容器，只会增加复杂性，也浪费资源。

Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。

推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中心，但不推荐。

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check="true"，可以通过 check="false" 关闭检查。

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。

目前暂时不支持，后续可能采用基于 JTA/XA 规范实现，如以图所示。

可以的，项目地址如下。

https://github.com/apache/incubator-dubbo-spring-boot-project

讲解他的架构图之前，我们先普及下几个概念。

节点角色说明：

如图，我们可以简单理解为web1234需要调用service1234的服务，所以web1234是消费者，service1234是生产者。

你看着晕不晕？晕不晕？晕不晕？反正我是晕了，万一分布式得更多呢？，所以我们需要他：

Registry（注册中心）: 服务注册与发现的注册中心。dubbo推荐的是zookeeper。什么是zookeeper？zookeeper是用于分布式中一致性处理的框架。简单的讲，zookeeper就是个中介，卖楼的（生产者）把楼盘信息放在中介（注册中心）那里，想买楼的（消费者）去中介那里获得楼盘资源清单。于是，我们的图变成了这样：

是不是好很多了？还不够， 我们还需要个监控中心（干嘛用的？当然是监控用的，调用失败怎么办？挂了怎么办？）：Monitor: 统计服务的调用次调和调用时间的监控中心。（不画图了）

然后，Provider放在容器里运行，就叫做Container服务运行容器。（不画图了）

最终dubbo架构，如图（从0开始看起）：

自己脑海里按照上图走了一遍后，看看自己想的是不是和下面说明一样。