Eureka和Nacos都可以作为注册中心,它们之间的区别
在微服务架构中,由于服务实例数量多、位置动态变化,需要一套机制来管理服务的位置信息,也就是注册中心。
Nacos与Eureka有相同点,也有不同之处,可以从以下几点来描述:
- 接口方式对比
- 实例类型对比
- 健康检测对比
- 服务发现对比
1. 接口方式对比
Nacos与Eureka都对外暴露了Rest风格的API接口,用来实现服务注册、发现等功能
Eureka的REST API设计
# 服务注册
POST /eureka/apps/{appID}
Content-Type: application/json{"instance": {"instanceId": "user-service-001","hostName": "192.168.1.100","app": "USER-SERVICE","ipAddr": "192.168.1.100","port": {"$": 8080, "@enabled": "true"},"securePort": {"$": 443, "@enabled": "false"},"status": "UP"}
}# 服务发现
GET /eureka/apps/{appID}
Accept: application/json# 心跳续约
PUT /eureka/apps/{appID}/{instanceID}# 服务下线
DELETE /eureka/apps/{appID}/{instanceID}
Nacos的REST API设计
# 服务注册
POST /nacos/v1/ns/instance
Content-Type: application/x-www-form-urlencodedserviceName=user-service&ip=192.168.1.100&port=8080&namespaceId=dev&groupName=DEFAULT_GROUP&ephemeral=true# 服务发现
GET /nacos/v1/ns/instance/list?serviceName=user-service&namespaceId=dev&groupName=DEFAULT_GROUP# 心跳续约
PUT /nacos/v1/ns/instance/beat
serviceName=user-service&ip=192.168.1.100&port=8080&beat={"state":"up"}# 服务下线
DELETE /nacos/v1/ns/instance?serviceName=user-service&ip=192.168.1.100&port=8080
可以看到两者虽然都是Rest风格的接口,但是仍然有差别
- 命名空间支持:
- Eureka:URL路径中只有应用名维度
- Nacos:支持namespace、group多维度隔离
- API版本管理:
- Eureka:没有明确的版本号
- Nacos:在URL中包含版本号(/v1/),便于后续演进
2. 实例类型对比
Nacos的实例有永久和临时实例之分;而Eureka只支持临时实例
对于Nacos的永久实例,即使实例宕机,服务信息仍保留在注册中心,恢复后可快速重新提供服务,而Eureka只有临时实例,实例宕机后会被注册中心删除,需要重新注册,因此Nacos的可以选择性地提高某些服务数据的安全性,更加灵活
3. 健康检测对比
Nacos对临时实例采用心跳模式检测,对永久实例采用主动请求来检测;Eureka只支持心跳模式
Nacos的差异化健康检测策略
临时实例:
-
客户端
- Nacos客户端注册时,同时会开启一个定时任务,默认定时5秒会发送心跳信息,
-
服务端
- 通过Controller从request中解析心跳信息,然后进行更新心跳时间等信息,
- 而心跳检测则是在服务端注册服务时,在初始化服务的过程中会开启心跳检测,心跳检测以定时任务的形式,默认延迟5秒每5秒执行一次,
- 检测时会将上次心跳时间距今大于15秒的实例标记为不健康,将会将上次心跳时间距今大于30秒的实例从实例列表中剔除
非临时实例:
- 客户端
- Nacos客户端注册时,对于非临时实例不会启动心跳任务,而是由服务端主动发起健康检查
- 服务端
- Nacos服务端在服务初始化中进行集群初始化时,会为集群创建定时任务,默认每5秒定时为实例创建健康检查任务并添加到阻塞队列,异步进行健康检查
- 健康检查默认采用TCP连接检测,尝试建立TCP连接到实例的指定端口,连接成功即为健康,连接失败或超时(默认5秒)则标记为不健康
- 检测时会将连接失败的实例标记为不健康,但不会将不健康的实例从实例列表中剔除
因此与eureka相比,Nacos与Eureka在临时实例上都是基于心跳模式实现,差别不大,主要是心跳周期不同,eureka是30秒,Nacos是5秒。
另外,Nacos支持永久实例,而Eureka不支持,Eureka只提供了心跳模式的健康监测,而没有主动检测功能。
4. 服务发现对比
Nacos支持定时拉取和订阅推送两种模式;Eureka只支持定时拉取模式,而且两者的定时拉取模式也略有差异
Nacos的拉取模式
Nacos的拉取模式采用自适应间隔+指数退避策略,是一个通过递归提交方式实现的定时任务
-
服务拉取成功 →按正常(自适应)节奏继续
-
服务拉取失败→ 放慢节奏(指数退避)
-
恢复后 → 立即回到正常节奏
//UpdateTask定时任务的对应部分
@Override
public void run() {long delayTime = DEFAULT_DELAY;try {// ... 获取和更新服务信息的逻辑 ...// ... 检查订阅状态和实例列表 ...// 服务拉取成功 → 使用服务端建议的间隔时间,按正常节奏继续delayTime = serviceObj.getCacheMillis();resetFailCount(); // 恢复后 → 立即回到正常节奏状态} catch (Throwable e) {incFailCount(); // 服务拉取失败 → 增加失败计数,准备放慢节奏NAMING_LOGGER.warn("[NA] failed to update serviceName: " + serviceName, e);} finally {// 服务拉取失败 → 放慢节奏(指数退避),给系统喘息时间executor.schedule(this, Math.min(delayTime << failCount, DEFAULT_DELAY * 60), TimeUnit.MILLISECONDS); //递归提交}
}
同时服务端会根据服务变更频率动态调整拉取间隔
- 服务变更频繁 → 服务端返回较短的缓存时间的数据→ 客户端更频繁地拉取
- 服务变更稳定 → 服务端返回较长的缓存时间的数据→ 客户端降低拉取频率
Eureka的拉取模式
而Eureka的拉取模式则是固定间隔+指数退避
-
服务拉取成功 →按正常(固定)节奏继续,这里的正常节奏可以在配置文件中配置
-
服务拉取失败→ 放慢节奏(指数退避)
-
恢复后 → 立即回到正常节奏
Nacos的订阅模式
Nacos的服务端在各处对服务进行变更操作时,会同时发布服务变更事件,监听器监听到后,就会准备数据(同样是调用doSrvIpxt())通过UDP推送给所有已注册的客户端
因此与Eureka相比,Nacos的订阅模式服务状态更新更及时,消费者更容易及时发现服务列表的变化,剔除故障服务。拉取模式也更智能,可以适应不同频率的的服务变更