Eureka采用CS架构,由服务注册中心Eureka Server和服务提供者/消费者Eureka Client组成。Nacos采用高可用的P2P设计(无主节点),所有的server节点都是同等作用,支持AP和CP两种模式。
Eureka基于HTTP RESTful API进行通信。Nacos同时支持HTTP和TCP两种通信方式,TCP方式效率更高,适用于服务间通信。
Eureka基于拉模式,Eureka Client会定期从Server拉取服务信息。Nacos基于推送模式,Server会实时推送服务信息变化给Client,AP模式下更适合大规模服务规模。
Eureka：通过注册中心定期拉取服务列表,有缓存,默认每30秒拉取一次。
Nacos：推送式服务列表更新,注册中心每次服务列表变化都会实时推送给订阅者,服务端和客户端保持心跳连接。
Eureka只支持基于HTTP的健康检查。Nacos同时支持HTTP和TCP两种健康检查,TCP连接方式可以更精确判断实例是否可用。
Eureka:支持HTTP健康检查,客户端定期(默认每30秒)向服务端发起HTTP请求,以此来判断服务是否可用。
Nacos:支持HTTP和TCP两种健康检查方式。TCP方式通过socket连接来判断服务健康性,更加准确。
Eureka的元数据信息较简单。Nacos的元数据更丰富,支持服务分类、权重、健康状态等信息。
Eureka只有区域(region)和区域(zone)两级隔离机制。Nacos通过namespace、group和service三级来实现隔离,更加细粒度。
Eureka没有流量控制功能。Nacos支持对服务的流量、实例数和权重进行精细化控制,用于金丝雀发布、蓝绿部署等场景。
Eureka采用主备模式实现高可用,一个主节点和多个备份节点。主节点失效时,备份节点进行选举产生新的主节点。这种模式下,主节点压力较大。
Nacos采用无主节点设计,所有的节点都是平等的,通过Raft协议实现高可用。多个节点会选举出Leader,但Leader也参与服务注册和查询等工作,压力较小。当Leader失效时,会重新选举产生新的Leader节点,整个服务不会中断。
Eureka通过备份节点定期从主节点拉取注册表信息进行同步。这种拉模式下,主备节点数据无法做到实时一致。
Nacos通过Raft协议实现数据同步,许多机制保证数据强一致,如入队出队机制、Commit机制、Snapshot机制等。Leader节点数据更新后,很快就会复制到Follower节点,数据实时一致。
根据CAP理论,Eureka属于AP系统,可以保证高可用性和分区容错性,但无法保证数据强一致性。
Nacos可以切换AP和CP两种模式:
AP模式:用于生产环境,可以保证高可用性和分区容错性。
CP模式:用于测试环境,可以保证数据一致性和分区容错性,但会损失一定高可用性。
Eureka深度集成于Spring Cloud,开箱即用
Eureka通过spring-cloud-starter-netflix-eureka可以轻松嵌入Spring Cloud应用。
Nacos可以通过Spring Cloud Alibaba来实现集成,需要自行引入依赖。
Nacos可以通过spring-cloud-starter-alibaba-nacos-discovery集成到Spring Cloud应用中,但需要额外引入spring-cloud-starter-alibaba-nacos-config来配置Nacos地址等信息,配置较为繁琐。
Nacos在机制设计和理论基础上都超过了Eureka,其无主节点设计、强数据一致性和CAP切换都很值得学习。但Eureka简单易用,Spring Cloud集成也更加微服,因此也依然有其存在的意义。
总之,Nacos在架构设计、功能特性和Spring Cloud集成方面都超越了Eureka,适用于更大规模的服务治理场景。但Eureka的简单易用也有其优势,依然适用于小规模服务场景。