Dubbo分布式开发流程：
Dubbo 分布式系统的开发与SpringCloud的生态圈实现原理类似。大致思路如下：
1、首先搭建一个注册中心，推荐使用Zookeeper（当然，也有人用redis）
2、注册中心搭建完成后，需要进行服务的注册，发布服务，发布服务需要使用 spring 容器和 dubbo 标签来发布服务。并且发布服务时需要指定注册中心的位置
3、服务发布之后就是调用服务。一般调用服务也是使用 spring 容器和 dubbo 标签来引用服务，这样就可以在客户端的容器中生成一个服务的代理对象，在 action 或者 Controller 中直接调用 service 的方法即可。Zookeeper 注册中心的作用主要就是注册和发现服务的作用。
dubbo 服务之间的通信协议？
dubbo 支持不同的通信协议，有 dubbo 协议、rmi 协议、hessian 协议、http 协议、webservice。
默认采取 dubbo 协议，单一长连接，进行的是 NIO 异步通信，基于 hessian 作为序列化协议。使用的场景
是：传输数据量小（每次请求在 100kb 以内），但是并发量很高
注册中心挂了,系统能否继续使用?
首先 zookeeper 挂了还能调用服务，在启动 dubbo 时，消费者会从 zk 拉取注册的生产者的地址接口等数据，
缓存在本地。每次调用时，按照本地存储的地址进行调用。前提是你没有增加新的服务，如果你要调用新的服
务，则是不能办到的
Zookeeper
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括:配置维护、域名服务、分布式同步、组服务等。ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、 功能稳定的系统提供给用户。
ZooKeeper 包含一个简单的原语集， 提供 Java 和 C 的接口。ZooKeeper 代码版本中，提供了分布式独享锁、选举、队列的接口，代码在 zookeeper-3.4.3\src\recipes。其中分布锁和队列有 Java 和 C 两个版本，选举只有Java 版本。
原理：
ZooKeeper 是以 Fast Paxos 算法为基础的，Paxos 算法存在活锁的问题，即当有多个 proposer 交错提交时，
有可能互相排斥导致没有一个 proposer 能提交成功，而 Fast Paxos 作了一些优化，通过选举产生一个 leader
(领导者)，只有 leader 才能提交 proposer，具体 算法可见 Fast Paxos。因此，要想弄懂 ZooKeeper 首先得
对 Fast Paxos 有所了解。
ZooKeeper 的基本运转流程:
1、选举 Leader。
2、同步数据。
3、选举 Leader 过程中算法有很多，但要达到的选举标准是一致的。
4、Leader 要具有最高的执行 ID，类似 root 权限。
5、集群中大多数的机器得到响应并 follow 选出的 Leader。
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推
送变更数据给消费者。 - 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，
如果调用失败，再选另一台调用。 - 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计
数据到监控中心