@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只会把数据加载到内存。
