注册中心Eureka、Zookeeper、Consul的异同点

先上结论：

组件名	语言	CAP	服务监控检查	对外暴露接口	Springcloud集成
Eureka	Java	AP	可配支持	HTTP	已集成
Consul	Go	CP	支持	HTTP/DNS	已集成
Zookeeper	Java	CP	支持	客户端	已集成

基于CAP理论介绍：

C：Consistency （强一致性）
A：Available （可用性）
P：Partition tolerance （分区容错性）

最多只能同时较好的满足两个

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求。因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类。

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强
CP - 满足一致性，分区容错性的系统，通常性能不是特别高
AP - 满足可用性，分区容错性的系统，通常可能对一致性要求低一些

Eureka 采用的是AP架构，只满足可用性和分区容错性
当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。

Eureka有自我保护机制，更强调的是AP，保证服务的高可用，微服务就是偶尔宕机掉线了，一时半会不会立刻删除。

Zookeeper 和 Consul采用的是CP架构，满足一致性和分区容错性
当网络分区出现后，为了保证一致性，就必须拒绝请求，否则无法保证一致性。

Zookeeper、Consul注册的微服务是一个临时节点，只要微服务不可用，发心跳测试收不到了，就迅速剔除微服务，微服务恢复过来以后，会重新换一个serviceID。