当前位置 : 主页 > 编程语言 > java >

Spring Cloud Alibaba——Nacos临时实例和持久化实例

来源:互联网 收集:自由互联 发布时间:2023-02-04
一、Nacos两种健康检查模式 1.1、agent上报模式 客户端(注册在nacos server上的微服务实例)健康检查 客户端通过心跳上报方式告知服务端(nacos注册中心)健康状态; 默认心跳间隔5秒; n

一、Nacos两种健康检查模式

1.1、agent上报模式

客户端(注册在nacos server上的微服务实例)健康检查

  • 客户端通过心跳上报方式告知服务端(nacos注册中心)健康状态;

  • 默认心跳间隔5秒;

  • nacos会在超过15秒未收到心跳后将实例设置为不健康状态;

  • 超过30秒将实例删除;

1.2、服务端主动检测

服务端健康检查。

  • nacos主动探知客户端健康状态,默认间隔为20秒;

  • 健康检查失败后实例会被标记为不健康,不会被立即删除。

1.3 临时实例

临时实例通过agent上报模式实现健康检查。

微服务注册为临时实例:

#false为永久实例,true表示临时实例开启,注册为临时实例 spring.cloud.nacos.discovery.ephemeral=true

二、注册实例支持ephemeral字段

Nacos 在 1.0.0版本 instance级别增加了一个ephemeral字段,该字段表示注册的实例是否是临时实例还是持久化实例。如果是临时实例,则不会在 Nacos 服务端持久化存储,需要通过上报心跳的方式进行保活,如果一段时间内没有上报心跳,则会被 Nacos 服务端踢除。在被踢除后如果又开始上报心跳,则会重新将这个实例注册。持久化实例则会持久化到Nacos 服务端,此时即使注册实例的客户端进程不在,这个实例也不会从服务端删除,只会将健康状态设为不健康。

 

同一个服务下可以同时有临时实例和持久化实例,这意味着当这服务的所有实例进程不在时,会有部分实例从服务上摘除,剩下的实例则会保留在服务下。

 

使用实例的ephemeral来判断,ephemeral为true对应的是服务健康检查模式中的 client 模式,为false对应的是 server 模式。

三、增加Server运行模式的设置

Server的运行模式,是指 Nacos Server 可以运行在多种模式下,当前支持三种模式:AP、CP和 MIXED 。这里的运行模式,使用的是CAP理论里的C、A和P概念。基于CAP理论,在分布式系统中,数据的一致性、服务的可用性和网络分区容忍性只能三者选二。一般来说分布式系统需要支持网络分区容忍性,那么就只能在C和A里选择一个作为系统支持的属性。C 的准确定义应该是所有节点在同一时间看到的数据是一致的,而A的定义是所有的请求都会收到响应。

 

Nacos 支持 AP 和 CP 模式的切换,这意味着 Nacos 同时支持两者一致性协议。这样,Nacos能够以一个注册中心管理这些生态的服务。不过在Nacos中,AP模式和CP模式的具体含义,还需要再说明下。  

AP模式为了服务的可用性而减弱了一致性,因此AP模式下只支持注册临时实例。AP 模式是在网络分区下也能够注册实例。在AP模式下也不能编辑服务的元数据等非实例级别的数据,但是允许创建一个默认配置的服务。同时注册实例前不需要进行创建服务的操作,因为这种模式下,服务其实降级成一个简单的字符创标识,不在存储任何属性,会在注册实例的时候自动创建。

 

CP模式下则支持注册持久化实例,此时则是以 Raft 协议为集群运行模式,因此网络分区下不能够注册实例,在网络正常情况下,可以编辑服务级别的配置。该模式下注册实例之前必须先注册服务,如果服务不存在,则会返回错误。

 

MIXED 模式可能是一种比较让人迷惑的模式,这种模式的设立主要是为了能够同时支持临时实例和持久化实例的注册。这种模式下,注册实例之前必须创建服务,在服务已经存在的前提下,临时实例可以在网络分区的情况下进行注册。

四、临时实例和持久化实例区别

临时和持久化的区别主要在健康检查失败后的表现,持久化实例健康检查失败后会被标记成不健康,而临时实例会直接从列表中被删除。  

这个特性比较适合那些需要应对流量突增,而弹性扩容的服务,当流量降下来后这些实例自己销毁自己就可以了,不用再去nacos里手动调用注销实例。持久化以后,可以实时看到健康状态,便于做后续的告警、扩容等一系列处理。

五、Nacos CP/AP模式切换

CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

  • 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)

  • 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)

  • 分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

CAP原则的精髓就是在分布式情况下,要么AP,要么CP,要么AC,但是不存在CAP。如果在某个分布式系统中数据无副本, 那么系统必然满足强一致性条件, 因为只有独一数据,不会出现数据不一致的情况,此时C和P两要素具备,但是如果系统发生了网络分区状况或者宕机,必然导致某些数据不可以访问,此时可用性条件就不能被满足,即在此情况下获得了CP系统,但是CAP不可同时满足。  

Nacos 集群默认支持的是CAP原则中的AP原则,但是也可切换为CP原则,切换命令如下:

curl -X PUT '$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

同时微服务的bootstrap.properties 需配置如下选项指明注册为临时/永久实例 AP模式不支持数据一致性,所以只支持服务注册的临时实例,CP模式支持服务注册的永久实例,满足配置文件的一致性

#false为永久实例,true表示临时实例开启,注册为临时实例 spring.cloud.nacos.discovery.ephemeral=false

参考: https://blog.csdn.net/qq_38826019/article/details/109433231

网友评论