注册中心是微服务架构中的通信中心，服务的消费端可以从中获取服务提供方的地址、状态等信息。
核心功能：
- 服务发现。服务方启动后，注册到注册中心，向注册中心提供自己的ip、port、运行状况指标的uri等。
- 服务记录。存储服务信息。
- 动态管理服务。通过特定的机制测试已注册的服务是否健康。如http、tcp心跳检测。
其他特点：一致性协议、负载均衡策略、雪崩保护、访问协议（HTTP/DNS）、跨注册中心同步等。
CAP原则
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
- 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
- 可用性（A）：保证每个请求不管成功或者失败都有响应。
- 分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。
个人理解：当发生网络分区(因网络问题导致节点之间无法相互访问)时，要求整个系统正常工作，这个就是P，一般分布式系统都要求P。如果数据需要不同分区直接通信才能保证正常的话，那么如果保证了A，那就是每个节点都能写入，但是因为网络分区，不同分区之间无法通信，那就数据就不正常，没了一致性。如果要求数据一致，那就不能让节点写入，也就没了可用性。所以要么AP要么CP。
Eureka是弱数据一致性，选择了AP。他每个节点都能读写，采用 Peer to Peer模式进行数据复制。发生网络分区时也能提供服务，不过由于数据没能及时互相同步，获取到的可能不是最新数据。Eureka通过lastDirtyTimestamp来解决复制冲突；通过hearbeat心跳，即续约操作，来进行数据的最终修复，因为节点间的复制可能会出错，通过心跳就可以发现错误，进行弥补，实现最终一致性。例如发现某个应用实例数据与某个server不一致，则server放回404，实例重新注册即可。
Zookeeper选择CP。跟Eureka不同，他是主从模式，Leader提供读写，Follower只读。他是强一致性，其核心是ZAB协议（Zookeeper原子消息广播协议）：
- 集群在半数以下节点宕机的情况下，能正常对外提供服务。
- 客户端的写请求全部转交给leader来处理，leader需确保写变更能实时同步给所有follower及observer。
- leader宕机或整个集群重启时，需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交，确保丢弃那些只在leader服务器上被提出的事务，并保证集群能快速恢复到故障前的状态。
Nacos可以采用AP或者CP模式，通过Raft算法实现CP，通过Distro协议来实现AP。
常见的分布式一致性算法还有Paxos、ZAB、Gossip算法等。
Paxos、Raft（muti-paxos）和ZAB（muti-paxos）是强一致性的；DNS系统和Gossip协议是弱一致性的（也叫最终一致性）。
Google的Chubby分布式锁服务，采用了Paxos算法；etcd分布式键值数据库，采用了Raft算法；ZooKeeper分布式应用协调服务，Chubby的开源实现，采用ZAB算法。
参考资料
微服务技术栈：常见注册中心组件，对比分析
CAP原则——百度百科
SpringCloud 注册中心 Eureka 集群是怎么保持数据一致的？
浅析Zookeeper的一致性原理
分布式一致性算法-Paxos、Raft、ZAB、Gossip
