架构设计
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理论
根据CAP理论，Eureka属于AP系统，可以保证高可用性和分区容错性，但无法保证数据强一致性；
Nacos可以切换AP和CP两种模式：
AP模式：用于生产环境，可以保证高可用性和分区容错性；
CP模式：用于测试环境，可以保证数据一致性和分区容错性，但会损失一定高可用性；
Spring Cloud集成
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集成也更加微服，因此也依然有其存在的意义；
