Envoy Proxy和Netflix Hystrix的區別有哪些

Envoy Proxy和Netflix Hystrix的區別有哪些，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

當我們構建服務架構時（面向服務的架構，微服務，以及其他的東西），我們都要在網絡上執行大量的調用。網絡的脆弱是眾所周知的，因此我們希望服務有一定的冗余，以便在系統故障期間能夠保持服務能力。這一拼圖中的重要一塊就是智能的、通曉應用情況的負載均衡器。

在構建大型、可靠的分布式系統尤其是在云端的微服務應用時，斷路器（注 3）是一個重要的組件。有了這一組件，我們可以在系統發生持續故障的時候進行短路操作。斷路器本身也是智能、應用感知的負載均衡器的組成部分。很多人都在或多或少的使用負載均衡。我們來看看 Netflix Hystrix（注 4）和 Envoy Proxy（注 5） 之間的差異。

熔斷

斷路（開路）的價值在于限制故障影響范圍。我們希望控制、減少或或中斷和故障系統之間的通信，從而降低故障系統的負載，有利于系統的恢復。例如有一個搜索服務，通過調用推薦服務來提供個性化的搜索結果；但是過程中發現推薦服務在很多不同調用中都返回了錯誤，所以我們可能應該停止調用一段時間。也許我們越是嘗試就越會給系統造成壓力，會造成情況的進一步惡化。經過考量，我們決定停止對這一服務的調用。這一方式和我們住宅中電氣線路的熔斷機制類似。如果出現故障，就應該斷開故障部分，保護系統的其他部分。斷路器模式強制我們的應用來正視網絡問題——網絡調用是可能、而且真的會出故障的，從而防止系統出現雪崩。這一技術的關鍵就是感知系統組件的健康并判斷是否應該向某組件發送流量。

Netflix OSS Hystrix

Netflix OSS（注 6）在 2012 年發布了了一個斷路器組件（注 7），稱為 Hystrix（注 8）。Hystrix 是一個用于提供熔斷能力的客戶端 Java 庫。Hystrix提供了這樣一些特性（注 7）](https://medium.com/netflix-techblog/making-the-netflix-api-more-resilient-a8ec62159c2d)。

來自“Making the Netflix API more resilient（注 7）”：

• 自定義回落操作：在一些情況下，服務客戶端庫提供了一個回落方法供調用，或者其他情況下，我們可以使用本地的數據來生成回應。

• 故障抑制：在這種情況下，回落方法簡單的返回一個 null 值，如果這一服務返回的數據是可選項目，這種方式會很有幫助。

• 快速失敗：當目標服務的返回數據是必須的秦光霞，上面兩種方法無法解決這一問題的，只能返回一個5xx響應。這對用戶感知是很不好的，但是這一手段能能夠保障服務器的健康，讓系統能夠更快的將失效服務進行修復。

可以用多種方式觸發斷路器（注 7）。

• 對遠程服務的請求發生超時。

• 用于一個服務的線程池或任務隊列容量滿載

• 用于調用服務的客戶端庫拋出異常。

Hystrix 熔斷過程：

Netflix Hystrix 允許對網絡交互進行非常細致的控制（注 9）。Hystrix 允許根據調用類型，對依賴服務進行精細的配置。假設我們對推薦引擎的調用絕大多數情況是只讀的，那么斷路器的配置就可以比較放松。

另外一個重要的事實是，Hystrix 的目的是及時斷路，因此他把故障看做和超時是一致的。超時的故障點也可能處于客戶一側。Hystrix 對斷路門檻的設置，并不區分故障究竟是服務端還是客戶端的責任。

另外呼應前文：斷路器真的只是智能、應用感知負載均衡技術的特性之一。在這種情況下“應用感知”的含義是：他的庫在你的應用中運行。在 Netflix 生態系統中，還可以把 Hystrix 和 Netflix OSS Ribbon（注 10）這樣的客戶端負載均衡進行配對使用。

Service Mesh 的發展

服務架構持續向多樣化方向演進，我們發現強制服務使用特定的庫、框架或者語言是很難或者不實際的。隨著 Service Mesh 走進視野，我們看到熔斷能力有了獨立于語言、框架的基礎設施級的解決方案。Service Mesh 可以定義為：

一個處于服務之間的，去中心化的應用級網絡基礎設施，提供安全、彈性、監控和路由控制能力。

Service Mesh 可以使用不同的 L7（應用級）代理來扮演數據面角色，用于提供重試、超時、斷路器等能力。本文中我們會看看 Envoy Proxy（注 10） 是如何完成熔斷任務的。Envoy Proxy 是 Istio Service Mesh（注 11）的缺省的、開箱即用的代理，所以這里描述的特性同樣也適用于 Istio。

Envoy Proxy / Istio Service Mesh

Envoy Proxy 將斷路功能作為負載均衡和健康檢查的一個子集。Envoy 將路由選擇（選擇進行通信的集群）的功能和通信功能（和確定的后端）分而治之。相對于其他粗粒度配置的負載均衡器，這一設計讓 Envoy 與眾不同。Envoy 可以有很多不同的“路由”嘗試把流量發送給合適的后端。這些后端被稱為cluster，每個cluster都可以有自己的負載均衡配置。每個cluster還可以有自己的被動健康檢查（外部檢測）配置。Envoy 有幾個配置項用于熔斷功能，這里可以逐個介紹一下。

這里定義一個外部cluster：

"clusters": [
  {
    "name": "httpbin_service",
    "connect_timeout_ms": 5000,
    "type": "static",
    "lb_type": "round_robin",
    "hosts": [
      {
        "url": "tcp://172.17.0.2:8080"
      },{
        "url": "tcp://172.17.0.3:8080"
      }
    ],

這里我們會看到，這里有一個叫httpbin_service的集群，使用round_robin的策略在兩個主機之間進行負載均衡。接下來加入 Envoy 斷路器配置（注 11）。

斷路器

   "circuit_breakers": {
      "default": {
        "max_connections": 1,
        "max_pending_requests": 1,
        "max_retries": 3
      }

這里我們目標是 HTTP 1.x 的負載。我們限制外來連接為 1，最大排隊請求也是 1。另外還定義了最大重試次數。某種意義上，限制連接池以及請求數量的做法和 bulkhead（注 12） 以及 Netflix Hystrix 是類似的。如果客戶端應用打開了超過限制的連接數量（這是一種軟限制，有一定誤差），我們會看到 Envoy 斷掉多出的連接（注 13），并在統計報告中進行記錄。

外部檢測

上面我們看到，Envoy 所謂的熔斷功能實際上更像是連接池控制。要完成這一功能，Envoy 做了一些稱為outlier detection（注 14）。Envoy 持續對負載均衡池中的不同端點的操作進行統計。如果發現了超標行為，就把端點從負載均衡池中移除。我們可以看一下這一部分的配置代碼：

   "outlier_detection" : {
      "consecutive_5xx": 1,
      "max_ejection_percent": 100,
      "interval_ms": 1000,
      "base_ejection_time_ms": 60000
    }

這一配置的含義是：通信過程中，“如果發生了一次 5xx”錯誤，我們應該把這一主機標記為不健康，將其從負載均衡池中移除。我們還配置max_ejection_percent為100，也就是說，在發生這一情況時，我們愿意逐出所有端點。這一設置跟環境緊密相關，因此配置內容應該因地制宜，謹慎從事。我們希望盡可能的路由到一個主機，這樣我們就不必冒著部分或級聯故障的風險了。Envoy 缺省設置max_ejection_percent為10。

我們還設置逐出的時間基數為6000毫秒。一個主機被逐出負載均衡池的真實時間，由這一基數乘以被逐出時間得來，這樣就可以對穩定性較差的主機實行更久的隔離。

集群恐慌

Envoy 外部檢測和負載均衡功能中還有一點我們要知道的。如果太多的主機被這一過程逐出，就會進入集群恐慌模式（注 15），這種情況下，代理服務器會無視負載均衡池的健康標記，重新向所有主機發送數據。這是一個非常棒的機制。在分布式系統中，必須了解到的一點是，有時候“理論上”的東西可能不是正常情況，最好能降低一點要求來防止擴大故障影響。另外一方面，可以對這一比例進行控制（缺省情況下超過 50% 的驅逐就會進入恐慌狀態），可以提高，也可以禁止這一閾值。設置為0之后，他的熔斷行為就和 Netflix Hystrix 類似了。

可微調的熔斷策略

庫方式有個好處就是應用感知的可微調的熔斷策略。Hystrix 文檔中演示了針對同一集群的查詢、讀取、寫入的不同調用，Hystrix FAQ 中說到：

通常情況下，一組負載均衡集群形成的單一網絡路由會使用很多不同的 HystrixCommands 服務于很多不同類型的功能。

每個 HystrixCommands 都需要設置不同的吞吐限制、超時以及回落策略。

在 Envoy 中，我們能夠通過路由匹配功能（注 16）獲得同樣的精確的熔斷策略，這一功能和集群策略（注 17）結合，就可以指定在什么集群上進行什么操作了。

Istio 斷路器

我們可以使用 Istio 的高級配置，來提供斷路器能力。在 Istio 中，我們使用 目標策略（注 17）來配置負載均衡和斷路器策略。下面是一個目標策略的例子，其中進行了斷路器的設置：

metadata:
  name: reviews-cb-policy
  namespace: defaultspec:
  destination:
    name: reviews
    labels:
      version: v1
  circuitBreaker:
    simpleCb:
      maxConnections: 100
      httpMaxRequests: 1000
      httpMaxRequestsPerConnection: 10
      httpConsecutiveErrors: 7
      sleepWindow: 15m
      httpDetectionInterval: 5m

熔斷之后怎么辦？

達到熔斷標準的時候，會發生什么事情？Hystrix 中的回落策略是包含在庫中并且能夠進行編排的。Hystrix 讓我們可以做一些后續操作，例如返回緩存值、返回缺省值甚至去調用其他服務。我們還可以獲得清晰的關于故障的信息，并作出應用相關的決策。

在 Service Mesh 之中，因為沒有內置庫的支持，故障原因會比較隱蔽。這并不意味著我們的應用就不能有回落操作了（不管是傳輸還是客戶端錯誤）。我認為對任何應用來說，不論他用的是不是特定庫的框架，都會要嘗試完成對客戶的承諾。如果無法完成預定動作，就應該有一種優雅的降級方法。幸運的是，這種操作也不是非框架不可。多數語言都有內置的錯誤和異常處理能力，回落策略可以在異常處理過程中完成。

回放

• 熔斷能力是負載均衡的功能之一。

• Hystrix 只提供了熔斷能力，負載均衡要配合 Ribbon（或者其他客戶端負載均衡庫）完成。

• Hystrix 以客戶端庫的形式提供了回落能力，非常強大。

• Envoy 的負載均衡實現中包含了外部檢測和斷路器的功能。

• Envoy 的熔斷更像 Hystrix Bulkhead ，外部檢測更像 Hystrix 斷路器。

• Envoy 具有很多缺省的久經考驗的功能，例如集群恐慌。

• Service Mesh 缺少故障回落的能力，只能讓應用來完成這一任務。

看完上述內容，你們掌握Envoy Proxy和Netflix Hystrix的區別有哪些的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！