Spring Cloud全解析：服务注册中心的多维度产品对比与优选指南
注册中心不同产品的对比
| 产品 | 使用语言 | CAP | 数据一致性 | 多数据中心 | Watch支持 | KV存储 | 服务健康检查 | 对外暴露接口 | Spring Cloud集成 |
|---|---|---|---|---|---|---|---|---|---|
| Eureka | java | AP | – | – | Long Polling | – | 可配置支持 | HTTP | 已集成 |
| zookeeper | java | CP | ZAB(Paxos) | – | 支持 | 支持 | 心跳 | 客户端 | 已集成 |
| consul | go | CP | Raft | 支持(Gossip) | Long Polling | 支持 | 服务状态、内存、磁盘等 | HTTP/DNS | 已集成 |
- Eureka集群模式，集群内的每个机器地位是相等的，不存在主从，每个服务可以向任意一个Eureka实例进行服务注册与发现，集群中的每一个Eureka实例接收到写请求之后都会自动同步给其他所有的Eureka实例
- Eureka是对等模式，可能数据还没同步完，然后就宕机了，此时还是可以从其他机器拉取注册信息，只是不保证是最新的注册信息，该过程服务可以向其他没有宕机的节点进行注册，为了保证A而舍弃了C
- Zookeeper 是有Leader+Follower两种角色，只有Leader负责写，也就是服务注册，然后把数据同步给所有的Follower，进行读操作时，也就是服务发现
- 由于Zookeeper是只有Leader是进行写操作的，如果leader挂了，需要重新选举新的leader，此时集群是不可用的，为了保证C而舍弃了A
CAP原则
- 一致性C(Consistency) 在分布式系统中的所有数据备份，所有节点的数据一致，都是最新的数据
- 可用性A(Availability) 在集群中任何一个节点挂了，其他节点可以继续对外提供服务
- 分区容错性P(Partition tolerance) 在分布式系统中每台主机称为一个分区，系统如果不能在时限内达成数据一致性或者无法及时响应客户端请求，都意味着出现了分区的情况，此时就需要在C和A之间做出选择，即为容错性
CP:如果需要一致性，就会影响到可用性，一旦系统出现故障，就需要等待一段时间进行修复，在修复期间无法对外提供服务，数据同步会消耗时间，导致可用性降低
AP:如果需要可用性，只要有一个服务在，就能正常接受请求，只能放弃强一致性，采用最终一致性
CA:如果想要满足一致性和可用性，那么分区容错性就难保证了，只能是单点
https://zhhll.icu/2021/框架/微服务/springcloud/注册中心/2.注册中心不同产品的对比/