Dubbo

@Reference 远程注入 RPC
1再zookeeper回去服务的url
2进行远程调用RPC
2将结果封装成对象，给变量赋值


项目模块
服务端- 消费端 -公共端

dubbo-admin管理平台（页面化）
服务查询 ，治理 ，路由， 负载均衡等
服务查询：测试 ,权重 ,服务信息

高级特性

序列化：服务和消费都依赖公共的pojo

地址缓存：zookeeper挂了还 可以服务原来的服务

超时和重试：timeout配置在服务@service 默认超时1秒（建议）     或者客户@Reference
                      当超时后重试retries默认2秒，配置在服务@service

多版本：调用同一个接口的不同版本 服务@service 配置version, 客户@Reference配置version
               灰度发版

负载均衡：权重随机（默认100），@service 配置weight; 客户@Reference配置Lodown
                     权重轮询 ，最少活跃调用，一致hash（相同请求分配）

集群容错：failover失败重试（默认）（一般读操作）；重试2次
                  failfast快速失败 一次 (一般写操作）
                  failsafe失败安全  失败异常返回空 一般日志
                  failback失败重试  定时重发
                  forking 并行调用多个服务 有一个成功就可以
                  broadcast 广播调用所有 有一个失败就失败

服务降级：mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值
      mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响

zookeeper集群中的三种角色Leader、Follower和observer

Leader
1、发起与提交写请求。
所有的跟随者Follower与观察者Observer节点的写请求都会转交给领导者Leader执行。Leader接受到一个写请求后，首先会发送给所有的Follower，统计Follower写入成功的数量。当有超过半数的Follower写入成功后，Leader就会认为这个写请求提交成功，通知所有的Follower commit这个写操作，保证事后哪怕是集群崩溃恢复或者重启，这个写操作也不会丢失。
2、与learner保持心跳
3、崩溃恢复时负责恢复数据以及同步数据到Learner

Follower
1、与老大Leader保持心跳连接
2、当Leader挂了的时候，经过投票后成为新的leader。leader的重新选举是由老二Follower们内部投票决定的。
3、向leader发送消息与请求
4、处理leader发来的消息与请求

observer(观察者)
1、与leader同步数据
2、不参与leader选举，没有投票权。也不参与写操作的提议过程。
3、数据没有事务化到硬盘。即Observer只会把数据加载到内存。