选型背景

方案对比

结论

结合实际业务和开发需要，着重考虑性能可靠性、功能和社区支持程度三方面，认为Nacos更适合作为服务发现和管理的技术框架。具体理由如下：

• 性能更好，可靠性更高 

• 经过阿里、APISIX、SpringCloudAlibaba,阿里内部的钉钉、考拉、饿了么、优酷等业务验证
• Nacos 在开源版本中，服务实例注册的支撑量约为 100 万，服务的数量可以达到 10 万以上
• 集群支持主从和平级，且有雪崩保护等机制

对于Nacos，根据最新的nacos官方描述，Nacos2.0 对连接模型、服务发现的数据模型及运作模式进行了大范围的重构，在模拟较真实的大规模使用场景下，使用 PAS 性能评估服务平台进行压测，其原理是基于利用 JMeter 引擎，使用 PAS

自动生成的 JMeter 脚本，进行压测，在服务端为8c16u的10节点集群，客户端为4c8u的200节点集群下，Nacos2.0 能够较无压力的支撑 10w 级的客户端和 50w 级的服务实例；

对于Eruka，在服务实例规模在 5000 左右的时候，Eruka就已经出现服务不可用的问题，甚至在压测的过程中，如果并发的线程数过高，就会造成 Eureka crash；

对于Zookeeper，paxos 协议限制了 Zookeeper 集群的规模（3、5个节点）。当大量实例上下线时，Zookeeper 的表现并不稳定，同时在推送机制上的缺陷，会引起客户端的资源占用上升，从而性能急剧下降。

• 功能更加丰富，覆盖范围更好

• 良好的图形界面更直观的管理服务上下线、调度、同时具备配置中心的功能
• 支持全面的负载均衡、支持AP/CP两种模型、支持业务和环境分组、支持自我监控、安全认证方式丰富

• 社区更活跃、学习成本更低

• 当前nacos2极其活跃，推出了多种新特性，且中文文档丰富
• 便于迁移至服务网格，通过MCP/XDS协议与Istio通信将Nacos服务下发Sidecar，可以无缝和K8s服务发现体系互通