Nacos架构与原理 - 健康检查机制

注册中心的健康检查机制

想象发生地质灾害,被掩埋在废墟下,搜救队需定位才能施救。两种方法:

• 大喊求救,告知位置与健康状况,让搜救队知晓
• 搜救队使用专业设备探测到被埋者位置

这两种方法可类比为服务探测方式:

• 客户端主动上报,告知服务端自己健康状态。若一段时间无上报,判定服务不健康。
• 服务端主动探测客户端,检查其是否可探测。

总之,实际案例比喻说明两种服务健康检查方式:

• 客户端主动上报状态,无上报判定异常
• 服务端主动探测客户端

前者依赖客户端自我报告,较易失效或延迟发现问题。后者由服务端定期检查,可更快准确发现客户端异常。但也增加服务端负载。

两种方式各有优劣,实际选择根据系统需求定制或混合使用。要点是确保服务健康状态被有效监控,问题能够及时发现。

可通过此例子理解常见的服务健康检查机制,两种方式的原理、特征与适用场景。在设计服务监控时,需考虑方式的优劣选择与定制需求,从而实现最优监控效果。

• 比喻场景中,主动呼救并报告位置与状态,可减轻搜救队工作量,专注救出。 • 类比服务健康检查,所有服务需要注册中心主动探测,任务量太大,考虑服务主动上报检查。 • 但如果呼救无力,搜救队仍会全面探测救出。 • 类比为服务本身无法主动上报,注册中心主动检查有用。 • 总之,主动上报模式减轻注册中心负载,但服务端无法主动上报时,注册中心主动检查必要。 • 前者适用于大多数正常服务,后者为少数异常服务提供保障。两种方式结合,可实现服务健康有效监控。 • 比喻清晰表达两种方式的作用与适用场景。正常情况下主动上报为主,异常情况由主动检查补充。注意两种方式的配合使用,实现完备监控。

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

对于主动探测的方式那么根据不同的场景，需要采用的方式可能会有不同

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 中，服务的注册我们从注册方式维度实际可以分为两大类。第⼀类通过 SDK RPC 连接进行注册，客户端会和注册中心保持链接。第二类，通过 OpenAPI 进行 IP 和端口注册。

第一类SDK方式

只需要和注册中心集群中的任意⼀台节点建立联系，那么由这个节点负责这个客户端就可以了。注册中心会在启动时注册⼀个全局的同步任务，用于将其当前负责的所有节点信息同步到集群中的其他节点，其他非负责的节点也会创建该客户端的信息，在非负责的节点上，连接类型的客户端，会有⼀个续约时间的概念，在收到其他节点的同步信息时，更新续约时间为当前时间，如果在集群中的其他节点在⼀段时间内没有收到不是自己的负责的节点的同步信息，那么认为此节点已经不健康，从而达到对不是自己负责的节点健康状态检查。

第二类OPENAPI方式

OpenAPI 注册的临时实例也是通过同步自身负责的节点到其他节点来更新其他节点的对应的临时实例的心跳时间，保证其他节点不会删除或者修改此实例的健康状态。

前面我们特别指明了是临时实例而没有说所有实例，你应该也可能会想到这种方式对于持久化节点会显得多余，永久实例会在被主动删除前⼀直存在于注册中心，那么我们健康检查并不会去删除实例，所以我们只需要在负责的节点永久实例健康状态变更的时候通知到其余的节点即可