流量管理

Istio 的流量路由規則可讓您輕鬆控制服務之間的流量和 API 呼叫。Istio 簡化了服務層級屬性的配置，例如斷路器、逾時和重試，並可輕鬆設定重要的任務，例如 A/B 測試、金絲雀發布和基於百分比流量分割的分階段發布。它還提供了開箱即用的可靠性功能，有助於提高您的應用程式對相依服務或網路故障的彈性。

Istio 的流量管理模型依賴於與您的服務一起部署的 Envoy 代理程式。您的網格服務傳送和接收的所有流量（資料平面 流量）會透過 Envoy 代理，讓您輕鬆地在網格周圍導引和控制流量，而無需對您的服務進行任何變更。

如果您對本指南中描述的功能如何運作的細節感興趣，您可以在架構概觀中找到更多關於 Istio 流量管理實作的資訊。本指南的其餘部分將介紹 Istio 的流量管理功能。

Istio 流量管理簡介

為了在網格內導引流量，Istio 需要知道您的所有端點在哪裡，以及它們屬於哪些服務。為了填入其自身的服務註冊表，Istio 會連線到服務探索系統。例如，如果您已在 Kubernetes 叢集上安裝 Istio，則 Istio 會自動偵測該叢集中的服務和端點。

使用此服務註冊表，Envoy 代理程式可以將流量導引至相關的服務。大多數基於微服務的應用程式都具有每個服務工作負載的多個執行個體來處理服務流量，有時稱為負載平衡池。預設情況下，Envoy 代理程式會使用最少請求模型在每個服務的負載平衡池中分配流量，其中每個請求都會路由到來自池中隨機選擇的兩個主機中具有較少作用中請求的主機；透過這種方式，負載最重的主機將不會收到請求，直到它不再比任何其他主機更負載。

雖然 Istio 的基本服務探索和負載平衡為您提供可運作的服務網格，但這遠遠不是 Istio 可以做的一切。在許多情況下，您可能希望對網格流量的處理方式進行更精細的控制。您可能希望將特定百分比的流量導引至服務的新版本，作為 A/B 測試的一部分，或者對特定服務執行個體子集的流量應用不同的負載平衡原則。您也可能希望對進入或離開網格的流量套用特殊規則，或將網格的外部相依性新增至服務註冊表。您可以使用 Istio 的流量管理 API 將您自己的流量配置新增至 Istio，來執行所有這些操作及更多功能。

與其他 Istio 配置一樣，API 是使用 Kubernetes 自訂資源定義（CRD）指定的，您可以使用 YAML 進行配置，如範例所示。

本指南的其餘部分將檢視每個流量管理 API 資源以及您可以使用它們執行的操作。這些資源是

• 虛擬服務
• 目標規則
• 閘道
• 服務條目
• 邊車

本指南還概述了內建於 API 資源中的一些網路彈性和測試功能。

虛擬服務

虛擬服務與目標規則一起，是 Istio 流量路由功能的關鍵建構區塊。虛擬服務可讓您設定如何在 Istio 服務網格中將請求路由到服務，這是建立在 Istio 和您的平台提供的基本連線和探索之上的。每個虛擬服務都包含一組按順序評估的路由規則，讓 Istio 將給定請求與虛擬服務相符，以符合網格中的特定實際目標。您的網格可能需要多個虛擬服務或不需要，取決於您的使用案例。

為什麼要使用虛擬服務？

虛擬服務在使 Istio 的流量管理靈活且強大方面發揮著關鍵作用。它們透過將用戶端傳送請求的位置與實際實作請求的目標工作負載強烈地解耦來實現這一點。虛擬服務還提供了一種豐富的方式，用於指定不同的流量路由規則，以便將流量傳送到這些工作負載。

為什麼這如此有用？如果沒有虛擬服務，Envoy 會在所有服務執行個體之間使用最少請求負載平衡來分配流量，如簡介中所述。您可以使用您對工作負載的了解來改進此行為。例如，有些工作負載可能代表不同的版本。這在 A/B 測試中可能很有用，在 A/B 測試中，您可能希望根據不同服務版本的百分比設定流量路由，或將來自內部使用者的流量導引到一組特定的執行個體。

使用虛擬服務，您可以指定一個或多個主機名稱的流量行為。您可以使用虛擬服務中的路由規則，告訴 Envoy 如何將虛擬服務的流量傳送到適當的目標。路由目標可以是同一服務的不同版本，也可以是完全不同的服務。

一個典型的使用案例是將流量傳送到服務的不同版本，指定為服務子集。用戶端將請求傳送到虛擬服務主機，就好像它是一個單一實體一樣，然後 Envoy 會根據虛擬服務規則將流量路由到不同的版本：例如，「20% 的呼叫進入新版本」或「來自這些使用者的呼叫進入版本 2」。這可讓您，例如建立金絲雀發布，其中您逐漸增加傳送到新服務版本的流量百分比。流量路由完全與執行個體部署分離，這表示實作新服務版本的執行個體數量可以根據流量負載向上和向下調整，而完全不需要參考流量路由。相比之下，像 Kubernetes 這樣的容器協調平台僅支援基於執行個體調整的流量分配，這會很快變得複雜。您可以透過使用 Istio 的金絲雀部署深入了解虛擬服務如何協助金絲雀部署。

虛擬服務還可讓您

• 透過單一虛擬服務處理多個應用程式服務。例如，如果您的網格使用 Kubernetes，您可以設定一個虛擬服務來處理特定命名空間中的所有服務。將單一虛擬服務對應到多個「實際」服務，在將單體式應用程式轉換為由不同微服務組成的複合服務時，特別有助於方便，而無需服務的消費者適應轉換。您的路由規則可以指定「呼叫 monolith.com 的這些 URI 會進入 microservice A」，依此類推。您可以在我們下面的範例之一中了解其運作方式。
• 結合閘道設定流量規則，以控制輸入和輸出流量。

在某些情況下，您還需要設定目標規則才能使用這些功能，因為它們是您指定服務子集的位置。在單獨的物件中指定服務子集和其他特定於目標的原則，可讓您在虛擬服務之間乾淨地重複使用這些原則。您可以在下一節中找到更多關於目標規則的資訊。

虛擬服務範例

以下虛擬服務根據請求是否來自特定使用者，將請求路由到服務的不同版本。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

hosts 欄位

hosts 欄位列出虛擬服務的主機（hosts）— 換句話說，這些路由規則適用的使用者可定址的目的地。這是客戶端在向服務發送請求時使用的位址。

hosts:
- reviews

虛擬服務的主機名稱可以是 IP 位址、DNS 名稱，或者，根據平台的不同，可以是解析為完整網域名稱 (FQDN) 的簡短名稱（例如 Kubernetes 服務簡短名稱，透過隱式或顯式的方式）。您也可以使用萬用字元 ("*") 前綴，讓您可以為所有匹配的服務建立一組路由規則。虛擬服務主機實際上不必是 Istio 服務註冊表的一部分，它們只是虛擬目的地。這讓您可以為網格內沒有可路由條目的虛擬主機建立流量模型。

路由規則

http 區段包含虛擬服務的路由規則，描述了路由到 hosts 欄位中指定目的地的 HTTP/1.1、HTTP2 和 gRPC 流量的匹配條件和動作（您也可以使用 tcp 和 tls 區段來設定 TCP 和未終止的 TLS 流量的路由規則）。路由規則由您希望流量前往的目的地以及零個或多個匹配條件組成，具體取決於您的使用案例。

符合條件

範例中的第一個路由規則具有條件，因此以 match 欄位開始。在這種情況下，您希望此路由適用於來自使用者 "jason" 的所有請求，因此您使用 headers、end-user 和 exact 欄位來選擇適當的請求。

- match:
   - headers:
       end-user:
         exact: jason

目的地

路由區段的 destination 欄位指定了符合此條件的流量的實際目的地。與虛擬服務的主機不同，目的地的「主機」必須是 Istio 服務註冊表中存在的真實目的地，否則 Envoy 將不知道將流量發送到何處。這可以是具有代理的網格服務，也可以是使用服務條目新增的非網格服務。在這種情況下，我們在 Kubernetes 上運行，並且主機名稱是 Kubernetes 服務名稱。

route:
- destination:
    host: reviews
    subset: v2

請注意，在本頁面上的這個和其他範例中，為了簡化起見，我們使用 Kubernetes 簡短名稱作為目的地主機。當評估此規則時，Istio 會根據包含路由規則的虛擬服務的命名空間新增一個網域後綴，以取得主機的完整名稱。在我們的範例中使用簡短名稱也表示您可以在任何您喜歡的命名空間中複製並嘗試它們。

目的地區段還指定了您希望符合此規則條件的請求前往此 Kubernetes 服務的哪個子集，在此範例中是名為 v2 的子集。您將在下面的 目的地規則章節中看到如何定義服務子集。

路由規則優先順序

路由規則會**從上到下依序評估**，虛擬服務定義中的第一個規則具有最高的優先順序。在這種情況下，您希望任何不符合第一個路由規則的內容都前往預設目的地，該目的地在第二個規則中指定。因此，第二個規則沒有匹配條件，只是將流量導向 v3 子集。

- route:
  - destination:
      host: reviews
      subset: v3

我們建議在每個虛擬服務中，提供像這樣「沒有條件」或基於權重的預設規則（如下所述）作為最後一個規則，以確保虛擬服務的流量始終至少有一個匹配的路由。

更多關於路由規則

正如您在上面看到的，路由規則是一個強大的工具，用於將特定的流量子集路由到特定的目的地。您可以根據流量連接埠、標頭欄位、URI 等設定匹配條件。例如，此虛擬服務允許使用者向兩個不同的服務（評分和評論）發送流量，就好像它們是 http://bookinfo.com/ 上較大虛擬服務的一部分。虛擬服務規則會根據請求 URI 匹配流量，並將請求導向適當的服務。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - bookinfo.com
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    - destination:
        host: reviews
  - match:
    - uri:
        prefix: /ratings
    route:
    - destination:
        host: ratings

對於某些匹配條件，您也可以選擇使用確切的值、前綴或正規表示式來選擇它們。

您可以將多個匹配條件新增到同一個 match 區塊，以 AND 您的條件，或者將多個匹配區塊新增到同一個規則，以 OR 您的條件。您也可以為任何給定的虛擬服務設定多個路由規則。這讓您可以在單個虛擬服務中，根據您的喜好設定複雜或簡單的路由條件。您可以在 HTTPMatchRequest 參考中找到匹配條件欄位及其可能值的完整清單。

除了使用匹配條件之外，您還可以按百分比「權重」分配流量。這對於 A/B 測試和 Canary 發布很有用。

spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

您也可以使用路由規則來對流量執行某些動作，例如

• 新增或移除標頭。
• 重寫 URL。
• 為對此目的地的呼叫設定重試策略。

要瞭解有關可用動作的更多資訊，請參閱 HTTPRoute 參考。

目標規則

除了虛擬服務之外，目的地規則是 Istio 流量路由功能的關鍵部分。您可以將虛擬服務視為如何將流量路由**到**給定目的地，然後使用目的地規則設定該目的地的流量**發生**什麼。目的地規則會在評估虛擬服務路由規則之後應用，因此它們適用於流量的「真實」目的地。

具體而言，您可以使用目的地規則指定已命名的服務子集，例如按版本分組給定服務的所有實例。然後，您可以使用虛擬服務的路由規則中的這些服務子集來控制不同服務實例的流量。

目的地規則還讓您可以自訂 Envoy 的流量策略，當呼叫整個目的地服務或特定服務子集時，例如您偏好的負載平衡模型、TLS 安全模式或斷路器設定。您可以在 目的地規則參考中看到目的地規則選項的完整清單。

負載平衡選項

依預設，Istio 使用最少請求的負載平衡策略，其中請求會分佈到具有最少請求數的實例中。Istio 還支援以下模型，您可以在目的地規則中為對特定服務或服務子集的請求指定這些模型。

• 隨機：請求會隨機轉發到集區中的實例。
• 加權：請求會根據特定百分比轉發到集區中的實例。
• 輪詢：請求會依序轉發到每個實例。
• 一致性雜湊：根據 HTTP 標頭、Cookie 或其他屬性提供軟性工作階段親和性。
• 環狀雜湊：使用 Ketama 演算法對上游主機實作一致性雜湊。
• Maglev：根據 Maglev 論文中描述的方式，對上游主機實作一致性雜湊。

有關每個選項的更多資訊，請參閱 Envoy 負載平衡文件。

目標規則範例

以下範例目的地規則為 my-svc 目的地服務設定三個不同的子集，具有不同的負載平衡策略

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

每個子集都根據一個或多個 labels 定義，在 Kubernetes 中，這些標籤是附加到物件（例如 Pod）的金鑰/值配對。這些標籤會在 Kubernetes 服務的部署中作為 metadata 應用，以識別不同的版本。

除了定義子集之外，此目的地規則還具有此目的地中所有子集的預設流量策略，以及僅針對該子集覆蓋該策略的子集特定策略。在 subsets 欄位上方定義的預設策略，為 v1 和 v3 子集設定一個簡單的隨機負載平衡器。在 v2 策略中，輪詢負載平衡器在相應子集的欄位中指定。

閘道

您可以使用 閘道 來管理網格的輸入和輸出流量，讓您可以指定想要進入或離開網格的流量。閘道組態會應用於在網格邊緣執行的獨立 Envoy 代理，而不是與您的服務工作負載並排執行的 Sidecar Envoy 代理。

與其他控制流量進入系統的機制（例如 Kubernetes Ingress API）不同，Istio 閘道讓您可以使用 Istio 流量路由的全部功能和彈性。您可以這樣做，因為 Istio 的閘道資源只讓您設定第 4-6 層的負載平衡屬性，例如要公開的連接埠、TLS 設定等等。然後，您可以將常規 Istio 虛擬服務繫結到閘道，而不是將應用程式層流量路由 (L7) 新增到相同的 API 資源。這讓您基本上可以像管理 Istio 網格中的任何其他資料平面流量一樣管理閘道流量。

閘道主要用於管理輸入流量，但您也可以設定輸出閘道。輸出閘道讓您可以為離開網格的流量設定專用的退出節點，讓您可以限制哪些服務可以或應該存取外部網路，或者啟用安全控制輸出流量，例如為您的網格增加安全性。您也可以使用閘道設定純粹的內部代理。

Istio 提供了一些預先設定的閘道代理部署 (istio-ingressgateway 和 istio-egressgateway)，您可以使用它們 — 如果您使用我們的示範安裝，則會部署這兩個部署，而只有輸入閘道會透過我們的 預設設定檔部署。您可以將您自己的閘道組態應用於這些部署，或部署並設定您自己的閘道代理。

閘道範例

以下範例顯示了外部 HTTPS 輸入流量的可能閘道組態

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    app: my-gateway-controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      credentialName: ext-host-cert

這個閘道設定允許來自 ext-host.example.com 的 HTTPS 流量透過 443 連接埠進入網格，但沒有指定任何流量路由。

若要指定路由並使閘道如預期般運作，您還必須將閘道綁定到虛擬服務。您可以使用虛擬服務的 gateways 欄位來執行此操作，如下列範例所示。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
  - ext-host-gwy

接著，您可以設定虛擬服務，以設定外部流量的路由規則。

服務條目

您可以使用服務條目，將條目新增到 Istio 內部維護的服務註冊表中。新增服務條目後，Envoy 代理程式可以將流量傳送到該服務，就像它是網格中的服務一樣。設定服務條目可讓您管理在網格外部執行的服務流量，包括下列任務：

• 重新導向和轉發外部目的地的流量，例如從網路上使用的 API，或是傳送到舊有基礎架構中服務的流量。
• 為外部目的地定義重試、逾時和錯誤注入策略。
• 透過將虛擬機器新增到網格，在虛擬機器 (VM) 中執行網格服務。

您不需要為網格服務想要使用的每個外部服務新增服務條目。依預設，Istio 會設定 Envoy 代理程式以將請求傳遞到未知服務。但是，您無法使用 Istio 功能來控制傳送到未在網格中註冊的目的地的流量。

服務條目範例

以下範例網格外部服務條目將 ext-svc.example.com 外部依賴項新增到 Istio 的服務註冊表中。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

您可以使用 hosts 欄位指定外部資源。您可以完全限定它，或是使用帶有萬用字元前綴的網域名稱。

您可以使用虛擬服務和目標規則，以更精細的方式控制傳送到服務條目的流量，就像您設定網格中任何其他服務的流量一樣。例如，以下目標規則調整了傳送到 ext-svc.example.com 外部服務的請求的 TCP 連線逾時時間，該外部服務是我們使用服務條目設定的。

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    connectionPool:
      tcp:
        connectTimeout: 1s

如需更多可能的設定選項，請參閱服務條目參考。

邊車

依預設，Istio 會設定每個 Envoy 代理程式以接受其相關工作負載的所有連接埠上的流量，並在轉發流量時到達網格中的每個工作負載。您可以使用Sidecar 設定來執行下列操作：

• 微調 Envoy 代理程式接受的連接埠和協定集。
• 限制 Envoy 代理程式可以連線到的服務集。

您可能會想要在較大型的應用程式中像這樣限制 Sidecar 的可連線性，因為如果將每個代理程式都設定為可以連線到網格中的每個其他服務，則可能會因為記憶體使用率過高而影響網格效能。

您可以使用 workloadSelector 指定要將 Sidecar 設定套用至特定命名空間中的所有工作負載，或是選擇特定的工作負載。例如，以下 Sidecar 設定會將 bookinfo 命名空間中的所有服務設定為只能連線到在同一個命名空間中執行的服務和 Istio 控制平面（Istio 的輸出和遙測功能需要）。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

如需更多詳細資訊，請參閱Sidecar 參考。

網路彈性和測試

除了協助您在網格中導引流量之外，Istio 還提供您可以於執行階段動態設定的可選故障恢復和錯誤注入功能。使用這些功能有助於您的應用程式可靠地運作，確保服務網格可以容忍失敗的節點，並防止局部故障級聯到其他節點。

逾時

逾時是指 Envoy 代理程式應等待來自指定服務的回覆的時間長度，確保服務不會無限期地等待回覆，並確保呼叫在可預測的時間範圍內成功或失敗。依預設，Istio 中會停用 HTTP 請求的 Envoy 逾時。

對於某些應用程式和服務，Istio 的預設逾時可能不適合。例如，逾時時間過長可能會因為等待失敗服務的回覆而導致過度的延遲，而逾時時間過短可能會因為等待涉及多個服務的作業傳回而導致不必要的呼叫失敗。若要尋找並使用最佳的逾時設定，Istio 可讓您使用虛擬服務，輕鬆地在每個服務的基礎上動態調整逾時，而無需編輯服務程式碼。以下是一個虛擬服務，指定呼叫評分服務 v1 子集的逾時時間為 10 秒。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s

重試

重試設定指定如果初始呼叫失敗，Envoy 代理程式嘗試連線到服務的最大次數。重試可以確保呼叫不會因為暫時性問題（例如暫時過載的服務或網路）而永久失敗，從而增強服務可用性和應用程式效能。重試之間的間隔 (25 毫秒以上) 是可變的，並由 Istio 自動決定，以防止呼叫的服務被請求淹沒。HTTP 請求的預設重試行為是在傳回錯誤之前重試兩次。

與逾時一樣，Istio 的預設重試行為在延遲（對失敗的服務進行過多次重試可能會減慢速度）或可用性方面可能不適合您的應用程式需求。同樣與逾時一樣，您可以在虛擬服務中，在每個服務的基礎上調整您的重試設定，而無需接觸您的服務程式碼。您還可以透過新增每次重試逾時來進一步精簡您的重試行為，指定您想要等待每次重試嘗試成功連線到服務的時間長度。以下範例設定在初始呼叫失敗後，最多重試 3 次連線到此服務子集，每次重試的逾時時間為 2 秒。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

斷路器

斷路器是 Istio 提供的另一個實用機制，可建立具備彈性的微服務型應用程式。在斷路器中，您可以設定對服務內個別主機呼叫的限制，例如並行連線數或對此主機呼叫失敗的次數。一旦達到該限制，斷路器就會「跳閘」並停止進一步連線到該主機。使用斷路器模式可以快速失敗，而不是讓用戶端嘗試連線到過載或失敗的主機。

由於斷路器適用於負載平衡集區中的「真實」網格目的地，因此您可以在目標規則中設定斷路器臨界值，設定會套用至服務中的每個個別主機。以下範例將 v1 子集的 reviews 服務工作負載的並行連線數限制為 100。

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

您可以在斷路中找到更多關於建立斷路器的資訊。

故障注入

在您設定好網路（包括故障恢復策略）之後，您可以使用 Istio 的錯誤注入機制來測試您應用程式整體的故障恢復能力。錯誤注入是一種測試方法，會將錯誤引入系統，以確保系統可以承受並從錯誤情況中復原。使用錯誤注入對於確保您的故障恢復策略不會不相容或限制過多特別有用，這可能會導致關鍵服務無法使用。

與其他引入錯誤的機制（例如延遲封包或在網路層終止 Pod）不同，Istio 可讓您在應用程式層注入錯誤。這可讓您注入更多相關的錯誤，例如 HTTP 錯誤碼，以獲得更相關的結果。

您可以注入兩種錯誤類型，兩種都使用虛擬服務設定：

• 延遲：延遲是時間錯誤。它們會模擬網路延遲增加或上游服務過載。
• 中止：中止是當機錯誤。它們會模擬上游服務中的失敗。中止通常以 HTTP 錯誤碼或 TCP 連線失敗的形式呈現。

例如，此虛擬服務會將傳送到 ratings 服務的每 1000 個請求中的 1 個請求延遲 5 秒。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

如需關於如何設定延遲和中止的詳細說明，請參閱錯誤注入。

與您的應用程式協同運作

Istio 故障恢復功能對於應用程式是完全透明的。應用程式不知道 Envoy Sidecar 代理程式是否正在為呼叫的服務處理故障，然後才傳回回應。這表示，如果您也在應用程式程式碼中設定故障恢復策略，則必須記住，兩者是獨立運作的，因此可能會發生衝突。例如，假設您有兩個逾時，一個是在虛擬服務中設定的，另一個是在應用程式中設定的。應用程式將對服務的 API 呼叫設定 2 秒的逾時時間。但是，您在虛擬服務中設定了 3 秒的逾時時間和 1 次重試。在這種情況下，應用程式的逾時會先啟動，因此您的 Envoy 逾時和重試嘗試無效。

雖然 Istio 故障恢復功能提高了網格中服務的可靠性和可用性，但應用程式必須處理故障或錯誤，並採取適當的後援動作。例如，當負載平衡集區中的所有執行個體都失敗時，Envoy 會傳回 HTTP 503 程式碼。應用程式必須實作處理 HTTP 503 錯誤碼所需的任何後援邏輯。