Envoy Proxy和Netflix Hystrix的區(qū)別有哪些

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

當(dāng)我們構(gòu)建服務(wù)架構(gòu)時（面向服務(wù)的架構(gòu)，微服務(wù)，以及其他的東西），我們都要在網(wǎng)絡(luò)上執(zhí)行大量的調(diào)用。網(wǎng)絡(luò)的脆弱是眾所周知的，因此我們希望服務(wù)有一定的冗余，以便在系統(tǒng)故障期間能夠保持服務(wù)能力。這一拼圖中的重要一塊就是智能的、通曉應(yīng)用情況的負(fù)載均衡器。

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

熔斷

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

Netflix OSS Hystrix

Netflix OSS（注 6）在 2012 年發(fā)布了了一個斷路器組件（注 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）”：

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

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

• 快速失?。?/strong>當(dāng)目標(biāo)服務(wù)的返回數(shù)據(jù)是必須的秦光霞，上面兩種方法無法解決這一問題的，只能返回一個5xx響應(yīng)。這對用戶感知是很不好的，但是這一手段能能夠保障服務(wù)器的健康，讓系統(tǒng)能夠更快的將失效服務(wù)進(jìn)行修復(fù)。

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

• 對遠(yuǎn)程服務(wù)的請求發(fā)生超時。

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

• 用于調(diào)用服務(wù)的客戶端庫拋出異常。

Hystrix 熔斷過程：

Netflix Hystrix 允許對網(wǎng)絡(luò)交互進(jìn)行非常細(xì)致的控制（注 9）。Hystrix 允許根據(jù)調(diào)用類型，對依賴服務(wù)進(jìn)行精細(xì)的配置。假設(shè)我們對推薦引擎的調(diào)用絕大多數(shù)情況是只讀的，那么斷路器的配置就可以比較放松。

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

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

Service Mesh 的發(fā)展

服務(wù)架構(gòu)持續(xù)向多樣化方向演進(jìn)，我們發(fā)現(xiàn)強(qiáng)制服務(wù)使用特定的庫、框架或者語言是很難或者不實際的。隨著 Service Mesh 走進(jìn)視野，我們看到熔斷能力有了獨立于語言、框架的基礎(chǔ)設(shè)施級的解決方案。Service Mesh 可以定義為：

一個處于服務(wù)之間的，去中心化的應(yīng)用級網(wǎng)絡(luò)基礎(chǔ)設(shè)施，提供安全、彈性、監(jiān)控和路由控制能力。

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

Envoy Proxy / Istio Service Mesh

Envoy Proxy 將斷路功能作為負(fù)載均衡和健康檢查的一個子集。Envoy 將路由選擇（選擇進(jìn)行通信的集群）的功能和通信功能（和確定的后端）分而治之。相對于其他粗粒度配置的負(fù)載均衡器，這一設(shè)計讓 Envoy 與眾不同。Envoy 可以有很多不同的“路由”嘗試把流量發(fā)送給合適的后端。這些后端被稱為cluster，每個cluster都可以有自己的負(fù)載均衡配置。每個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的策略在兩個主機(jī)之間進(jìn)行負(fù)載均衡。接下來加入 Envoy 斷路器配置（注 11）。

斷路器

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

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

外部檢測

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

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

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

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

集群恐慌

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

可微調(diào)的熔斷策略

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

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

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

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

Istio 斷路器

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

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

熔斷之后怎么辦？

達(dá)到熔斷標(biāo)準(zhǔn)的時候，會發(fā)生什么事情？Hystrix 中的回落策略是包含在庫中并且能夠進(jìn)行編排的。Hystrix 讓我們可以做一些后續(xù)操作，例如返回緩存值、返回缺省值甚至去調(diào)用其他服務(wù)。我們還可以獲得清晰的關(guān)于故障的信息，并作出應(yīng)用相關(guān)的決策。

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

回放

• 熔斷能力是負(fù)載均衡的功能之一。

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

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

• Envoy 的負(fù)載均衡實現(xiàn)中包含了外部檢測和斷路器的功能。

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

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

• Service Mesh 缺少故障回落的能力，只能讓應(yīng)用來完成這一任務(wù)。

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