09 | 健康檢測：這個節點掛了，為啥還要瘋狂發請求？

服務調用方在每次調用服務提供方的服務時，RPC框架會根據路由和負載均衡演算法選擇一個具體的IP地址，為了保證請求成功，我們需要確保每次選擇出來的IP對應的連接是健康的。

調用方和集群節點之間的網路狀況是瞬息萬變的，兩者之間可能會出現閃斷或者網路設備損壞的情況，為瞭解決這個問題，我們的終極解決方案就是讓調用方實時感知到節點的變化。

業內經常用來檢測服務節點是否可用的方法是用心跳機制。心跳機制就是服務調用方每隔一段時間就問一下服務提供方，“兄弟，你還好嗎？”，然後服務提供方誠實地告訴調用方它目前的狀態。

服務提供方的狀態一般會有三種情況：

1. 健康狀態：建立連接成功，並且心跳探活也一直成功。
2. 亞健康狀態：建立連接成功，但是心跳請求連續失敗。
3. 死亡狀態：建立連接失敗。

上述三種狀態是可以變轉變的。

一個節點從健康狀態過渡到亞健康狀態的前提是連續“心跳失次數必須達到某個閾值。

只關心服務節點網路穩定，會有2個問題：

1. 調用方每個介面的調用頻次不一樣，有的介面可能1秒內調用上百次，有的介面可能半個小時才會被調用一次，所以我們不能簡單的把失敗總次數當做判斷條件。
2. 服務的藉口響應時間也不一樣，有的介面可能1ms，有的可能是10s，我們不能使用TPS來作為談判條件。

我們可以使用”可用率“，它的計算方式是某一個時間視窗內介面調用的成功次數的百分比。當可用率低於某個比例就認為這個節點存在問題，需要把它轉移到亞健康列表，這樣既考慮了高低頻的調用介面，也兼顧了介面響應時間不同的問題。

我們在部署時，需要註意將檢測程式部署到多個機器裡面，分佈在不同的機架，甚至不同的機房。