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

先上结论:

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

基于CAP理论介绍:
注册中心Eureka、Zookeeper、Consul的异同点
C:Consistency (强一致性)
A:Available (可用性)
P:Partition tolerance (分区容错性)

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

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

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

Eureka 采用的是AP架构,只满足可用性和分区容错性
当网络分区出现后,为了保证可用性,系统B可以返回旧值,保证系统的可用性。
注册中心Eureka、Zookeeper、Consul的异同点
Eureka有自我保护机制,更强调的是AP,保证服务的高可用,微服务就是偶尔宕机掉线了,一时半会不会立刻删除。

Zookeeper 和 Consul采用的是CP架构,满足一致性和分区容错性
当网络分区出现后,为了保证一致性,就必须拒绝请求,否则无法保证一致性。
注册中心Eureka、Zookeeper、Consul的异同点
Zookeeper、Consul注册的微服务是一个临时节点,只要微服务不可用,发心跳测试收不到了,就迅速剔除微服务,微服务恢复过来以后,会重新换一个serviceID。