1.Dubbo的作用
Dubbo是管理中间层的工具,在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。
Dubbo基于RPC（Remote Procedure Call 远程过程调用）协议，服务提供方和服务消费方之间的调用关系：
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。调用关系说明：
- 0服务容器负责启动，加载，运行服务提供者。
- 1服务提供者在启动时，向注册中心注册自己提供的服务。
- 2服务消费者在启动时，向注册中心订阅自己所需的服务。
- 3注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 4服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 5服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
这个框架要完成调度必须要有一个分布式的注册中心,存储所有服务的元数据,用到zookeeper。
2.Zookeeper的作用
zookeeper用来注册服务和负载均衡。
哪一个服务由哪一个机器来提供必须让调用者知道,简单来说就是ip地址和服务器名称的对应关系。 当然也可以将这种对应关系通过硬编码在调用方业务代码中实现，但是如果提供服务的机器挂掉调用方无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。zookeeper可以通过心跳机制检测挂掉的服务器并将挂掉的服务器的ip和服务器对应的关系从列表中删除。
至于支持高并发，就是横向扩展，在不更改代码的情况通过添加机器来提高运算能力。
3.Zookeeper和Dubbo的关系
- Dubbo将注册中心进行抽象，使得它可以外接不同的存储媒介给注册中心提供服务。
- 引入zookeeper作为存储媒介，也就把zookeeper的特性引了进来。
- 首先是负载均衡：单注册中心的承载能力是有限的，在流量达到一定程度的时候需要分流，负载均衡就是为了分流而存在的，一个zookeeper集群配合相应的web应用就很容易达到负载均衡；
- 资源同步：单单有负载均衡还不够，节点之间的数据和资源是需要同步，zookeeper集群就天然具备有这样的功能；
- 命名服务：将树状结构用于维护全局的服务地址列表，服务提供者在启动的时候，向zookeeper上的指定节点目录下写入自己的URL地址，这个操作就完成了服务的发布
- Mast：ZooKeeper能会保证客户端无法创建一个已经存在的ZNode。也就是说，如果同时有多个客户端请求创建同一个临时节点，那么最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很容易地在分布式环境中进行Master选举了。
-
分布式锁：分布式锁是控制分布式系统之间同步访问共享资源的一种方式。当前获得锁的客户端机器发生宕机或重启，那么该临时节点就会被删除，释放锁。正常执行完业务逻辑后，客户端就会主动将自己创建的临时节点删除，释放锁。
4.dubbo的优点 缺点
优点:
- 透明化的远程方法调用
像调用本地方法一样调用远程方法；只需简单配置，没有任何API侵入。
- 软负载均衡及容错机制
可在内网替代nginx lvs等硬件负载均衡器。
- 服务注册中心自动注册 & 配置管理
不需要写死服务提供者地址，注册中心基于接口名自动查询提供者ip。
使用类似zookeeper等分布式协调服务作为服务注册中心，可以将绝大部分项目配置移入zookeeper集群。
- 服务接口监控与治理
Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能，针对不同应用的不同接口，可以进行 多版本，多协议，多注册中心管理。
缺点：
- 只支持JAVA语言
5.Dubbo中Zookeeper作为注册中心,如果zookeeper注册中心集群都挂掉,服务的发布方和调用方还能通信吗?
启动dubbo时,消费者会从zookeeper中拉去注册的生产者的地址接口等数据,缓存在本地.每次调用时,按照本地存储的地址进行调用.但是在注册中心全部挂掉后增加新的提供者,则不能被消费者发现
健壮性:
- 监控中心宕掉不影响使用，只是丢失部分采样数据
- 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
- 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
- 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
- 服务提供者无状态，任意一台宕掉后，不影响使用
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复