Eureka,Zookeeper,Consul三者异同点以及CAP规则

三者之间的比较

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

CAP规则

鉴于现在的微服务架构，这个P，我们永远都要保证，系统要么是AP，要么是CP，三个里面不可能全占

CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求。

因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类:

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

典型案例

AP（Eureka）

当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。

• 当没有出网络分区时，系统A与系统B的数据一致，X=1
• 将系统A的X修改为2，X=2
• 当出现网络分区后，系统A与系统B之间的数据同步数据失败，系统B的X=1
• 当客户端请求系统B时，为了保让可用性，此时系统B应返回旧值，X=1

结论：违背了一致性C的要求，只满足可用性和分区容错，即AP，Eureka在服务断开连接以后，并不会将其清除出注册表，也就是自我保护机制，这个机制就是AP的一种体现（好死不如赖活着），当然我们也可以关闭自我保护机制开启无情模式。

CP（Zookeeper和Consul）

当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性

• 当没有出网络分区时，系统A与系统B的数据一致，X=1
• 将系统A的X修改为2，X=2
• 当出现网络分区后，系统A与系统B之间的数据同步数据失败，系统BX=1
• 当客户端请求系统B时，为了保证一致性，此时系统B应拒绝服务请求，返回错误码或错误信息

结论:违背了可用性A的要求，只满足—致性和分区容错，即CP,Zookeeper中，当服务关闭以后，Zookeeper在给服务发送心跳没有回应，它就把服务给删了，等恢复了服务，重新再以新的id上线；Consul中，如果服务关闭了，会在管理界面看见健康检查一栏为x。