【SpringCloud】Nacos健康检查

5.6 Nacos 健康检查

Nacos 作为注册中心，肯定是需要感知到注册的服务是否是健康的， 这样才能为服务调用方提供良好的服务，如果哪个注册的服务挂了，但是 Nacos 没感知到，那可就有问题了。

5.6.1 健康检查机制

Nacos 中提供了两种健康检查机制：

• 客户端主动上报
  • 客户端通过心跳的方式告知 Nacos注册中心它的健康状态，默认心跳间隔五秒。
  • Nacos 会在超过 15 秒未收到心跳后，将实例设置成不健康状态，超过 30 秒会将改实例删除。
• 反向探测
  • Nacos 主动探知客户端的健康状态，默认间隔 20 秒探知一次。
  • Naocs 探知发现该实例不健康后，会将改实例标记成为不健康状态，但不会被删除。

但是 Nacos 这两种健康检查机制，咱们是不能自定义的，它由服务实例的类型决定的。

5.6.2 服务实例类型

Nacos 服务在注册的时候，会将注册的服务节点分为两种类型：

临时实例： 如果实例宕机超过一定时间，会从服务列表中删除，默认的类型。

非临时实例： 如果实例宕机了，不会从服务列表中删除，也叫永久实例。

如果注册的服务是临时实例，则 Nacos 采用的是客户端主动上报的机制。

如果注册的服务是永久实例，则 Nacos 采用的是注册中心反向探测的机制。‘

所以其实 Nacos 有了这两种实例类型，咱们看看前面讲的 CAP 理论：

1. 一致性（C）：所有的节点提供的服务必须都是保持一致的。
2. 可用性（A）：就算某台节服务没同步，无法提供这个服务，也要允许返回错误信息。
3. 分区容错性（P）：某台服务器宕机，也能有其他的服务顶上。

C A 两个是互斥，所以只能在 CP 和 AP 中做选择。

在来看临时实例，如果宕机，则从服务列表中删除，这个保持了每个节点的一致性，确保每个节点提供的服务都是一致的，所以 Nacos 中，如果是临时实例，保证的是 CP。

再来看永久实例，如果宕机，也不从服务列表中删除，就算某个节点提供不了服务，也要允许返回错误的信息，所以 Nacos 中，如果是非临时实例(永久实例)，保证的是 AP。

所以在 Nacos 中，AP 和 CP 可以混合存在。

如何为 Nacos 配置一个永久实例呢？

直接在 .yml 进行配置就行：

server:port: 9090
spring:application:name: waiter-servicecloud:nacos:discovery:server-addr: 127.0.0.1:8848 # 配置 nacos 地址cluster-name: SH # 配置集群名称ephemeral: false # 设置实例为非临时实例

这个 ephemeral 配置项，默认是 true，也是就临时实例，改成 false 就将这个实例设置成 非临时实例了。

这样一来，就算咱们的 waiter-service 9090 宕机了，Nacos 注册中心 也不会删除它，咱们 cook-service 也能在服务列表中发现他，虽然调用 waiter-service 9090 可能会返回错误信息，但至少也是保证了有节点可以用。

设置成非临时实例咱们就不演示了，配置完后，重新启动项目，去 Nacos 管理面板中查看，在临时实例那一栏，就会显示成 false，然后终止项目，会发现实例还在上面，接着进行测试就够了。

但是这里有个注意点！

Nacos 服务实例类型不允许改变！！！

当服务注册后，Nacos 会记录每个服务实例的IP和端口号，当发现IP和端口号都没有发生变化时，Nacos不允许⼀个服务实例类型发生变化，比如从临时实例变为非临时实例，或者从非临时实例，变成临时实例。

如果发现修改实例类型重新启动项目后报错，可以参考下面两个步骤：

① 停掉 Nacos 服务。

② 删除 Nacos 目录下/data/protocol/raft 目录。