當前位置：首頁 >

Service Mesh 最火项目 Istio 分层架构，你真的了解吗？

發布時間：2025/3/20 31 豆豆

生活随笔收集整理的這篇文章主要介紹了 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-demoaddress:socket_address: { address: 0.0.0.0, port_value: 15001 }filter_chains:- filters:- name: envoy.http_connection_managerconfig:stat_prefix: egress_httproute_config:name: httpbin_local_routevirtual_hosts:- name: httpbin_local_servicedomains: ["*"]routes:- match: { prefix: "/" }route:auto_host_rewrite: truecluster: httpbin_servicehttp_filters:- name: envoy.routerclusters:- name: httpbin_serviceconnect_timeout: 5stype: LOGICAL_DNS# Comment out the following line to test on v6 networksdns_lookup_family: V4_ONLYlb_policy: ROUND_ROBINhosts: [{ 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: GRPCgrpc_services:- envoy_grpc:cluster_name: xds_cluster clusters: - name: xds_clusterconnect_timeout: 0.25stype: STATIClb_policy: ROUND_ROBINhttp2_protocol_options: {}hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

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

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

（xDS?服務信息）