nacos的cp和ap原则,服务健康检查

CP和AP

CAP原则：cap理论是针对分布式数据库而言的，它是指在一个分布式系统中，一致性（Consistency，C）、可用性（Availability，A）、分区容错性（Partition Tolerance, P）三者不可兼得。

nacos支持AP(可用性 | 分区容错性) 和 CP(一致性 | 分区容错性)两种  默认是AP

如果注册Nacos的client节点注册时ephemeral=true，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现；而注册Nacos的client节点注册时ephemeral=false，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。根据client注册时的属性，AP，CP同时混合存在，只是对不同的client节点效果不同。Nacos可以很好的解决不同场景的业务需求。

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

 服务的健康检查

分为两种模式：1 agent上报模式，2 服务端主动检测

1、 agent上报模式
客户端（注册在nacos上的其它微服务实例）健康检查。

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

默认心跳间隔5秒；

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

超过30秒将实例删除；

2 、服务端主动检测
服务端健康检查。

nacos主动探知客户端健康状态，默认间隔为20秒；

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

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

为什么会有两种健康检查模式呢？
对于临时实例，健康检查失败，则直接可以从列表中删除。这种特性就比较适合那些需要应对流量突增的场景，服务可以进行弹性扩容。当流量过去之后，服务停掉即可自动注销了。

对于持久化实例，健康检查失败，会被标记成不健康状态。它的好处是运维可以实时看到实例的健康状态，便于后续的警告、扩容等一些列措施。

Nacos的保护阈值
Nacos中可以针对具体的实例设置一个保护阈值，值为0-1之间的浮点类型。本质上，保护阈值是⼀个⽐例值（当前服务健康实例数/当前服务总实例数）。

⼀般情况下，服务消费者要从Nacos获取可用实例有健康/不健康状态之分。Nacos在返回实例时，只会返回健康实例。

但在高并发、大流量场景会存在⼀定的问题。比如，服务A有100个实例，98个实例都处于不健康状态，如果Nacos只返回这两个健康实例的话。流量洪峰的到来可能会直接打垮这两个服务，进一步产生雪崩效应。

保护阈值存在的意义在于当服务A健康实例数/总实例数 < 保护阈值时，说明健康的实例不多了，保护阈值会被触发（状态true）。

Nacos会把该服务所有的实例信息（健康的+不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样也⽐造成雪崩要好。牺牲了⼀些请求，保证了整个系统的可⽤。

这里我们看到了不健康实例的另外一个作用：防止产生雪崩。

那么，如果所有的实例都是临时实例，当雪崩场景发生时，Nacos的阈值保护机制是不是就没有足够的（包含不健康实例）实例返回了？如果有一部分实例是持久化实例，即便它们已经挂掉，状态为不健康的，但当触发阈值保护时，还是可以起到分流的作用。