注册中心
Apache Zookeeper -> CP
- 该注册中心遵循CP理念无论何时都会保证数据的一致性，无法保证最终一致性
- 内部有选举机制，一旦mast节点挂掉，那么内部就会30s - 120s 长时间选举，在此期间整个服务都是不可用的，在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。
Spring Cloud Eureka -> AP
- 该注册中心遵循AP理念无法实时保证数据的一致性，但能保证最终一致性
- 内部没有选举机制，不同于ZK，eureka没有mast节点，每一个节点都是副本节点，当集群节点中有一个节点宕掉，该节点请求就会转移到其他节点，当该节点回复eureka就会将刚节点重新纳入集群中去，所有操作都会在节点间复制，将请求复制到其他已知的所有节点间
- 当一个新的eureka节点启动的时候会首先尝试从临近节点获取所有的注册列表信息，并且完成初始化，并且会通过心跳锲约的方式定期更新
- Eureka有保护机制，当一个节点在一定时间没有接收到某个服务的心跳，就会注销该实例，当实例丢失过多的时候就会进入自我保护机制，该机制是为了保护在服务中心在网络故障的情况下大批量丢失实例服务，若是超过85%那么就会进入保护机制如下情况会进入保护机制：
(1) eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；
(2) eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；
(3) 当网络稳定时，当前实例新注册的信息会被同步到其它节点中；
5.Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。
Consul：
- Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）
- Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。
- Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。
- Consul本质上属于应用外的注册方式，但可以通过SDK简化注册流程。而服务发现恰好相反，默认依赖于SDK，但可以通过Consul Template（下文会提到）去除SDK依赖。
- Consul Template
Consul，默认服务调用者需要依赖Consul SDK来发现服务，这就无法保证对应用的零侵入性，所幸通过Consul Template，可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置（比如nginx的upstream），这样对于服务调用者而言，只需要配置一个统一的服务调用地址即可。
6.Consul强一致性(C)带来的是：服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功，Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
7.Eureka保证高可用(A)和最终一致性：服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功，当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。
8.其他方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。
Nacos：
- 目前在使用接触中，无法给更多总结，下列为精品帖子
https://www.cnblogs.com/dalianpai/p/12773879.html
