本篇文章Nacos核心逻辑篇,给大家讲解一下「临时实例」与「持久化实例」的区别及运用场景。
Nacos的临时实例与持久化实例
在Nacos Client进行实例注册时,我们知道是通过Instance对象来携带实例的基本信息的。在Instance中有一个ephemeral字段,用来表示该实例是临时实例,还是持久化实例。
public class Instance implements Serializable {
/**
* If instance is ephemeral.
*
* @since 1.0.0
*/
private boolean ephemeral = true;
// 省略其他
}
从源码可以看出ephemeral字段是1.0.0版本新增的,用来表示注册的实例是否是临时实例还是持久化实例。
目前,无论是Nacos 1.x版本,还是2.x版本,ephemeral的默认值都是true。在1.x版本中服务注册默认采用http协议,2.x版本默认采用grpc协议,但这都未影响到ephemeral字段的默认值。
也就是说,一直以来,Nacos实例默认都是以临时实例的形式进行注册的。
当然,也是可以通过application的配置来改变这里默认值的。比如:
# false为永久实例,true表示临时实例
spring.cloud.nacos.discovery.ephemeral=false
上面是基于Spring Cloud进行配置,false为永久实例,true表示临时实例,默认为true。
临时实例与持久化实例的区别
临时实例与持久化实例的区别主要体现在服务器对该实例的处理上。
临时实例向Nacos注册,Nacos不会对其进行持久化存储,只能通过心跳方式保活。默认模式是:客户端心跳上报Nacos实例健康状态,默认间隔5秒,Nacos在15秒内未收到该实例的心跳,则会设置为不健康状态,超过30秒则将实例删除。
持久化实例向Nacos注册,Nacos会对其进行持久化处理。当该实例不存在时,Nacos只会将其健康状态设置为不健康,但并不会对将其从服务端删除。
另外,可以使用实例的ephemeral来判断健康检查模式,ephemeral为true对应的是client模式(客户端心跳),为false对应的是server模式(服务端检查)。
为什么要设计两种模式?
上面说了两种模式的不同和处理上的区别,那么Nacos为什么设计两种模式,它们是为了应对什么样的场景而存在呢?
对于临时实例,健康检查失败,则直接可以从列表中删除。这种特性就比较适合那些需要应对流量突增的场景,服务可以进行弹性扩容。当流量过去之后,服务停掉即可自动注销了。
对于持久化实例,健康检查失败,会被标记成不健康状态。它的好处是运维可以实时看到实例的健康状态,便于后续的警告、扩容等一些列措施。
除了上述场景之外,持久化实例还有另外一个场景用的到,那就是保护阈值。
Nacos的保护阈值
关于保护阈值,在前面的文章中专门写到过。
Nacos中可以针对具体的实例设置一个保护阈值,值为0-1之间的浮点类型。本质上,保护阈值是⼀个⽐例值(当前服务健康实例数/当前服务总实例数)。
⼀般情况下,服务消费者要从Nacos获取可⽤实例有健康/不健康状态之分。Nacos在返回实例时,只会返回健康实例。
但在⾼并发、⼤流量场景会存在⼀定的问题。比如,服务A有100个实例,98个实例都处于不健康状态,如果Nacos只返回这两个健康实例的话。流量洪峰的到来可能会直接打垮这两个服务,进一步产生雪崩效应。
保护阈值存在的意义在于当服务A健康实例数/总实例数 < 保护阈值时,说明健康的实例不多了,保护阈值会被触发(状态true)。
Nacos会把该服务所有的实例信息(健康的+不健康的)全部提供给消费者,消费者可能访问到不健康的实例,请求失败,但这样也⽐造成雪崩要好。牺牲了⼀些请求,保证了整个系统的可⽤。
这里我们看到了不健康实例的另外一个作用:防止产生雪崩。
那么,如果所有的实例都是临时实例,当雪崩场景发生时,Nacos的阈值保护机制是不是就没有足够的(包含不健康实例)实例返回了?如果有一部分实例是持久化实例,即便它们已经挂掉,状态为不健康的,但当触发阈值保护时,还是可以起到分流的作用。
小结
关于Nacos临时实例与持久化实例就聊这么多了。如果想更深入了解,其实可以读一下源码。由于基于gRPC的实现过于复杂,可读性不够强,如果想阅读,建议阅读基于Http的实现。
标签:持久,阈值,傻傻,ephemeral,nacos,Nacos,实例,健康,分不清 From: https://www.cnblogs.com/yaochunhui/p/17076901.html