1、主流服务发现对比

目前市面上用的较多的服务发现中心有：Nacos、Eureka、Consul 以及 Zookeeper.

对比项目 Nacos Eureka Consul Zookeeper 一致性 支持AP和CP模型 AP模型 CP模型 CP模型 健康检查 TCP / HTTP / MYSQL / Client Beat Client Beat TCP / HTTP / gRPC / Cmd Keep Alive 负载均衡策略 权重 / metadata / Selector Ribbon Fabio - 雪崩保护 有 有 无 无 自动注销实例 支持 支持 不支持 支持 访问协议 HTTP / DNS HTTP HTTP / DNS TCP 监听支持 支持 支持 支持 支持 多数据中心 支持 支持 支持 不支持 跨注册中心同步 支持 不支持 支持 不支持 SpringCloud集成 支持 支持 支持 不支持 Dubbo集成 支持 不支持 不支持 支持 k8s集成 支持 不支持 支持 不支持

Nacos 作为服务发现中心，具备更多的功能支持项，且从长远来看 Nacos在以后的版本会支持 SpringCloud + Kubernetes 的组合，填补了两者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。另外，Nacos 计划实现 Service Mesh，也是未来微服务发展的趋势。

2、主流配置中心对比

对比项目 Spring Cloud Config Apollo（携程开源） Nacos（阿里开源） 配置实时推送 支持（Spring Cloud Bus） 支持（HTTP长轮询1s内） 支持（HTTP长轮询1s内） 版本管理 支持（Git） 支持 支持 配置回滚 支持（Git） 支持 支持 灰度发布 支持 支持 不支持 权限管理 支持（依赖Git） 支持 不支持 多集群 支持 支持 支持 多环境 支持 支持 支持 监听查询 支持 支持 支持 多语言 只支持Java 主流语言，提供了Open API 主流语言，提供了Open API 配置格式校验 不支持 支持 支持 单机读（QPS） 7(限流所致) 9000 15000 单机写（QPS） 5(限流所致) 1100 1800 3节点读（QPS） 21(限流所致) 27000 45000 3节点写（QPS） 5(限流所致) 3300 5600

从配置中心角度来看，性能方面 Nacos 的读写性能最高，Apollo 次之。Spring Cloud Config 依赖 Git 场景，不适合开放的大规模自动化运维API。 功能方面 Apollo 最为完善，Nacos 具有 Apollo 大部分配置管理功能，而 Spring Cloud Config 不带运维管理界面，需要自行开发。Nacos 的一大优势是整合了注册中心和配置中心功能，部署和操作相比 Apollo 都要只管简单，因此它简化了架构复杂度，并减轻运维及部署工作。 通过对比，综合来看，Nacos 的特点和优势还是比较明显的。

3、Nacos 的四种功能特性

1、服务发现与服务健康检查 Nacos使服务更容易注册，并通过DNS或HTTP接口发现其他服务，Nacos 还提供服务的实时健康检查，以防止向不健康的主机或服务实例发送请求。 2、动态配置管理 动态配置服务允许在所有环境中，以集中和动态的方式管理所有服务的配置。Nacos 消除了在更新配置时重新部署应用程序，这使配置的更改更加高效和灵活。 3、动态 DNS 服务 Nacos提供基于DNS 协议的服务发现能力，旨在支持异构语言的服务发现，支持将注册在 Nacos 上的服务以域名的方式暴露端点，让三方应用方便查询及发现。 4、服务和元数据管理 Nacos 能让开发及维护者从微服务平台建设的视角，去管理数据中心的所有服务及元数据。包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。

.