Nacos 健康检查机制

Nacos注册中心不应该仅仅提供服务注册和发现功能， 还应该保证对服务可用性进行监测， 对不健康的服务和过期的进行标识或剔除， 维护实例的生命周期， 以保证客户端尽可能的查询到可用的服务列表。 因此本文将详细介绍Nacos 注册中心中的健康检查机制。

一、注册中心的健康检查机制

想象⼀下这么⼀个场景， 你所在的地区突然发生地质灾害， 你被掩盖在废墟下面， 搜救队必须要知道你在废墟里面那么才能对你进行施救。 那么有什么方法可以让救援队知道你在废墟下面？ 第⼀种，你在废墟里面大喊 help! help! I am here! ， 让搜救队知道你的位置和健康状态。 第二种， 搜救队使用了他们的专业检查设备， 探测到你正埋在废墟下面。
这两种检查方式其实也可以类比到我们对于服务的探测， 我们需要知道⼀个服务是否还健康。 那么第⼀种方式是客户端主动上报， 告诉服务端自己健康状态， 如果在⼀段时间没有上报， 那么我们就认为服务已经不健康。 第二种， 则是服务端主动向客户端进行探测， 检查客户端是否还被能探测到。

再回到前面的场景中， 如果是你在废墟中大声呼叫救援队并且提供你的位置和健康信息， 那么相比于搜救队用探测设备挨着废墟探测会使探测队的工作量减轻很多， 那么他可以专注于尽快将你救出。
这也好比于注册中心对于服务健康状态的检测， 如果所有服务都需要注册中心去主动探测， 由于服务的数量远大于注册中心的数量， 那么注册中心的任务量将会比较巨大。 所以我们自然而然会想到，那就都采用服务主动上报的方式进行健康检查。 那如果在废墟之下的我们因为身体状况无法呼救，那么搜救队就会放弃搜救了吗？ 当然不是， 搜救队肯定也会对废墟进行全面探测将你救出。 类比到服务健康检查， 如果服务本身就没法主动进行健康上报， 那么这个时候注册中心主动检查健康状态就有用武之地了。
 

在当前主流的注册中心， 对于健康检查机制主要都采用了 TTL（Time To Live） 机制， 即客户端在⼀定时间没有向注册中心发送心跳， 那么注册中心会认为此服务不健康， 进而触发后续的剔除逻辑。
对于主动探测的方式那么根据不同的场景， 需要采用的方式可能会有不同。

二、Nacos 健康检查机制

既然以上两种健康检查机制都有应用的场景， 且适用场景不⼀致， 那么 Nacos 对于健康检查的机
制又是如何抉择的呢？
 在介绍 Nacos 的健康检查机制之前， 我们先回顾⼀下 Nacos 服务有什么特点。 Nacos 提供了两
种服务类型供用户注册实例时选择， 分为临时实例和永久实例。
临时实例只是临时存在于注册中心中， 会在服务下线或不可用时被注册中心剔除， 临时实例会与注册中心保持心跳， 注册中心会在⼀段时间没有收到来自客户端的心跳后会将实例设置为不健康， 然后在⼀段时间后进行剔除。
永久实例在被删除之前会永久的存在于注册中心， 且有可能并不知道注册中心存在， 不会主动向注册中心上报心跳， 那么这个时候就需要注册中心主动进行探活。
从上面的介绍我们可以看出， Nacos 中两种健康探测方式均有被使用， Nacos 中监看检查的整体交互如下如所示。 下面我们会详细介绍 Nacos 中对于两种实例的健康检查机制。

三、临时实例健康检查机制

在 Nacos 中， 用户可以通过两种方式进行临时实例的注册， 通过 Nacos 的 OpenAPI 进行服务注
册或通过 Nacos 提供的 SDK 进行服务注册。
OpenAPI 的注册方式实际是用户根据自身需求调用 Http 接口对服务进行注册， 然后通过 Http 接
口发送心跳到注册中心。 在注册服务的同时会注册⼀个全局的客户端心跳检测的任务。 在服务⼀段时间没有收到来自客户端的心跳后， 该任务会将其标记为不健康， 如果在间隔的时间内还未收到心跳， 那么该任务会将其剔除。
SDK 的注册方式实际是通过 RPC 与注册中心保持连接（Nacos 2.x 版本中， 旧版的还是仍然通过
OpenAPI 的方式） ， 客户端会定时的通过 RPC 连接向 Nacos 注册中心发送心跳， 保持连接的存活。 如果客户端和注册中心的连接断开， 那么注册中心会主动剔除该 client 所注册的服务， 达到下线的效果。 同时 Nacos 注册中心还会在注册中心启动时， 注册⼀个过期客户端清除的定时任务，用于删除那些健康状态超过⼀段时间的客户端。
从上面的特点我们可以发现， 对于不同类型的使用方式， Nacos 对于健康检查的特点实际都是相同的， 都是由客户端向注册中心发送心跳， 注册中心会在连接断开或是心跳过期后将不健康的实例移除。
 

四、永久实例健康检查机制

Nacos 中使用 SDK 对于永久实例的注册实际也是使用 OpenAPI 的方式进行注册， 这样可以保证
 即使是客户端下线后也不会影响永久实例的健康检查。
对于永久实例的的监看检查， Nacos 采用的是注册中心探测机制， 注册中心会在永久服务初始化时根据客户端选择的协议类型注册探活的定时任务。 Nacos 现在内置提供了三种探测的协议， 即
Http、 TCP 以及 MySQL 。 ⼀般而言 Http 和 TCP 已经可以涵盖绝大多数的健康检查场景。
MySQL 主要用于特殊的业务场景， 例如数据库的主备需要通过服务名对外提供访问， 需要确定当前访问数据库是否为主库时， 那么我们此时的健康检查接口， 是⼀个检查数据库是否为主库的 MySQL命令。

由于持久化服务的实例的在被主动删除前⼀直存在的特性， 探活的定时任务会不断探测服务的健康状态， 并且将无法探测成功的实例标记为不健康。 但是有些时候会有这样的场景， 有些服务不希望去校验其健康状态， Nacos 也是提供了对应的白名单配置， 用户可以将服务配置到该白名单， 那么Nacos 会放弃对其进行健康检查， 实例的健康状态也始终为用户传入的健康状态。

五、集群模式下的健康检查机制

⼀个完整的注册中心， 是应该具备高可用的特性， 即我们的注册中心是可以集群部署作为⼀个整体对外提供服务， 当然 Nacos 也支持这样的特性。 不同于单机部署， 集群部署中我们的客户端只和其中⼀个注册中心服务保持链接和请求， 但是我们的服务信息需要注册到所有的服务节点上， 在其他客户端从任意⼀个注册中心服务获取服务列表时始终是所有的服务列表。 在这种情况下， 那么Nacos 在集群模式下又是如何对不是和自己保持心跳连接的服务进行健康检查的呢？

 

对于集群下的服务， Nacos ⼀个服务只会被 Nacos 集群中的⼀个注册中心所负责， 其余节点的服
务信息只是集群副本， 用于订阅者在查询服务列表时， 始终可以获取到全部的服务列表。 临时实例只会对其被负责的注册中心节点发送心跳信息， 注册中心服务节点会对其负责的永久实例进行健康探测， 在获取到健康状态后由当前负责的注册中心节点将健康信息同步到集群中的其他的注册中心。
在 Nacos 中， 服务的注册我们从注册方式维度实际可以分为两大类。 第⼀类通过 SDK RPC 连接进行注册， 客户端会和注册中心保持链接。 第二类， 通过 OpenAPI 进行 IP 和端口注册。
对于第⼀类， 如何寻找到对其负责的注册中心节点呢？ 聪明的你肯定想到了， 只需要和注册中心集群中的任意⼀台节点建立联系， 那么由这个节点负责这个客户端就可以了。 注册中心会在启动时注册⼀个全局的同步任务， 用于将其当前负责的所有节点信息同步到集群中的其他节点， 其他非负责的节点也会创建该客户端的信息， 在非负责的节点上， 连接类型的客户端， 会有⼀个续约时间的概念， 在收到其他节点的同步信息时， 更新续约时间为当前时间， 如果在集群中的其他节点在⼀段时间内没有收到不是自己的负责的节点的同步信息， 那么认为此节点已经不健康， 从而达到对不是自己负责的节点健康状态检查。
 

对于第二类， 方式其实也基本和第⼀类⼀致， OpenAPI 注册的临时实例也是通过同步自身负责的节点到其他节点来更新其他节点的对应的临时实例的心跳时间， 保证其他节点不会删除或者修改此实例的健康状态。 前面我们特别指明了是临时实例而没有说所有实例， 你应该也可能会想到这种方式对于持久化节点会显得多余， 永久实例会在被主动删除前⼀直存在于注册中心， 那么我们健康检查并不会去删除实例， 所以我们只需要在负责的节点永久实例健康状态变更的时候通知到其余的节点即可。

 

六、小结

本文从注册中心场景展开， 详细介绍了 Nacos 注册中心的健康检查机制。 在 Nacos 中， 针对不同类型的服务将会使用不同的健康检查方式进行实例生命周期的维护， 并通过前文提到的⼀致性协议使 Nacos 节点均能够保持实例生命周期的⼀致。 从本文开始， 我们提及了 Nacos 注册中心集群中，实例的健康状态和生命周期需要保持⼀致， 因此在下文中， 我们将开始介绍 Nacos 注册中心是如何使用 Nacos 的⼀致性协议， 来保持数据模型及生命周期⼀致。

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