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 理论：
- 一致性（C）：所有的节点提供的服务必须都是保持一致的。
- 可用性（A）：就算某台节服务没同步，无法提供这个服务，也要允许返回错误信息。
- 分区容错性（P）：某台服务器宕机，也能有其他的服务顶上。
C A 两个是互斥，所以只能在 CP 和 AP 中做选择。
在来看临时实例，如果宕机，则从服务列表中删除，这个保持了每个节点的一致性，确保每个节点提供的服务都是一致的，所以 Nacos 中，如果是临时实例，保证的是 CP。
再来看永久实例，如果宕机，也不从服务列表中删除，就算某个节点提供不了服务，也要允许返回错误的信息，所以 Nacos 中，如果是非临时实例(永久实例)，保证的是 AP。
所以在 Nacos 中，AP 和 CP 可以混合存在。
如何为 Nacos 配置一个永久实例呢？
直接在 .yml 进行配置就行：
server:
port: 9090
spring:
application:
name: waiter-service
cloud:
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 目录。
