《Istio官方文件》—— 故障處理
原文連結 譯者:carvendy
故障處理
使者在故障恢復中，提供了一個拆箱即用的集合，可以更方便地在服務中移除應用。特性包括：
- 超時
- 限定的重試，在重試之間有超時預計與數值的波動性。
- 有限的併發連線數和請求的上游服務。
- 對於負載均衡池裡的成員，進行動態（週期性的）健康檢查。
- 細粒度的斷路器（通過健康檢查）—— 在負載均衡池裡每個例項都需要通過。
重試的抖動減少了，重試對上游服務的影響。當可能會超時的時候，呼叫服務會在限定的時間內得到響應(成功或失敗)。
主動和被動組成的健康檢查，在負載均衡池裡最少（4~5以上）機會訪問不健康的例項。當組合使用容器管理級別的健康檢查（如：Kubernetes或Mesos），應用可以確定不健康的pod、container、VM,並將其從服務網格中移除，只產生極小的故障和潛在影響。
同時，這些特性可以讓服務網格忍受故障的節點，並避免了來自級聯不確定的節點引起區域性失敗。
好協調
Istio流量管理規則允許運維人員為失敗故障的每一個服務或版本設定全域性預設服務或版本。無論如何，服務的消費者可以重寫超時和重試，並通過特別的HTTP頭資訊來提供了請求級別的重寫。在使者代理實現下，頭部資訊分別是“x-envoy-upstream-rq-timeout-ms” 和 “x-envoy-max-retries”。
FAQ
- 執行在Istio的應用依然要處理失敗？
是的，在網格里Istio提供了可靠和可用的服務。無論如何，應用需要處理故障(錯誤)和採取適當的後備操作。舉例子，在負載均衡池裡的所有例項有失敗的，使者將會返回503狀態碼。應用的響應就會實現任何後備的邏輯，並需要處理來自下游服務的503錯誤碼。
- 使者故障恢復特性，將會打破應用程式已經使用失敗容忍的類庫？(例如：Hystrix)
不是。使者對於應用是完整的、透明的。由使者返回個失敗的響應，將不能從中區別下游服務在哪裡被喚醒。
- 當同時使用應用級別的類庫和使者代理，要如何處理故障？
對於同一個目的地的服務使用兩種故障恢復策略。（例如：兩個超時——一個在使者一個在應用類庫），這兩個限制將會在故障時候被觸發。例子，如果應用設定了5秒鐘作為一個API響應超時時間，而當運維配置了10秒種，應用的超時將會首先發生。同樣地，如果使者斷路器在應用斷路器之前執行了，那麼API響應服務將會從使者中獲取到503狀態碼。
