使用服务治理实现服务注册与发现
基于客户端的服务注册与发现 Apache Zookeeper
基于服务端的服务注册与发现 Netflix Eureka
分布式协调框架Zookeeper
分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成“脏数据”的后果。
Zookeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
Zookeeper的数据模型
Zookeeper的数据模型很像数据结构当中的树，也很像文件系统的目录。树是由节点所组成，Zookeeper的数据存储也同样是基于节点(Znode)，但是不同于树节点，Znode的引用方式是路径引用，类似于文件路径。
有四种类型的znode：
-
PERSISTENT-持久节点
默认的节点类型，创建节点的客户端与Zookeeper断开连接后，该节点依旧存在
-
PERSISTENT_SEQUENTIAL-持久节点顺序节点
在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号
-
EPHEMERAL-临时节点
当创建节点的客户端与zookeeper断开连接后，临时节点会被删除
-
EPHEMERAL_SEQUENTIAL-临时顺序节点
当创建节点的客户端与zookeeper断开连接后，临时节点会被删除，只是Zookeeper给该节点名称进行顺序编号
Znode元素
data : Znode存储的数据信息。
ACL : 记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。
stat : 包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。
child : 当前节点的子节点引用。
注意：Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过1MB。
Zookeeper的基本操作
创建节点 create
删除节点 delete
判断节点是否存在 exists
获取一个节点的数据 getData
设置一个节点的数据 setData
获取节点下的所有子节点 getChildren
Zookeeper的事件通知
exists,getData,getChildren属于读操作。Zookeeper客户端在请求读操作的时候，可以选择是否设置Watch。
可以把Watch理解成是注册在特定Znode上的触发器。当这个Znode发生改变，也就是调用了create,delete,setData方法的时候，将会触发Znode上注册的对应事件，请求Watch的客户端会接收到异步通知。
Zookeeper的一致性
为了防止单机挂掉的情况，Zookeeper维护了一个集群。Zookeeper Service集群是一主多从结构。在更新数据时，首先更新到主节点(这里的节点是指服务器，不是Znode)，再同步到从节点。在读取数据时，直接读取任意从节点。为了保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法Paxos和Raft。
ZAB(Zookeeper Atomic Broadcast)
ZAB协议有效解决了Zookeeper集群崩溃恢复，以及主从同步数据的问题。
ZAB协议定义的三种节点状态：Looking（选举节点），Following（从节点所处状态），Leading（主节点所处状态）
最大ZXID : 节点本地的最新事务编号，包含epoch和计数两部分，epoch是纪元的意思，相当于Raft算法选主时候的term。
ZAB的4个阶段
1 选举：Looking状态中选举出Leader节点，Leader的lastZXID总是最新的
2 发现：Follower节点向准Leader推送FOllOWERINFO，该信息中包含了上一周期的epoch，接受准Leader的NEWLEADER指令，检查newEpoch有效性，准Leader要确保Follower的epoch与ZXID小于或等于自身的。
3 同步：将Follower与Leader的数据进行同步，由Leader发起同步指令，最总保持集群数据的一致性
4 广播：Leader广播Proposal与Commit，Follower接受Proposal与Commit；
选举
1、每个Follower都向其他节点发送选自身为Leader的Vote投票请求，等待回复；
2、Follower接受到的Vote如果比自己的ZXID更新时则投票，并更新自身的Vote，否则拒绝投票；
3、每个Follower中维护着一个投票记录表，当某个节点收到过半的投票时，结束投票并把该Follower选为Leader，投票结束；
恢复(发现和同步)
发现
1、leader生成新的zxid和epoch，接受follower发送来的FOllOWERINFO（含有当前节点的LastZXID）
2、leader向follower发送NEWLEADER；Leader根据follower发送过来的LastZXID根据数据更新策略向Follower发送更新指令；
同步
1、SNAP：如果follower数据太老，epoch还在上上一轮，leader将发送快照snap指令给follower同步
2、DIFF：正常同步阶段
3、TRUNC：如果Follower是上一轮的少数派(通过对比ztid)，发送TRUNC指令让follower丢弃这段数据
广播
进入正常leader提交阶段，产生递增的zxid，接受半数投票后，再提交。