转载：https://blog.csdn.net/duan18888/article/details/124986196
注册中心对比&选型
服务健康检查：Euraka 使用时需要显式配置健康检查支持；Zookeeper、Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。
多数据中心：Consul 和 Nacos 都支持，其他的产品则需要额外的开发工作来实现。
KV 存储服务：除了 Eureka，其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务哦。
CAP 理论的取舍：
Eureka 是典型的 AP，Nacos可以配置为 AP，作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。
而Zookeeper、Etcd、Consul则是 CP 类型牺牲可用性，在服务发现场景并没太大优势；
Watch的支持：Zookeeper 支持服务器端推送变化，其它都通过长轮询的方式来实现变化的感知。
自身集群的监控：除了Zookeeper和Nacos，其它几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的。
Spring Cloud的集成：目前都有相对应的 boot starter，提供了集成能力。
注册中心选型
关于注册中心的对比和选型，其实上面已经讲的非常清楚了，我给出一些个人理解：
关于CP还是AP的选择：选择 AP，因为可用性高于一致性，所以更倾向 Eureka 和 Nacos；关于Eureka、Nacos如何选择，哪个让我做的事少，我就选择哪个，显然 Nacos 帮我们做了更多的事。
技术体系：Etcd 和 Consul 都是Go开发的，Eureka、Nacos、Zookeeper 和 Zookeeper 都是Java开发的，可能项目属于不同的技术栈，会偏向选择对应的技术体系。
高可用：这几款开源产品都已经考虑如何搭建高可用集群，有些差别而已；
产品的活跃度：这几款开源产品整体上都比较活跃。
