为什么使用Nacos而不是Eureka（Nacos和Eureka的区别）

---

前言

为什么如今微服务注册中心用Nacos相对比用Eureka的多了？本文章将介绍他们之间的区别和优缺点。

---

一、Eureka是什么？

简介：
Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。

---

详解：
Eureka包含两个组件：Eureka Server和Eureka Client。

• Eureka Server：Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
• Eureka Client：Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。

---

Eureka闭源影响

在Euraka的GitHub上，宣布Eureka 2.x闭源。近这意味着如果开发者继续使用作为 2.x 分支上现有工作
repo 一部分发布的代码库和工件，则将自负风险。

二、Nacos是什么？

简介：
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。简单来说 Nacos 就是 注册中心 + 配置中心的组合，提供简单易用的特性集，帮助我们解决微服务开发必会涉及到的服务注册 与发现，服务配置，服务管理等问题。 Nacos 还是 Spring Cloud Alibaba 组件之一，负责服务注册与发现。

---

Namespace隔离设计：
Nacos提供了namespace来实现环境隔离功能。

• nacos中可以有多个namespace
• namespace下可以有group
• 不同namespace之间相互隔离，例如不同namespace的服务互相不可见
  命名空间用于进行隔离，Namespace 的常用场景之一是不同环境的隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。
  

三、Nacos和Eureka的区别

3.1 支持的CAP

• Consistency（一致性） ：数据一致更新，所有数据的变化都是同步的
• Availability（可用性） ：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求
• Partition tolerance（分区容忍性） ：某个节点的故障，并不影响整个系统的运行

注册中心	AP	CP
Eureka	支持	不支持
Nacos	支持	支持

注：nacos是根据配置识别CP或AP模式,如果注册Nacos的client节点注册时是ephemeral=true即为临时节点,那么Naocs集群对这个client节点效果就是AP,反之则是CP,即不是临时节点

3.2连接方式

• Nacos使用的是netty和服务直接进行连接,属于长连接
• Eureka是使用定时发送和服务进行联系,属于短连接

3.3 服务异常剔除

Nacos:
Nacos client 通过心跳上报方式告诉 nacos注册中心健康状态,默认心跳间隔5秒，nacos会在超过15秒未收到心跳后将实例设置为不健康状态，可以正常接收到请求超过30秒nacos将实例删除,不会再接收请求

---

Eureka:
Eureka client在默认情况每隔30s想Eureka Server发送一次心跳,当Eureka Server在默认连续90s秒的情况下没有收到心跳, 会把Eureka client 从注册表中剔除,在由Eureka-Server 60秒的清除间隔,把Eureka client 给下线，也就是在极端情况下Eureka 服务 从异常到剔除在到完全不接受请求可能需要 30s+90s+60s=3分钟左右(还是未考虑ribbon缓存情况下)

---

所以Nacos服务异常剔除效率高于Eureka

3.4 操作实例方式

Nacos:
提供了nacos console可视化控制话界面,可以对实例列表进行监听,对实例进行上下线,权重的配置,并且config server提供了对服务实例提供配置中心,且可以对配置进行CRUD,版本管理

---

Eureka:
仅提供了实例列表,实例的状态,错误信息,相比于nacos过于简单

---

所以Nacos相对于Eureka操作更详细，多元化

---

总结

综上所述，Nacos更优于Eureka，这也是为什么我们更倾向于使用Nacos而不是Eureka。（而且Eureka闭源了）