CAP定理：
指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得。
一致性(C-数据同步耗时)：所有节点在同一时间具有相同的数据，节点越多，数据同步越耗时。
可用性(A-保证正常响应时间)：服务一直可用，保证每个请求不管成功或者失败都有响应，而且是正常响应时间
分区容错性(P-机器数量多)：分区容忍性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，机器越多越好）
值得注意的是，CAP原理指的是在分区容错发生时，只能在保证一致性或可用性中二选其一。因为分区容错不可避免，在系统设计时必须放弃一致性或可用性，没有分区发生时可以同时保证一致性和可用性。
CA 满足的情况下，P不能满足的原因：
数据同步(C)需要时间，也要正常的时间内响应(A)，那么机器数量就要少，所以P就不满足，存在单点问题。
CP 满足的情况下，A不能满足的原因：
数据同步(C)需要时间, 机器数量也多(P)，但是同步数据需要时间，所以不能再正常时间内响应，所以A就不满足。
AP 满足的情况下，C不能满足的原因：
机器数量也多(P)，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以C不满足。
好了，明白这些理论，就可以在相应的场景选择服务注册与发现了。
注册中心选择：
Zookeeper：CP原则，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足
Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化
Consul：保证CA，提供较高的可用性，并能 k-v store 服务保证一致性 CA 类型的场景
结论：分布式系统中 P 肯定要满足，所以只能在CA中二选一。
没有最好的选择，最好的选择是根据业务场景来进行架构设计，
如果要求一致性，则选择zookeeper，如金融行业
如果要求可用性，则Eureka，如电商系统