### 健康檢查 主動健康檢查是以每個上游服務群集進行配置。如服務發現部分所述，主動健康檢查與SDS服務發現配合使用。但是，即使使用其他服務發現方式，也有相應需要進行主動健康檢查的情況。Envoy支持三種不同類型的健康檢查以及相應設置（檢查時間間隔，因故障標記主機不健康，成功之后標記主機健康等）： - HTTP：HTTP健康檢查期間，Envoy將向上游主機發送HTTP請求。如果主機健康，預計會有200返回碼。如果上游主機想立即通知下游主機不再向其轉發流量，則返回503返回碼。 - L3/L4：在L3/L4健康檢查期間，Envoy會向上游主機發送一個可配置的報文。如果主機期望被認為是健康的，則在響應中回應相應的報文。Envoy也支持只連接L3/L4健康檢查。 - Redis：Envoy將發送一個Redis PING命令，并期待一個PONG響應。上游Redis服務器可以使用PONG以外的任何其他響應，來立即觸發的健康檢查失敗。 #### 被動健康檢查 Envoy還支持通過檢測異常值，來進行被動健康檢查。 #### 連接池交互 瀏覽[此處](Connectionpooling.md)獲取更多信息。 #### HTTP健康檢查過濾器 當部署Envoy網格并在集群之間進行主動健康檢查時，會生成大量健康檢查的流量。Envoy提供一個可配置HTTP健康檢查過濾器，并安裝在HTTP監聽器中。這個過濾器有幾種不同的操作模式： - **不通過**：在此模式下，健康檢查請求永遠不會傳遞到本地服務。Envoy將根據服務器當前的耗盡狀態，以200或503響應。 - **通過**：在這種模式下，Envoy會將每個健康檢查請求傳遞給本地服務。預計該服務將返回200或503取決于其健康狀況。 - **通過緩存**：在這種模式下，Envoy會將健康檢查請求傳遞給本地服務，但是會將結果緩存一段時間。隨后在緩存有效時間內，進行的健康檢查都會從緩存獲取結果。當緩存超時后，下一個健康檢查請求將被傳遞給本地服務。在使用較大的Envoy網格時，這是推薦的操作模式。Envoy使用持久性連接進行健康檢查，健康檢查請求對Envoy本身的成本很低。因此，這種操作模式產生了每個上游主機的健康狀態的最終一致的視圖，而沒有使大量的健康檢查請求壓倒本地服務。 進一步閱讀： - [健康檢查過濾器配置]() - [健康檢查失敗管理端口]()(/healthcheck/fail) - [健康檢查成功管理端口]()(/healthcheck/ok) #### 主動健康檢查（快速失敗） 當使用主動健康檢查和被動健康檢查（異常檢測）時，通常使用較長的健康檢查間隔來避免大量的主動健康檢查流量。在這種情況下，在使用健康檢查失敗管理端口時，對能夠快速排除上游主機，仍然很有用。為了支持這個，路由器過濾器將響應x-envoy-immediate-health-check-fail頭。如果此報頭由上游主機設置，則Envoy將立即將主機標記為主動健康檢查失敗。請注意，只有在主機集群中配置了主動健康檢查，才會出現此情況。如果Envoy已通過健康檢查失敗管理端口標記為失敗，則運行狀況檢查過濾器將自動設置此標頭。 #### 健康檢查身份識別 只要驗證上游主機對特定健康檢查URL的響應，并不一定意味著上游主機是有效的。例如，在云自動擴展或容器環境中，使用最終一致的服務發現時，主機可能會消失，然后以相同的IP地址返回，但會以不同的主機類型返回。解決這個問題的一個辦法是為每個服務類型設置不同的HTTP健康檢查URL。這種方法的缺點是使得整體配置變得更加復雜，因為每個健康檢查URL都是完全自定義的。 Envoy的HTTP健康檢查支持service_name選項。如果設置了此選項，運行健康檢查程序會將x-envoy-upstream-healthchecked-cluster響應頭域的值與service_name進行比較。如果值不匹配，健康檢查不通過。上游運行狀況檢查過濾器會將x-envoy-upstream-healthchecked-cluster附加到響應頭域。附加值由--service-cluster命令行選項確定。 ### 返回 - [架構介紹](../Architectureoverview.md) - [簡介](../../Introduction.md) - [首頁目錄](../../README.md)