注册中心概述
1.zookeeper，eruka,necos,consul这些注册中心。
1.1 使用dubbo作为rpc框架，一般使用zookeeper作为注册中心。
1.2 使用springclould作为rpc框架，用eruka.
zookeeper的介绍：
基于临时节点。
底层实现注册中心的原理
服务向zk的主机进行注册，注册完成，zk会主动向服务调用者推送服务列表，然后服务调用者进行服务发现。
zk的集群架构：是由主从机器，只要主机可以进行服务的写入，服务注册。从机只能进行服务发现。针对CAP理论，满足的是CP。保证了数据的一致性合分区容错性。当服务注册时，如果master进行宕机，会在从机里面选举出一台作为主机进行服务的写入，在这个过程会有zk短时间不可用，选举好了主机，写入完成秒级的通知到从机进行数据同步。保证了服务变更，服务一定能及时被感知发现。
数据的时效性：zk的服务主机同步从机，主动推送调用者服务列表的变更都是秒级。时效性高。由于zk是天生自带监听机制
缺点：不适合服务实例操作上千以上的管理协调。因为服务的变更是主动推送给服务调用者，当大量的服务变更，会批量推送数据，造成网络带宽十分大。
eruka的介绍
实现服务注册于发现的原理：服务注册到eruka时，eruka又一个注册表，存储服务注册信息。服务通过发送心跳机制给eruka的注册表，eruka根据是否正确的发送心跳来判定服务是否可用。当服务发生变更（宕机），注册表会通过心跳机制感知到，会将readWriter的缓存进行清空。之后会通过定时任务，将最新的readWrite的缓存覆盖readOnly的缓存。这时，调用服务在请求获取注册中心时，会先从readOnly,readWriter获取，当缓存为空，会查询注册服务表，查询完，进行同步readWriter缓存。后面通过定时任务刷新readOnly缓存一致。
eruka的时效性比较差，定时任务同步注册表信息。
保证了集群好可用，不保证数据强一致性。会有服务的延迟感知到。
集群架构：
集群之间的机器是点对点的。没有主从之分。CAP保证了CP. 高可用和分区容错性。当一台机器挂掉，服务发送心跳机制就会失败。就会从其他的机器进行故障转移进行注册。
