学习不用那么功利，二师兄带你从更高维度轻松阅读源码～
本篇文章Nacos核心逻辑篇，给大家讲解一下「临时实例」与「持久化实例」的区别及运用场景。
Nacos的临时实例与持久化实例
在Nacos Client进行实例注册时，我们知道是通过Instance对象来携带实例的基本信息的。在Instance中有一个ephemeral字段，用来表示该实例是临时实例，还是持久化实例。
代码语言：javascript复制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的配置来改变这里默认值的。比如：
代码语言：javascript复制# 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的实现。
博主简介：《SpringBoot技术内幕》技术图书作者，酷爱钻研技术，写技术干货文章。
