微服务架构 - 服务发现、配置中心对比 - Nacos

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 能让开发及维护者从微服务平台建设的视角，去管理数据中心的所有服务及元数据。包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。

 
 
 
 
 
 
 
 
 
 
 
 
 
.