Nacos做爲註冊中心——健康檢測機制

Zookeeper 和 Eureka的機制

Zookeeper 和 Eureka 都實現了一種 TTL 的機制，就是若是客戶端在必定時間內沒有向註冊中心發送心跳，則會將這個客戶端摘除。Eureka 作的更好的一點在於它容許在註冊服務的時候，自定義檢查自身狀態的健康檢查方法。這在服務實例可以保持心跳上報的場景下，是一種比較好的體驗。

Nacos的機制

在 Dubbo 和 SpringCloud 這兩大致系內，也被培養成用戶心智上的默認行爲。Nacos 也支持這種 TTL 機制，不過這與 ConfigServer 在阿里巴巴內部的機制又有一些區別。

1.心跳檢測

Nacos 目前支持臨時實例使用心跳上報方式維持活性，發送心跳的週期默認是 5 秒，Nacos 服務端會在 15 秒沒收到心跳後將實例設置爲不健康，在 30 秒沒收到心跳時將這個臨時實例摘除。

不過正如前文所說，有一些服務沒法上報心跳，可是能夠提供一個檢測接口，由外部去探測。這樣的服務也是普遍存在的，並且以咱們的經驗，這些服務對服務發現和負載均衡的需求一樣強烈。

Nacos 支持傳輸層（PIND 或 TCP）和應用層（如 HTTP、Redis、MySQL、用戶自定義）的監控檢查

2.傳輸層（PIND 或 TCP）檢測

服務端健康檢查最多見的方式是 TCP 端口探測和 HTTP 接口返回碼探測，這兩種探測方式由於其協議的通用性能夠支持絕大多數的健康檢查場景。

3.應用層（如 HTTP、Redis、MySQL、用戶自定義）的檢測

在其餘一些特殊的場景中，可能還須要執行特殊的接口才能判斷服務是否可用。例如部署了數據庫的主備，數據庫的主備可能會在某些狀況下切換，須要經過服務名對外提供訪問，保證當前訪問的庫是主庫。此時的健康檢查接口，可能就是一個檢查數據庫是不是主庫的 MYSQL 命令了。

客戶端健康檢查和服務端健康檢查

客戶端健康檢查和服務端健康檢查有一些不一樣的關注點。客戶端健康檢查主要關注客戶端上報心跳的方式、服務端摘除不健康客戶端的機制。而服務端健康檢查，則關注探測客戶端的方式、靈敏度及設置客戶端健康狀態的機制。

從實現複雜性來講，服務端探測確定是要更加複雜的，由於須要服務端根據註冊服務配置的健康檢查方式，去執行相應的接口，判斷相應的返回結果，並作好重試機制和線程池的管理。這與客戶端探測，只須要等待心跳，而後刷新 TTL 是不同的。同時服務端健康檢查沒法摘除不健康實例，這意味着只要註冊過的服務實例，若是不調用接口主動註銷，這些服務實例都須要去維持健康檢查的探測任務，而客戶端則能夠隨時摘除不健康實例，減輕服務端的壓力。

​

Nacos 的健康檢查

Nacos 既支持客戶端的健康檢查，也支持服務端的健康檢查，同一個服務能夠切換健康檢查模式。咱們認爲這種健康檢查方式的多樣性很是重要，這樣能夠支持各類類型的服務，讓這些服務均可以使用到 Nacos 的負載均衡能力。Nacos 下一步要作的是實現健康檢查方式的用戶擴展機制，無論是服務端探測仍是客戶端探測。這樣能夠支持用戶傳入一條業務語義的請求，而後由 Nacos 去執行，作到健康檢查的定製。