nacos比eureka好在哪(nacos和eureka哪个好)

微服务-SpringCloudAlibaba-nacos服务注册

SpringCloudAlibaba使用的是nacos作为服务注册，和Eureka对比一下，看看孰优孰劣。

可以对比一下，nacos设计应该和eureka是互相参考的，设计原理基本一样。

和eureka相比，几乎一模一样，不同的是eureka本身需要开发者组装起来，注册中心变化时，nacos会以主动通知的方式通知消费者。

nacos和eureka的区别是什么？

nacos和eureka的区别区别如下：

springcloud eureka是注册中心，负责微服务的注册与发现，起到承上启下的作用，在微服务架构中相当于人体的 大脑，很重要，nacos是阿里巴巴出的，功能类似eureka。

nacos的部署方式与springcloud eureka不太一样，euraka是需要创建springboot项目，然后将euraka服务端通过gav的方式加载进来，然后部署项目。nacos是直接从阿里巴巴nacos的官网下载jar包，启动服务。

Eureka Server：

之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

nacos简介以及作为注册/配置中心与Eureka、apollo的选型比较

Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。

Nacos主要提供以下四大功能：

Nacos支持加权路由，使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。

Nacos提供易于使用的服务仪表板，可帮助您管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计。

nacos具有Apollo大部分功能，最重要的是配置中心与注册中心打通，可以省去我们在微服务治理方面 的一些投入（比如通过动态配置来启停线程池等操作）。

初步结论为：使用Nacos代替Eureka和apollo，主要理由为：

相比与Eureka：

(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。

(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护

(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势

(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。

(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

相比于apollo

(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。

(2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则

(3)性能方面，Nacos读写tps比apollo稍强一些

结论：使用Nacos代替Eureka和apollo

系统模块架构

Nacos提供DNS-F功能

DNS-F落地的技术价值

阿里巴巴、虎牙直播、中国工商银行、爱奇艺、中国平安、平安科技、浙江农信、贝壳、丰巢、百世快递、汽车之家等

完整列表：

Nacos对比Zookeeper、Eureka之间的区别

这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性(C)：在分布式系统中，如果服务器集群，每个节点在同时刻访问必须要保持数据的一致性。

可用性(A)：集群节点中，部分节点出现故障后任然可以使用 （高可用）

分区容错性(P)：在分布式系统中网络会存在脑裂的问题，部分Server与整个集群失去节点联系，无法组成一个群体。

只有在CP和AP选择一个平衡点

CP情况下：虽然我们服务不通用，但是必须要保证数据的一致性。

AP情况下：可以短暂保证数据不一致性，但是最终可以一致性，不管怎么样，要能够保证我们的服务可用

相同点：三者都可以实现分布式注册中心框架

不同点：

Zookeeper采用CP保证数据的一致性的问题，原理采用(ZAP原子广播协议)，当我们ZK领导者因为某种情况下部分节点出现了故障，会自动重新实现选举新的领导角色，整个选举的过程中为了保证数据一致性的问题，客户端暂时无法使用我们的Zookeeper，那么这以为着整个微服务无法实现通讯。

注意：可运行的节点必须满足过半机制，整个zk采用使用。

Eureka采用AP设计思想实现分布式注册中心，完全去中心化、每个节点都是相等，采用你中有我、我中有你相互注册设计思想， 只要最后有一台Eureka节点存在整个微服务就可以实现通讯。

中心化：必须围绕一个领导角色作为核心，选举为领导和跟随者角色

去中心化：每个角色都是均等

Nacos从1.0版本选择Ap和CP混合形式实现注册中心，默认情况下采用Ap，CP则采用Raft协议实现保持数据的一致性。

如果选择为Ap模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例

选择CP模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。

必须要求读取接口的地址保证强一致性的问题，可以采用cp模式， 一般情况下采用ap就可以了

Zookeeper基于ZAP协议实现保持每个节点的数据同步，中心化思想集群模式，分为领导和跟随者的角色

在Raft协议中分为的角色

1.状态：分为三种 跟随者、竞选者、领导

2.大多数： n/2+1

3.任期：每次选举一个新的领导角色 任期都会增加。

默认情况下选举的过程：

核心的设计原理其实就是靠的 谁超时时间最短谁就有非常大的概率为领导角色。

疑问：是否可能会产生两个同时的竞选者呢，同时实现拉票呢？

注意当我们的集群节点总数，如果是奇数情况下 就算遇到了该问题也不用担心。

当我们的节点是为偶数的情况下，可能会存在该问题，如果两个竞选者获取的票数相等的情况下，开始重置竞选的超时时间，一直到谁的票数最多谁就为领导。

本文参考蚂蚁课堂：

Nacos,Eureka与ZooKeeper的比较

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

3.1 Zookeeper保证CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

3.2 Eureka保证AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：?

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务?

2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)?

3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。