作者 | 王夕寧 阿里巴巴高級技術專家
參與“阿里巴巴雲原生”公衆號文末留言互動，即有機會獲得贈書福利！
本文摘自於由阿里雲高級技術專家王夕寧撰寫的《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 的文檔（www.envoyproxy.io/docs/envoy/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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆號。”