Service Mesh 最火專案 Istio 分層架構，你真的瞭解嗎？

作者 | 王夕寧 阿里巴巴高階技術專家

本文摘自於由阿里雲高階技術專家王夕寧撰寫的《Istio 服務網格技術解析與實踐》一書，文章從基礎概念入手，介紹了什麼是服務網格及 Istio，針對 2020 服務網格的三大發展趨勢，體系化、全方位地介紹了 Istio 服務網格的相關知識。

參與“阿里巴巴雲原生”公眾號文末留言互動，技術人必備書籍《Istio 服務網格技術解析與實踐》免費領~

Istio 是一個開源的服務網格，可為分散式微服務架構提供所需的基礎執行和管理要素。隨著各組織越來越多地採用雲平臺，開發者必須使用微服務設計架構以實現可移植性，而運維人員必須管理包含混合雲部署和多雲部署的大型分散式應用。Istio 採用一種一致的方式來保護、連線和監控微服務，降低了管理微服務部署的複雜性。

從架構設計上來看，Istio 服務網格在邏輯上分為控制平面和資料平面兩部分。其中，控制平面 Pilot 負責管理和配置代理來路由流量，並配置 Mixer 以實施策略和收集遙測資料；資料平面由一組以 Sidecar 方式部署的智慧代理（Envoy）組成，這些代理可以調節和控制微服務及 Mixer 之間所有的網路通訊。

（Istio 架構）

作為代理，Envoy 非常適合服務網格的場景，但要發揮 Envoy 的最大價值，就需要使它很好地與底層基礎設施或元件緊密配合。Envoy 構成了服務網格的資料平面，Istio 提供的支撐元件則是建立了控制平面。

（Pilot 與 Envoy 資料平面）

一方面，我們在 Envoy 中看到，可以使用靜態配置檔案或使用一組發現服務來配置一組服務代理，以便在執行時發現監聽器、端點和叢集。Istio 在 Pilot 中實現了這些 Envoy 代理的 xDS API。

另一方面，Envoy 的服務發現依賴於某種服務登錄檔來發現服務端點。Istio Pilot 實現了這個 API，但也將 Envoy 從任何特定的服務註冊實現中抽象出來。當 Istio 部署在 Kubernetes 上時，Kubernetes 的服務登錄檔是 Istio 用於服務發現的。其它登錄檔也可以像 HashiCorp 的 Consul 那樣使用。Envoy 資料平面完全不受這些實施細節的影響。

（Mixer 架構）

此外，Envoy 代理可以發出很多指標和遙測資料，這些遙測資料傳送到何處，取決於 Envoy 的配置。Istio 提供遙測接收器 Mixer 作為其控制平面的一部分，Envoy 代理可以將這些資料傳送到 Mixer。Envoy 還將分散式跟蹤資料傳送到開放式跟蹤引擎（遵循 Open Tracing API）。Istio 可以支援相容的開放式跟蹤引擎並配置 Envoy 將其跟蹤資料傳送到該位置。

剖析 Istio 控制平面

Istio 的控制平面和 Envoy 的資料平面共同構成了一個引人注目的服務網格實現。兩者都擁有蓬勃發展和充滿活力的社群，並且面向下一代服務架構。Istio 是獨立於平臺的，可運行於各種環境中，包括跨雲、內部部署、Kubernetes、Mesos 等。你可以在 Kubernetes 上部署 Istio 或在具有 Consul 的 Nomad 上部署。Istio 目前支援在 Kubernetes 上部署的服務、使用 Consul 註冊的服務以及在虛擬機器上部署的服務。

其中，控制平面部分包括了 Pilot、Mixer、Citadel 和 Galley 四個元件。參見 Istio 架構一圖。

1。 Pilot

Istio 的 Pilot 元件用於管理流量，可以控制服務之間的流量流動和 API 呼叫，透過 Pilot 可以更好地瞭解流量，以便在問題出現之前發現問題。這使得呼叫更加可靠、網路更加強健，即使遇到不利條件也能讓應用穩如磐石。藉助 Istio 的 Pilot，你能夠配置熔斷器、超時和重試等服務級屬性，並設定常見的連續部署任務，如金絲雀釋出、A/B 測試和基於百分比拆分流量的分階段釋出。Pilot 為 Envoy 代理提供服務發現功能，為智慧路由和彈效能力（如超時、重試、熔斷器等）提供流量管理功能。Pilot 將控制流量行為的高階路由規則轉換為特定於 Envoy 代理的配置，並在執行時將它們傳播到 Envoy。此外，Istio 提供了強大的開箱即用故障恢復功能，包括超時、支援超時預算和變數抖動的重試機制、發往上游服務的併發連線和請求數限制、對負載均衡池中的每個成員進行的定期主動執行狀況檢查，以及被動執行狀況檢查。

Pilot 將平臺特定的服務發現機制抽象化並將其合成為標準格式，符合資料平面 API 的任何 Sidecar 都可以使用這種標準格式。這種鬆散耦合使得 Istio 能夠在多種環境下執行（例如 Kubernetes、Consul、Nomad），同時可保持用於流量管理的操作介面相同。

2。 Mixer

Istio 的 Mixer 元件提供策略控制和遙測收集功能，將 Istio 的其餘部分與各個後端基礎設施後端的實現細節隔離開來。Mixer 是一個獨立於平臺的元件，負責在服務網格上執行訪問控制和使用策略，並從 Envoy 代理和其他服務收集遙測資料。代理提取請求級屬性，傳送到 Mixer 進行評估。

Mixer 中包括一個靈活的外掛模型，使其能夠接入到各種主機環境和後端基礎設施，從這些細節中抽象出 Envoy 代理和 Istio 管理的服務。利用 Mixer，你可以精細控制網格和後端基礎設施後端之間的所有互動。

與必須節省記憶體的 Sidecar 代理不同，Mixer 獨立執行，因此它可以使用相當大的快取和輸出緩衝區，充當 Sidecar 的高度可伸縮且高度可用的二級快取。

Mixer 旨在為每個例項提供高可用性。它的本地快取和緩衝區可以減少延遲時間，還有助於遮蔽後端基礎設施後端故障，即使後端沒有響應也是如此。

3。 Citadel

Istio Citadel 安全功能提供強大的身份驗證功能、強大的策略、透明的 TLS 加密以及用於保護服務和資料的身份驗證、授權和審計（AAA）工具，Envoy 可以終止或向網格中的服務發起 TLS 流量。為此，Citadel 需要支援建立、簽署和輪換證書。Istio Citadel 提供特定於應用程式的證書，可用於建立雙向 TLS 以保護服務之間的流量。

（Istio Citadel 架構）

藉助 Istio Citadel，確保只能從經過嚴格身份驗證和授權的客戶端訪問包含敏感資料的服務。Citadel 透過內建身份和憑證管理提供了強大的服務間和終端使用者身份驗證。可用於升級服務網格中未加密的流量，併為運維人員提供基於服務標識而不是網路控制的強制執行策略的能力。Istio 的配置策略在伺服器端配置平臺身份驗證，但不在客戶端強制實施該策略，同時允許你指定服務的身份驗證要求。Istio 的金鑰管理系統可自動生成、分發、輪換與撤銷金鑰和證書。

Istio RBAC 為 Istio 網格中的服務提供名稱空間級別、服務級別和方法級別的訪問許可權控制，包括易於使用的基於角色的語義、服務到服務和終端使用者到服務的授權，並在角色和角色繫結方面提供靈活的自定義屬性支援。

Istio 可以增強微服務及其通訊（包括服務到服務和終端使用者到服務的通訊）的安全性，且不需要更改服務程式碼。它為每個服務提供基於角色的強大身份機制，以實現跨叢集、跨雲端的互動操作。

4。 Galley

Galley 用於驗證使用者編寫的 Istio API 配置。隨著時間的推移，Galley 將接管 Istio 獲取配置、處理和分配元件的頂級責任。它負責將其他的 Istio 元件與從底層平臺（例如 Kubernetes）獲取使用者配置的細節中隔離開來。

總而言之，透過 Pilot，Istio 可在部署規模逐步擴大的過程中幫助你簡化流量管理。透過 Mixer，藉助強健且易於使用的監控功能，能夠快速有效地檢測和修復問題。透過 Citadel，減輕安全負擔，讓開發者可以專注於其他關鍵任務。

Istio 的架構設計中有幾個關鍵目標，這些目標對於系統應對大規模流量和高效能的服務處理至關重要。

最大化透明度：

要採用 Istio，應該讓運維和開發人員只需付出很少的代價就可以從中獲得實際價值。為此，Istio 將自身自動注入到服務間所有的網路路徑中。Istio 使用 Envoy 代理來捕獲流量，並且在可能的情況下自動對網路層進行程式設計，以便透過這些代理路由流量，而無需對已部署的應用程式程式碼進行太多的更改，甚至不需要任何更改。在 Kubernetes 中，Envoy 代理被注入到 pod 中，透過 iptables 規則來捕獲流量。一旦注入 Envoy 代理到 pod 中並且修改路由規則，Istio 就能夠調節所有流量。這個原則也適用於效能。當將 Istio 用於部署時，運維人員可以發現，為提供這些功能而增加的資源開銷是很小的。所有元件和 API 在設計時都必須考慮效能和規模。

可擴充套件性：

隨著運維人員和開發人員越來越依賴 Istio 提供的功能，系統必然和他們的需求一起成長。在我們繼續新增新功能的同時，最需要的是能夠擴充套件策略系統，整合其他策略和控制來源，並將網格行為訊號傳播到其他系統進行分析。策略執行時支援標準擴充套件機制以便插入到其他服務中。此外，它允許擴充套件詞彙表，以允許基於網格生成的新訊號來強制執行策略。

可移植性：

使用 Istio 的生態系統在很多方面都有所不同。Istio 必須能夠以最少的代價執行在任何雲或本地環境中。將基於 Istio 的服務移植到新環境應該是輕而易舉的，而使用 Istio 將一個服務同時部署到多個環境中也是可行的，例如可以在混合雲上部署以實現冗餘災備。

策略一致性：

策略應用於服務之間的 API 呼叫，可以很好地控制網格行為。但對於無需在 API 級別表達的資源來說，對資源應用策略也同樣重要。例如，將配額應用到機器學習訓練任務消耗的 CPU 數量上，比將配額應用到啟動這個工作的呼叫上更為有用。因此，Istio 將策略系統維護為具有自己的 API 的獨特服務，而不是將其放到代理中，這允許服務根據需要直接與其整合。

剖析 Istio 資料平面

當介紹服務網格的概念時，提到了服務代理的概念以及如何使用代理構建一個服務網格，以調節和控制微服務之間的所有網路通訊。Istio 使用 Envoy 代理作為預設的開箱即用服務代理，這些 Envoy 代理與參與服務網格的所有應用程式例項一起執行，但不在同一個容器程序中，形成了服務網格的資料平面。只要應用程式想要與其他服務通訊，就會透過服務代理 Envoy 進行。由此可見，Envoy 代理是資料平面和整個服務網格架構中的關鍵組成部分。

1。 Envoy 代理

Envoy 最初是由 Lyft 開發的，用於解決構建分散式系統時出現的一些複雜的網路問題。它於 2016 年 9 月作為開源專案提供，一年後加入了雲原生計算基金會（CNCF）。Envoy 是用 C++ 語言實現的，具有很高的效能，更重要的是，它在高負載執行時也非常穩定和可靠。網路對應用程式來說應該是透明的，當網路和應用程式出現問題時，應該很容易確定問題的根源。正是基於這樣的一種設計理念，將 Envoy 設計為一個面向服務架構的七層代理和通訊匯流排。

為了更好地理解 Envoy，我們需要先搞清楚相關的幾個基本術語：

程序外（Out of Process）架構：

Envoy 是一個獨立程序，Envoy 之間形成一個透明的通訊網格，每個應用程式傳送訊息到本地主機或從本地主機接收訊息，但無需關心網路拓撲。

單程序多執行緒模型：

Envoy 使用了單程序多執行緒的架構模型。一個主執行緒管理各種瑣碎的任務，而一些工作子執行緒則負責執行監聽、過濾和轉發功能。

下游（Downstream）：

連線到 Envoy 併發送請求、接收響應的主機叫下游主機，也就是說下游主機代表的是傳送請求的主機。

上游（Upstream）：

與下游相對，接收請求的主機叫上游主機。

監聽器（Listener）：

監聽器是命名網路地址，包括埠、unix domain socket 等，可以被下游主機連線。Envoy 暴露一個或者多個監聽器給下游主機連線。每個監聽器都獨立配置一些網路級別（即三層或四層）的過濾器。當監聽器接收到新連線時，配置好的本地過濾器將被例項化，並開始處理後續事件。一般來說監聽器架構用於執行絕大多數不同的代理任務，例如限速、TLS 客戶端認證、HTTP 連線管理、MongoDB sniff？ing、原始 TCP 代理等。

叢集（Cluster）：

叢集是指 Envoy 連線的一組邏輯相同的上游主機。

xDS 協議：

在 Envoy 中 xDS 協議代表的是多個發現服務協議，包括叢集發現服務（CDS，

Cluster Discovery Service）、監聽器發現服務（LDS，Listener Discovery Service）、路由發現服務（RDS，Route Discovery Service）、端點發現服務（EDS，Endpoint Discovery Service），以及金鑰發現服務（SDS，Secret Discovery Service）。

（Envoy 代理）

Envoy 代理有許多功能可用於服務間通訊，例如，暴露一個或者多個監聽器給下游主機連線，透過埠暴露給外部的應用程式；透過定義路由規則處理監聽器中傳輸的流量，並將該流量定向到目標叢集，等等。後續章節會進一步分析這幾個發現服務在 Istio 中的角色和作用。

在瞭解了 Envoy 的術語之後，你可能想盡快知道 Envoy 到底起到了什麼作用？

首先，Envoy 是一種代理，在網路體系架構中扮演著中介的角色，可以為網路中的流量管理新增額外的功能，包括提供安全性、隱私保護或策略等。在服務間呼叫的場景中，代理可以為客戶端隱藏服務後端的拓撲細節，簡化互動的複雜性，並保護後端服務不會過載。例如，後端服務實際上是執行的一組相同例項，每個例項能夠處理一定量的負載。

其次，Envoy 中的叢集（Cluster）本質上是指 Envoy 連線到的邏輯上相同的一組上游主機。那麼客戶端如何知道在與後端服務互動時要使用哪個例項或 IP 地址？Envoy 作為代理起到了路由選擇的作用，透過服務發現（SDS，Service Discovery Service），Envoy 代理發現叢集中的所有成員，然後透過主動健康檢查來確定叢集成員的健康狀態，並根據健康狀態，透過負載均衡策略決定將請求路由到哪個叢集成員。而在 Envoy 代理處理跨服務例項的負載均衡過程中，客戶端不需要知道實際部署的任何細節。

2。 Envoy 的啟動配置

Envoy 目前提供了兩個版本的 API，即 v1 和 v2，從 Envoy 1。5。0 起就有 v2 API 了，為了能夠讓使用者順利地向 v2 版本 API 遷移，Envoy 啟動的時候設定了一個引數——v2-conf？ig-only。透過這個引數，可以明確指定 Envoy 使用 v2 API 的協議。幸運的是，v2 API 是 v1 的一個超集，相容 v1 的 API。在當前的 Istio 1。0 之後的版本中，明確指定了其支援 v2 的 API。透過檢視使用 Envoy 作為 Sidecar 代理的容器啟動命令，可以看到如下類似的啟動引數，其中指定了引數——v2-conf？ig-only：

$ /usr/local/bin/envoy -c

/etc/istio/proxy/envoy-rev0。json ——restart-epoch 0 ——drain-time-s 45

——parent-shutdown-time-s 60 ——service-cluster ratings ——service-node

sidecar~172。33。14。2~ratings-v1-8558d4458d-ld8x9。default~default。svc。cluster。local

——max-obj-name-len 189 ——allow-unknown-fields -l warn ——v2-config-only

其中，引數 -c 表示的是基於版本 v2 的引導配置檔案的路徑，格式為 JSON，也支援其他格式，如 YAML、Proto3等。它會首先作為版本 v2 的引導配置檔案進行解析，若解析失敗，會根據 ［——v2-conf？ig-only］ 選項決定是否作為版本 v1 的 JSON 配置檔案進行解析。其他引數解釋如下，以便讀者及時理解 Envoy 代理啟動時的配置資訊：

restart-epoch 表示熱重啟週期，對於第一次啟動預設為 0，每次熱重啟後都應該增加它。

service-cluster 定義 Envoy 執行的本地服務叢集名稱。

service-node 定義 Envoy 執行的本地服務節點名稱。

drain-time-s 表示熱重啟期間 Envoy 將耗盡連線的時間（秒），預設為 600 秒（10 分鐘）。通常耗盡時間應小於透過 ——parent-shutdown-time-s 選項設定的父程序關閉時間。

parent-shutdown-time-s 表示 Envoy 在熱重啟時關閉父程序之前等待的時間（秒）。

max-obj-name-len 描述的是叢集 cluster、路由配置 route_conf？ig 以及監聽器 listener 中名稱欄位的最大長度，以位元組為單位。此選項通常用於自動生成叢集名稱的場景，通常會超過 60 個字元的內部限制。預設為 60。

Envoy 的啟動配置檔案分為兩種方式：靜態配置和動態配置。具體表現為：

靜態配置是將所有資訊都放在配置檔案中，啟動的時候直接載入。

動態配置需要提供一個 Envoy 的服務端，用於動態生成 Envoy 需要的服務發現介面，也就是通常說的 xDS，透過發現服務來動態調整配置資訊，Istio 實現了 v2 的 xDS API。

3。 Envoy 靜態與動態配置

Envoy 是由 JSON 或 YAML 格式的配置檔案驅動的智慧代理，對於已經熟悉 Envoy 或 Envoy 配置的使用者來說，相信應該已經知道了 Envoy 的配置也有不同的版本。初始版本 v1 是 Envoy 啟動時配置 Envoy 的原始方式。此版本已被棄用，以支援 Envoy 配置的 v2 版本。Envoy 的參考文件（

https：//www。

envoyproxy。io/docs

）還提供了明確區分 v1 和 v2 的文件。本文將只關注 v2 配置，因為它是最新的版本，也是 Istio 使用的版本。

Envoy 版本 v2 的配置 API 建立在 gRPC 之上，v2 API 的一個重要特性是可以在呼叫 API 時利用流功能來減少 Envoy 代理匯聚配置所需的時間。實際上，這也消除了輪詢 API 的弊端，允許伺服器將更新推送到 Envoy 代理，而不是定期輪詢代理。

Envoy 的架構使得使用不同型別的配置管理方法成為可能。部署中採用的方法將取決於實現者的需求。簡單部署可以透過全靜態配置來實現，更復雜的部署可以遞增地新增更復雜的動態配置。主要分為以下幾種情況：

全靜態：在全靜態配置中，實現者提供一組監聽器和過濾器鏈、叢集和可選的 HTTP 路由配置。動態主機發現僅能透過基於 DNS 的服務發現。配置過載必須透過內建的熱重啟機制進行。

僅SDS/EDS：在靜態配置之上，Envoy 可以透過該機制發現上游叢集中的成員。

SDS/EDS 和 CDS：Envoy 可以透過該機制發現使用的上游叢集。

SDS/EDS、CDS 和 RDS：RDS 可以在執行時發現用於 HTTP 連線管理器過濾器的整個路由配置。

SDS/EDS、CDS、RDS 和 LDS：LDS 可以在執行時發現整個監聽器。這包括所有的過濾器堆疊，包括帶有內嵌到 RDS 的應用的 HTTP 過濾器。

靜態配置

我們可以使用 Envoy 的配置檔案指定監聽器、路由規則和叢集。如下示例提供了一個非常簡單的 Envoy 配置：

static_resources：

listeners：

- name： httpbin-demo

address：

socket_address： { address： 0。0。0。0， port_value： 15001 }

filter_chains：

- filters：

- name： envoy。http_connection_manager

config：

stat_prefix： egress_http

route_config：

name： httpbin_local_route

virtual_hosts：

- name： httpbin_local_service

domains： ［“*”］

routes：

- match： { prefix： “/”

}

route：

auto_host_rewrite： true

cluster： httpbin_service

http_filters：

- name： envoy。router

clusters：

- name： httpbin_service

connect_timeout： 5s

type： LOGICAL_DNS

# Comment out the following line to test on v6 networks

dns_lookup_family： V4_ONLY

lb_policy： ROUND_ROBIN

hosts： ［{ socket_address： { address： httpbin， port_value： 8000 }}］

在這個簡單的 Envoy 配置檔案中，我們聲明瞭一個監聽器，它在埠 15001 上開啟一個套接字併為其附加一個過濾器鏈。過濾器 http_connection_manager 在 Envoy 配置中使用路由指令（在此示例中看到的簡單路由指令是匹配所有虛擬主機的萬用字元），並將所有流量路由到 httpbin_service 叢集。配置的最後一部分定義了 httpbin_service 叢集的連線屬性。在此示例中，我們指定端點服務發現的型別為 LOGICAL_DNS、與上游 httpbin 服務通訊時的負載均衡演算法為 ROUND_ROBIN。

這是一個簡單的配置檔案，用於建立監聽器傳入的流量，並將所有流量路由到 httpbin 叢集。它還指定要使用的負載均衡演算法的設定以及要使用的連線超時配置。

你會注意到很多配置是明確指定的，例如指定了哪些監聽器，路由規則是什麼，我們可以路由到哪些叢集等。這是完全靜態配置檔案的示例。

有關這些引數更多資訊的解釋，請參閱 Envoy 的文件（

http：//www。

envoyproxy。io/docs/envo

y/latest/intro/arch_overview/service_discovery#logical-dns

）。

在前面的部分中，我們指出 Envoy 能夠動態配置其各種設定。下面將介紹 Envoy 的動態配置以及 Envoy 如何使用 xDS API 進行動態配置。

動態配置

Envoy 可以利用一組 API 進行配置更新，而無需任何停機或重啟。Envoy 只需要一個簡單的引導配置檔案，該配置檔案將配置指向正確的發現服務 API，其餘動態配置。Envoy 進行動態配置的 API 通常統稱為 xDS 服務，具體包括如下：

監聽器發現服務（LDS）：

一種允許 Envoy 查詢整個監聽器的機制，透過呼叫該 API 可以動態新增、修改或刪除已知監聽器；每個監聽器都必須具有唯一的名稱。如果未提供名稱，Envoy 將建立一個 UUID。

路由發現服務（RDS）：

Envoy 動態獲取路由配置的機制，路由配置包括 HTTP 標頭修改、虛擬主機以及每個虛擬主機中包含的單個路由規則。每個 HTTP 連線管理器都可以透過 API 獨立地獲取自身的路由配置。RDS 配置隸屬於監聽器發現服務 LDS 的一部分，是 LDS 的一個子集，用於指定何時應使用靜態和動態配置，以及指定使用哪個路由。

叢集發現服務（CDS）：

一個可選的 API，Envoy 將呼叫該 API 來動態獲取叢集管理成員。Envoy 還將根據 API 響應協調叢集管理，根據需要新增、修改或刪除已知的叢集。在 Envoy 配置中靜態定義的任何叢集都不能透過 CDS API 進行修改或刪除。

端點發現服務（EDS）：

一種允許 Envoy 獲取叢集成員的機制，基於 gRPC 或 RESTJSON 的 API，它是 CDS 的一個子集；叢集成員在 Envoy 術語中稱為端點（Endpoint）。對於每個叢集，Envoy 從發現服務獲取端點。EDS 是首選的服務發現機制。

金鑰發現服務（SDS）：

用於分發證書的 API；SDS 最重要的好處是簡化證書管理。如果沒有此功能，在 Kubernetes 部署中，必須將證書建立為金鑰並掛載到 Envoy 代理容器中。如果證書過期，則需要更新金鑰並且需要重新部署代理容器。使用金鑰發現服務 SDS，那麼 SDS 伺服器會將證書推送到所有 Envoy 例項。如果證書過期，伺服器只需將新證書推送到 Envoy 例項，Envoy 將立即使用新證書而無需重新部署。

聚合發現服務（ADS）：

上述其他 API 的所有更改的序列化流；你可以使用此單個 API 按順序獲取所有更改；ADS 並不是一個實際意義上的 xDS，它提供了一個匯聚的功能，在需要多個同步 xDS 訪問的時候，ADS 可以在一個流中完成。

配置可以使用上述服務中的一個或其中幾個的組合，不必全部使用它們。需要注意的一點是，Envoy 的 xDS API 是建立在最終一致性的前提下，正確的配置最終會收斂。例如，Envoy 最終可能會使用新路由獲取RDS的更新，該路由將流量路由到尚未在 CDS 中更新的叢集。這意味著，路由可能會引入路由錯誤，直到更新 CDS。Envoy 引入了聚合發現服務 ADS 來解決這種問題，而 Istio 實現了聚合發現服務 ADS，並使用 ADS 進行代理配置的更改。

例如，Envoy 代理要動態發現監聽器，可以使用如下配置：

dynamic_resources：

lds_config：

api_config_source：

api_type： GRPC

grpc_services：

- envoy_grpc：

cluster_name： xds_cluster

clusters：

- name： xds_cluster

connect_timeout： 0。25s

type： STATIC

lb_policy： ROUND_ROBIN

http2_protocol_options： {}

hosts： ［{ socket_address： { address： 127。0。0。3， port_value： 5678 }}］

透過上面的配置，我們不需要在配置檔案中顯式配置每個監聽器。我們告訴 Envoy 使用 LDS API 在執行時發現正確的監聽器配置值。但是，我們需要明確配置一個叢集，這個叢集就是 LDS API 所在的位置，也就是該示例中定義的叢集 xds_cluster。

在靜態配置的基礎上，比較直觀地表示出各個發現服務所提供的資訊。

（xDS 服務資訊）

在靜態配置的基礎上，比較直觀地表示出各個發現服務所提供的資訊。

本文摘自於《Istio 服務網格解析與實戰》，經出版方授權釋出。本書由阿里雲高階技術專家王夕寧撰寫，詳細介紹 Istio 的基本原理與開發實戰，包含大量精選案例和參考程式碼可以下載，可快速入門 Istio 開發。Gartner 認為，2020 年服務網格將成為所有領先的容器管理系統的標配技術。本書適合所有對微服務和雲原生感興趣的讀者，推薦大家對本書進行深入的閱讀。

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”