Dubbox 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbox就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbox这样的分布式服务框架的需求，并且本质上是个服务调用的东西，说白了就是个远程服务调用的分布式框架。
SOA是Service-Oriented Architecture的首字母简称，它是一种支持面向服务的架构样式。从服务、基于服务开发和服务的结果来看，面向服务是一种思考方式。
Dubbo能做什么？
最简单直接的说法就是：dubbo本身是一个程序，在开发中作为jar包供我们使用，dubbo为我们做的就是根据服务的url去调用服务（基于rpc协议的调用）。
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo基于RPC（Remote Procedure Call 远程过程调用）协议，服务提供方和服务消费方之间的调用关系：
-
Provider: 暴露服务的服务提供方。
-
Consumer: 调用远程服务的服务消费方。
-
Registry: 服务注册与发现的注册中心。
-
Monitor: 统计服务的调用次调和调用时间的监控中心。
-
Container: 服务运行容器。
调用关系说明：
-
服务容器负责启动，加载，运行服务提供者。
-
服务提供者在启动时，向注册中心注册自己提供的服务。
-
服务消费者在启动时，向注册中心订阅自己所需的服务。
-
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
-
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
-
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
Dubbo 属于 RPC 框架，连接消费者和生产者，注册中心 监控被调用对象的运行状态
Dubbo提供的注册中心有如下几种类型可供选择：
- Multicast注册中心
- Zookeeper注册中心
- Redis注册中心
- Simple注册中心
dubbo和zookeeper的关系：
对于注册中心的选择，我们一般用Zookeeper，那么zookeeper和dubbo的关系是怎么样的
上面这个图如果看不太懂的话，建议看一下 ZooKeeper的数据模型 ，这里简单解释一下：
zookeeper的数据模型跟我们windows系统下的文件模型相似，都是树形结构的;
windows下的文件系统有文件夹和文件两种，文件夹只是路径，文件才是存储体；
而zookeeper的数据模型也是树结构的，每个节点叫做znode，每个znode既可以存储数据也可以当做路径
树形结构的节点都是唯一的，而上面这个图上的绿色圆点都是zookeeper中的一个znode，每个znode都有自己的路径和自己的值，存储着我们dubbo注册的service信息，而上面这张图的znode分为4级（root、service、type、url）：
- 一级节点root内存储着dubbo，代表这个znode下的所有znode都是dubbo相关的
- 二级节点service存储着我们dubbo注册到zk中的service名称，每多注册一个service服务，就会在dubbo这个znode下添加一个新的service节点
- 三级节点type存储着service类型，是提供者还是消费者
- 四级节点url存储着我们所注册的服务的具体地址
dubbo就是通过这一层层的节点找到我们需要调用的url然后进行调用的。
zookeeper作为dubbo的注册中心的角色使用
我们把提供者和消费者通过dubbo注册到zookeeper这个注册中心里，zookeeper中存储的是服务的url的列表
通过消费者调用提供者服务的时候，会根据接口的名称类型通过dubbo到zookeeper中找到对应的服务的url列表，zookeeper返回服务提供者地址列表给消费者
消费者从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用（这个调用就是图1 消费者和提供者的调用关系），如果调用失败，再选另一台调用