0


谈谈Nacos跟Eureka的区别

Eureka和Nacos都是服务注册与发现的组件,都支持服务注册和服务拉取,都支持服务提供者心跳方式做健康检测,

Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务治理 ,在传统的rpc远程调用框架中,管理每个服务与服务之间依赖关系比较复杂,管理比较复杂,所以需要使用服务治理,管理服务于服务之间依赖关系,可以实现服务调用、负载均衡、容错等,实现服务发现与注册

Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Nacos就是注册中心 + 配置中心的组合Nacos = Eureka+Config +Bus。

Nacos的前四个字母分别为Naming和Configuration的前两个字母,最后的s为Service。

Nacos: Dynamic Naming and Configuration Service

CAP上的区别

C一致性,A高可用,P分区容错性

  • eureka只支撑AP

只要集群中

任意一个实例不

出现问题,Eureka服务就是可用的;即Eureka Client 在向某个 Eureka Server 注册时,如果发现连接失败,则会自动切换至其它节点。Eureka的集群中,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性

  • nacos支撑CP跟AP两种 nacos是依据设置辨认CP或AP形式,假如注册Nacos的client节点注册时是ephemeral=true即为临时节点,那么Naocs集群对这个client节点后果就是AP,反之则是CP,即不是临时节点。
 #false为永久实例,true表示临时实例开启,注册为临时实例
 spring.cloud.nacos.discovery.ephemeral=true

检测机制

Eureka通过定期发送HTTP请求来检查注册的服务是否正常运行。服务提供者会在启动时向Eureka注册自己,并定期发送心跳信息告知Eureka服务依然存活。Eureka服务器也会定期向已注册的服务发送健康检查请求,如果服务没有及时响应或返回异常状态码,Eureka将视为该服务不可用。

Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式

与Eureka类似,Nacos也使用心跳机制来维持与注册的服务的连接。服务提供者会定期发送心跳给Nacos服务器,告知自己的状态。Nacos服务器接收到心跳后,会更新服务的状态信息。如果一个服务连续几个心跳周期没有发送心跳,则Nacos服务器会将该服务标记为不可用。

动检测模式(Active Health Check)来主动检测注册的服务是否可用。在主动检测模式下,Nacos服务器会主动向服务实例发送健康检查请求,并根据返回的结果来判断服务的可用性。

临时实例心跳不正常会被剔除,非临时实例则不会被剔除

连接方式

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

自我保护

Nacos也有自我保护机制(当前健康实例数/当前服务总实例数),值为0-1之间的浮点类型。正常情况下Nacos 只会健康的实例。单在高并发场景,如果只返回健康实例的话,流量洪峰到来可能直接打垮剩下的健康实例,产生雪崩效应。

保护阈值存在的意义在于当服务A健康实例数/总实例数 < 保护阈值时,Nacos会把该服务所有的实例信息(健康的+不健康的)全部提供给消费者,消费者可能访问到不健康的实例,请求失败,但这样远比造成雪崩要好。牺牲了请求,保证了整个系统的可用。

Eureka保护模式主要用与一组EurekaClient客户端和EurekaServer之间存在网络分区场景下的保护。一旦进入保护模式,EurekaServer将会保护其注册表中的服务,不再删除服务注册表中的数据,也就是不会注销任何微服务。

自我保护机制是一种针对网络异常波动的安全保护措施,可以使Eureka集群更加的健壮、稳定的运行。

标签: eureka 云原生 spring

本文转载自: https://blog.csdn.net/m0_62436868/article/details/135080594
版权归原作者 一个风轻云淡 所有, 如有侵权,请联系我们删除。

“谈谈Nacos跟Eureka的区别”的评论:

还没有评论