程露 Nacos committer

在上文中，我們介紹了 Nacos 注冊中心中的服務(wù)數(shù)據(jù)模型，說明了服務(wù)、實例以及集群的內(nèi)容，關(guān)系及它們的生命周期。期間健康檢查是一個被反復(fù)提及的詞語，這是由于注冊中心不應(yīng)該僅僅提供服務(wù)注冊和發(fā)現(xiàn)功能，還應(yīng)該保證對服務(wù)可用性進行監(jiān)測，對不健康和過期的服務(wù)實例進行標識或剔除，維護實例的生命周期，以保證客戶端盡可能的查詢到可用的服務(wù)列表。因此本文將詳細介紹 Nacos 注冊中心中的健康檢查機制。

注冊中心的健康檢查機制

想象一下這么一個場景，你所在的地區(qū)突然發(fā)生地質(zhì)災(zāi)害，你被掩蓋在廢墟下面，搜救隊必須要知道你在廢墟里面那么才能對你進行施救。那么有什么方法可以讓救援隊知道你在廢墟下面？第一種，你在廢墟里面大喊help! help! I am here! ，讓搜救隊知道你的位置和健康狀態(tài)。第二種，搜救隊使用了他們的專業(yè)檢查設(shè)備，探測到你正埋在廢墟下面。
這兩種檢查方式其實也可以類比到我們對于服務(wù)的探測，我們需要知道一個服務(wù)是否還健康。那么第一種方式是客戶端主動上報，告訴服務(wù)端自己健康狀態(tài)，如果在一段時間沒有上報，那么我們就認為服務(wù)已經(jīng)不健康。第二種，則是服務(wù)端主動向客戶端進行探測，檢查客戶端是否還被能探測到。

再回到前面的場景中，如果是你在廢墟中大聲呼叫救援隊并且提供你的位置和健康信息，那么相比于搜救隊用探測設(shè)備挨著廢墟探測會使探測隊的工作量減輕很多，那么他可以專注于盡快將你救出。這也好比于注冊中心對于服務(wù)健康狀態(tài)的檢測，如果所有服務(wù)都需要注冊中心去主動探測，由于服務(wù)的數(shù)量遠大于注冊中心的數(shù)量，那么注冊中心的任務(wù)量將會比較巨大。所以我們自然而然會想到，那就都采用服務(wù)主動上報的方式進行健康檢查。那如果在廢墟之下的我們因為身體狀況無法呼救，那么搜救隊就會放棄搜救了嗎？當(dāng)然不是，搜救隊肯定也會對廢墟進行全面探測將你救出。類比到服務(wù)健康檢查，如果服務(wù)本身就沒法主動進行健康上報，那么這個時候注冊中心主動檢查健康狀態(tài)就有用武之地了。

在當(dāng)前主流的注冊中心，對于健康檢查機制主要都采用了 TTL（Time To Live）機制，即客戶端在一定時間沒有向注冊中心發(fā)送心跳，那么注冊中心會認為此服務(wù)不健康，進而觸發(fā)后續(xù)的剔除邏輯。對于主動探測的方式那么根據(jù)不同的場景，需要采用的方式可能會有不同。

既然以上兩種健康檢查機制都有應(yīng)用的場景，且適用場景不一致，那么 Nacos 對于健康檢查的機制又是如何抉擇的呢？
在介紹 Nacos 的健康檢查機制之前，我們先回顧一下 Nacos 服務(wù)有什么特點。Nacos 提供了兩種服務(wù)類型供用戶注冊實例時選擇，分為非持久化實例（又稱臨時實例）和持久化實例（又稱永久實例）。
臨時實例只是臨時存在于注冊中心中，會在服務(wù)下線或不可用時被注冊中心剔除，臨時實例會與注冊中心保持心跳，注冊中心會在一段時間沒有收到來自客戶端的心跳后會將實例設(shè)置為不健康，然后在一段時間后進行剔除。
永久實例在被刪除之前會永久的存在于注冊中心，且有可能并不知道注冊中心存在，不會主動向注冊中心上報心跳，那么這個時候就需要注冊中心主動進行探活。
從上面的介紹我們可以看出，Nacos 中兩種健康探測方式均有被使用，Nacos 中健康檢查的整體交互如下如所示。下面我們會詳細介紹 Nacos 中對于兩種實例的健康檢查機制。

臨時實例健康檢查機制

在 Nacos 中，用戶可以通過兩種方式進行臨時實例的注冊，通過 Nacos 的 OpenAPI 進行服務(wù)注冊或通過 Nacos 提供的 SDK 進行服務(wù)注冊。
OpenAPI 的注冊方式實際是用戶根據(jù)自身需求調(diào)用 Http 接口對服務(wù)進行注冊，然后通過 Http 接口發(fā)送心跳到注冊中心。在注冊服務(wù)的同時會注冊一個全局的客戶端心跳檢測的任務(wù)。在服務(wù)一段時間沒有收到來自客戶端的心跳后，該任務(wù)會將其標記為不健康，如果在間隔的時間內(nèi)還未收到心跳，那么該任務(wù)會將其剔除。
SDK 的注冊方式實際是通過 RPC 與注冊中心保持連接（Nacos 2.x 版本中，舊版的還是仍然通過 OpenAPI 的方式），客戶端會定時的通過 RPC 連接向 Nacos 注冊中心發(fā)送心跳，保持連接的存活。如果客戶端和注冊中心的連接斷開，那么注冊中心會主動剔除該 client 所注冊的服務(wù)，達到下線的效果。同時 Nacos 注冊中心還會在注冊中心啟動時，注冊一個過期客戶端清除的定時任務(wù)，用于刪除那些健康狀態(tài)超過一段時間的客戶端。
從上面的特點我們可以發(fā)現(xiàn)，對于不同類型的使用方式，Nacos 對于健康檢查的特點實際都是相同的，都是由客戶端向注冊中心發(fā)送心跳，注冊中心會在連接斷開或是心跳過期后將不健康的實例移除。

永久實例健康檢查機制

Nacos 中使用 SDK 對于永久實例的注冊實際也是使用 OpenAPI 的方式進行注冊，這樣可以保證即使是客戶端下線后也不會影響永久實例的健康檢查。
對于永久實例的的健康檢查，Nacos 采用的是注冊中心探測機制，注冊中心會在持久化服務(wù)初始化時根據(jù)客戶端選擇的協(xié)議類型注冊探活的定時任務(wù)。Nacos 現(xiàn)在內(nèi)置提供了三種探測的協(xié)議，即 Http、TCP 以及 MySQL 。一般而言 Http 和 TCP 已經(jīng)可以涵蓋絕大多數(shù)的健康檢查場景。MySQL 主要用于特殊的業(yè)務(wù)場景，例如數(shù)據(jù)庫的主備需要通過服務(wù)名對外提供訪問，需要確定當(dāng)前訪問數(shù)據(jù)庫是否為主庫時，那么我們此時的健康檢查接口，是一個檢查數(shù)據(jù)庫是否為主庫的 MySQL 命令。

由于持久化服務(wù)的實例的在被主動刪除前一直存在的特性，探活的定時任務(wù)會不斷探測服務(wù)的健康狀態(tài)，并且將無法探測成功的實例標記為不健康。但是有些時候會有這樣的場景，有些服務(wù)不希望去校驗其健康狀態(tài)，Nacos也是提供了對應(yīng)的白名單配置，用戶可以將服務(wù)配置到該白名單，那么 Nacos 會放棄對其進行健康檢查，實例的健康狀態(tài)也始終為用戶傳入的健康狀態(tài)。

集群模式下的健康檢查機制

一個完整的注冊中心，是應(yīng)該具備高可用的特性，即我們的注冊中心是可以集群部署作為一個整體對外提供服務(wù)，當(dāng)然 Nacos 也支持這樣的特性。不同于單機部署，集群部署中我們的客戶端只和其中一個注冊中心服務(wù)保持鏈接和請求，但是我們的服務(wù)信息需要注冊到所有的服務(wù)節(jié)點上，在其他客戶端從任意一個注冊中心服務(wù)獲取服務(wù)列表時始終是所有的服務(wù)列表。在這種情況下，那么 Nacos 在集群模式下又是如何對不是和自己保持心跳連接的服務(wù)進行健康檢查的呢？

對于集群下的服務(wù)，Nacos 一個服務(wù)只會被 Nacos 集群中的一個注冊中心所負責(zé)，其余節(jié)點的服務(wù)信息只是集群副本，用于訂閱者在查詢服務(wù)列表時，始終可以獲取到全部的服務(wù)列表。臨時實例只會對其被負責(zé)的注冊中心節(jié)點發(fā)送心跳信息，注冊中心服務(wù)節(jié)點會對其負責(zé)的永久實例進行健康探測，在獲取到健康狀態(tài)后由當(dāng)前負責(zé)的注冊中心節(jié)點將健康信息同步到集群中的其他的注冊中心。
在Nacos中，服務(wù)的注冊我們從注冊方式維度實際可以分為兩大類。第一類通過 SDK RPC 連接進行注冊，客戶端會和注冊中心保持鏈接。第二類，通過 OpenAPI 進行 IP 和端口注冊。
對于第一類，如何尋找到對其負責(zé)的注冊中心節(jié)點呢？聰明的你肯定想到了，只需要和注冊中心集群中的任意一臺節(jié)點建立聯(lián)系，那么由這個節(jié)點負責(zé)這個客戶端就可以了。注冊中心會在啟動時注冊一個全局的同步任務(wù)，用于將其當(dāng)前負責(zé)的所有節(jié)點信息同步到集群中的其他節(jié)點，其他非負責(zé)的節(jié)點也會創(chuàng)建該客戶端的信息，在非負責(zé)的節(jié)點上，連接類型的客戶端，會有一個續(xù)約時間的概念，在收到其他節(jié)點的同步信息時，更新續(xù)約時間為當(dāng)前時間，如果在集群中的其他節(jié)點在一段時間內(nèi)沒有收到不是自己的負責(zé)的節(jié)點的同步信息，那么認為此節(jié)點已經(jīng)不健康，從而達到對不是自己負責(zé)的節(jié)點健康狀態(tài)檢查。

對于第二類，方式其實也基本和第一類一致，OpenAPI 注冊的臨時實例也是通過同步自身負責(zé)的節(jié)點到其他節(jié)點來更新其他節(jié)點的對應(yīng)的臨時實例的心跳時間，保證其他節(jié)點不會刪除或者修改此實例的健康狀態(tài)。前面我們特別特別指明了是臨時實例而沒有說所有實例，你應(yīng)該也可能會想到這種方式對于持久化節(jié)點的會顯得多余，永久實例會在被主動刪除前一直存在于注冊中心，那么我們健康檢查并不會去刪除實例，所以我們只需要在負責(zé)的節(jié)點永久實例健康狀態(tài)變更的時候通知到其余的節(jié)點即可。

小結(jié)

本文從注冊中心場景展開，詳細介紹了 Nacos 注冊中心的健康檢查機制。在 Nacos 中，針對不同類型的服務(wù)將會使用不同的健康檢查方式進行實例生命周期的維護，并通過前文提到的一致性協(xié)議使 Nacos 節(jié)點均能夠保持實例生命周期的一致。從本文開始，我們提及了 Nacos 注冊中心集群中，實例的健康狀態(tài)和生命周期需要保持一致，因此在下文中，我們將開始介紹 Nacos 注冊中心是如何使用 Nacos 的一致性協(xié)議，來保持數(shù)據(jù)模型及生命周期一致。

相關(guān)知識

幼兒健康檢查制度
兒童健康檢查工作制度(12篇)
一體化身體健康檢查健康小屋體檢一體機
托幼機構(gòu)健康檢查管理PPT課件.ppt
幼兒園健康檢查制度（精選12篇）
哪些醫(yī)療機構(gòu)可承擔(dān)職業(yè)健康檢查？
幼兒園環(huán)境衛(wèi)生健康檢查制度
托幼機構(gòu)工作人員健康檢查表
職業(yè)健康檢查與獎懲制度（簡單版21篇）
健康檢測一體機

網(wǎng)址: Nacos 健康檢查機制 http://www.u1s5d6.cn/newsview139835.html