前言
很多人學習和使用envoy時，很容易混淆一些概念，比如把異常點驅逐和微服務熔斷混爲一談，分不清最大驅逐比與恐慌閾值的區別等。本文將基於envoy官方文檔(v1.10.0)，詳細介紹異常點檢測的類型、驅逐算法以及相關概念的解析，並且最後對易混淆的幾個概念進行辨析。
簡介
異常點檢測(Outlier detection)和驅逐(Ejection)是用來動態確定上游集羣中是否有表現不同於其他主機的實例，並將它們從健康負載均衡集中移除的過程。性能可能會沿着不同的軸變化，如連續失敗，一時的成功率，短時間內的延遲等。異常值檢測是一種被動的健康檢查形式。Envoy還支持主動健康檢查。被動和主動健康檢查功能可以一起或獨立使用，它們共同構成整個上游健康檢查解決方案的基礎。
驅逐算法
根據異常值檢測的類型，驅逐要麼以直線方式運行（例如在連續返回5xx的情況下），要麼以指定的間隔運行（例如在週期性成功率的情況下）。驅逐算法的工作原理如下:
- 主機被確定爲異常點。
- 如果沒有主機被驅逐，Envoy 會立即驅逐主機。否則，它會檢查以確保驅逐主機的數量低於允許的閾值（通過 outlier_detection.max_ejection_percent設置指定）。如果驅逐的主機數量超過閾值，則主機不會被驅逐。
- 主機被驅逐的狀態會保持一小段時間（以毫秒爲單位）。被驅逐意味着該主機被標記爲不健康，並且在負載均衡期間不會被使用，除非負載均衡器處於恐慌狀態。被驅逐的時間等於outlier_detection.base_ejection_time_ms的值乘以該主機被驅逐的次數。這意味着，如果該主機連續失敗，它被驅逐的時間將越來越長。
- 驅逐時間滿足後，被驅逐主機將自動恢復服務。通常情況下，異常值檢測與主動健康檢查(active health checking)一起使用，以獲得全面的健康檢查解決方案。
檢測類型
Envoy支持以下異常點檢測類型：
連續返回5xx
如果上游主機返回一些連續的5xx，它將被驅逐。注意，在本例中，5xx表示實際的5xx響應碼，或者導致HTTP路由器代表上游返回該響應碼的事件（重置、連接失敗等）。驅逐所需的連續5xx的數量由outlier_detection.continutive_5xx值控制。
連續網關失敗
如果上游主機返回一些連續的"網關錯誤”（502、503或504狀態碼），它將被驅逐。注意，這包括可能導致HTTP路由器代表上游返回其中一個狀態碼的事件（重置、連接失敗等）。驅逐所需的連續網關故障數量由outlier_detection.consecutive_gateway_failure值所決定的。
成功率
基於成功率的異常點驅逐聚合了集羣中每個主機的成功率數據。然後在給定的時間間隔內，基於統計的異常點檢測數據對主機進行驅逐。如果主機的請求量彙總時間間隔小於outlier_detection.success_rate_request_volume值，該異常點驅逐將不會被計算。另外，如果一個間隔中具有最小所需請求卷的主機數量小於outlier_detection.success_rate_minimum_hosts 值，檢測將不能進行。
驅逐事件日誌
異常點驅逐事件的日誌可以由Envoy選擇性地生成。這在日常操作中非常有用，因爲全局統計信息不能提供關於哪些主機被驅逐以及出於什麼原因被驅逐的足夠信息。日誌被結構化爲基於protobuf的OutlierDetectionEvent messages轉存文件。驅逐事件日誌是在集羣管理器outlier detection configuration中配置的。
相關概念
主動健康檢查
主動健康檢查可以在每個上游集羣的基礎上進行配置。主動運行健康檢查和EDS類型服務發現會同時進行。但是，即使使用其他服務發現類型，也有其他需要進行主動健康檢查的情況。Envoy 支持三種不同類型的健康檢查（HTTP, L3/L4, Redis）及各種設置（檢查時間間隔、主機不健康標記爲故障、主機健康時標記爲成功等）。
在同時使用主動健康檢查和被動健康檢查(異常點檢測)時，通常使用較長的健康檢查間隔來避免大量的主動健康檢查流量。在這種情況下，當使用/healthcheck/fail管理端點時，能夠快速耗盡上游主機仍然是有用的，router filter會在x-envoy-immediate-health-check-fail header裏面響應來支持它的實現。如果header由上游主機設置標記，Envoy將立即將主機標記爲主動健康檢查失敗。注意，只有在主機集羣的主動健康檢查已配置時纔會發生這種情況。如果Envoy已經通過/healthcheck/fail管理端點標記爲失敗，健康檢查過濾器將自動設置這個header。
恐慌閾值
在負載均衡期間，Envoy 通常只會考慮上游集羣中健康的主機。但是，如果集羣中健康主機的百分比變得過低，envoy 將忽視所有主機中的健康狀況和均衡。這被稱爲 恐慌閾值(panic threshold) 。缺省恐慌閾值是 50％。這可以通過運行時配置或者集羣配置進行配置。恐慌閾值用於避免在負載增加時主機故障導致整個集羣中級聯故障的情況。注意：恐慌閾值不同於驅逐算法第2點提到的最大驅逐百分比(outlier_detection.max_ejection_percent)。
另外，恐慌閾值與優先級協同工作。如果某個優先級的可用主機數量下降，Envoy將嘗試將一些流量轉移到較低的優先級。如果它成功地在較低的優先級找到足夠的可用主機，Envoy將不顧恐慌閾值。在數學術語中，如果所有優先級的規範化(normalized)總可用性爲100%，Envoy將忽略恐慌閾值，並繼續根據這裏描述的算法在優先級之間分配流量負載。然而，當規範化總可用性下降到100%以下時，Envoy假定在所有優先級上都沒有足夠的可用主機。它將繼續跨優先級分配流量負載，但是如果給定優先級的可用性低於panic閾值，則流量將負載均衡到該優先級的所有主機，而不管它們的可用性如何。
總結
結合以上介紹來看，異常點檢測是一種被動的健康檢查，區別於主動健康檢查，它不是向主機發送心跳或者通過長鏈接探活來判定實例的健康，而是通過對該主機發起的請求的返回值做分析，基於不同的檢測類型以及不同的驅逐算法，對目標主機做驅逐或者恢復。
而微服務中的熔斷主要是一種系統保護策略，它的基本功能是在檢測到故障後切斷鏈路，通過直接返回錯誤或者fallback值，來直接提高系統可用性，防止該故障程序出現問題蔓延至整個網絡造成雪崩效果。筆者以爲，envoy中的異常點檢測可以理解爲"實例級別"的熔斷，並且沒有半開放狀態。關於該實例級別的熔斷與公稱斷路器的區別的詳細介紹，可以參考微服務斷路器模式實現：Istio vs Hystrix。
並且，envoy異常點檢測中的maxEjectionPercent屬性的作用會保持一部分的實例池，即使其中部分實例不可用。其目的是爲了避免在負載增加時主機故障導致整個集羣中級聯故障雪崩，這一點和恐慌閾值的作用相似。但是’maxEjectionPercent’與’panic threshold’的作用域卻完全不同。達到恐慌閾值後，流量將負載均衡到該優先級的所有主機，所有主機包括被異常點檢測標記爲不健康的實例和健康的實例，並且如果如果驅逐達到了‘maxEjectionPercent’設定值，那麼這組健康的實例中還可能包含不可用的實例。
最後Envoy自身還實現了網絡級別的分佈式斷路器，這纔是istio/envoy提供的"正統"斷路器。作爲一個分佈式短路器，它的特點是在網絡級別強制實現斷路，而不必爲每個應用程序單獨配置或者編程，實現零侵入。Envoy支持的分佈式斷路包括：集羣最大連接數、集羣最大掛起請求數、集羣最大請求數、集羣最大活動重試次數等。
總而言之，不管是envoy的異常點檢測還是網絡級別的分佈式斷路器，作爲一種sidecar代理，採用的是黑盒方式的實現，並且對應用程序零侵入。但是如果你的系統需要對某個應用程序做到方法級別的精確熔斷，設置各種超時重試等參數，設置不同的fallback返回值，抑或是調用其它的服務做降級處理等等，則需要侵入式的斷路器（可參考Resilience4J與Hystrix）。
本文轉載自公衆號ServiceMesher（ID：ServiceMesher）。
原文鏈接：