Nacos、Eureka、Zookeeper、Consul对比
开发中，经常需要对微服务进行管理，所以需要引入一些服务治理的中间件，用于注册、发现服务，常见的服务治理中间件为
服务治理中间件
【1】Nacos
【2】Eureka
【3】Zookeeper
【4】Consul（Consul 所在的 HashiCorp 公司宣布，不允许中国境内使用该公司旗下的产品和软件。）
对比一览表
| 名称 | Nacos | Eureka | Zookeeper | Consul |
|---|---|---|---|---|
| 开发语言 | Java | Java | C | Java |
| 功能特性 | 服务注册&发现、配置管理、流量控制、DNS、动态DNS | 服务注册&发现 | 数据存储、协调 | 服务注册&发现、配置管理 |
| 应用场景 | K8S、Service Mesh、SpringCloud | SpringCloud | Hadoop分布式集群 | K8S、SpringCloud |
| CAP理论 | CP/AP | AP | CP | CP |
| 运行模式 | 自主部署、集群模式 | 自主部署、集群模式 | 需独立部署、启动集群 | |
| 其它 | OpenAPI标准、支持多语言 | Spring开发、易于集成 | ||
| 开发者 | 阿里巴巴 | NetFilx | Apache基金会 |
CAP理论
CP：Consistency and Partition tolerance 一致性与分区容错度
AP：Availability and Partition tolerance 可用性与分区容错度
一致性（C）：确保分布式系统中的所有数据备份在同一时刻具有相同的值，即所有节点访问同一份最新的数据副本。
~
可用性（A）：在集群中一部分节点发生故障后，集群整体仍然能够响应客户端的读写请求，保持服务的高可用性。
~
分区容错性（P）：在分布式系统中，由于网络分区等原因，系统可能会无法与部分节点通信，此时系统必须能够继续提供服务，即使是在部分节点不可用的情况下。
CAP三者是相互矛盾的！
一个分布式系统，不能同时将CAP都很好的满足，只能满足其中两者，所以可以使用AP策略、也可以用CP策略
功能特性
Nacos是一个全栈的解决方案，而支持服务发现、配置管理和流量管理等多个功能。
Eureka专注于服务注册和发现、适用于SpringCloud体系。
Zookeeper则是一个通用的分布式数据存储和协调系统，适用于大规模分布式系统的场景
Consul与Nacos基本相同
负载均衡
Nacos 本身具备负载均衡能力，可以提供服务端负载均衡与客户端负载均衡。
Zookeeper 不支持。
Eureka 本身不支持，通过Ribbon做负载均衡。
Consul 本身不支持，通过Fabio做负载均衡。
健康检查
服务端健康检查最常见的方式是 TCP 端口探测和 HTTP 接口返回码探测，这两种探测方式因为其协议的通用性可以支持绝大多数的健康检查场景。Zookeeper 和 Eureka 都实现了⼀种 TTL(Time To Live)机制，就是如果客户端在⼀定时间内没有向注册中心发送心跳，则会将这个客户端摘除。
Zookeeper 使用TCP的KeepAlive保持客户端和服务端的连接。
Eureka 通过客户端心跳来确定客户端是否启动。
Consul 通过check方法实现健康检查，check方法有五种：Script + Interval、HTTP + Interval、TCP+ Interval、Docker + interval、TTL。
Nacos 既支持客户端的健康检查（KeepAlive、Client Beet），也支持服务端的健康检查（MYSQL命令等）。
性能与容量
影响读写性能的因素很多：⼀致性协议、机器的配置、集群的规模、存量数据的规模、数据结构及读写逻辑的设计等等。并非性能越高就越好，因为追求性能往往需要其他方面做出牺牲。
Zookeeper 在写性能可以达到上万的 TPS，容量从存储节点数来说可以达到百万级别。不过 Paxos 协议限制了 Zookeeper 集群的规模（3、5个节点）。当大量实例上下线时，Zookeeper 的表现并不稳定，同时在推送机制上的缺陷，会引起客户端的资源占用上升，从而性能急剧下降。
Eureka 在服务实例规模在 5000 左右的时候，就已经出现服务不可用的问题，甚至在压测的过程中，如果并发的线程数过高，就会造成 Eureka crash。
Nacos 在开源版本中，服务实例注册的支撑量约为 100 万，服务的数量可以达到 10 万以上。