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

時間 2021-02-18

標籤 node 算法編程 json 後端 api 緩存安全服務器網絡欄目系統架構简体版

原文原文鏈接

做者 | 王夕寧阿里巴巴高級技術專家node

參與「阿里巴巴雲原生」公衆號文末留言互動，即有機會得到贈書福利！算法

本文摘自於由阿里雲高級技術專家王夕寧撰寫的《Istio 服務網格技術解析與實踐》一書，文章從基礎概念入手，介紹了什麼是服務網格及 Istio，針對 2020 服務網格的三大發展趨勢，體系化、全方位地介紹了 Istio 服務網格的相關知識。你只需開心參與文末互動，咱們負責買單！技術人必備書籍《Istio 服務網格技術解析與實踐》免費領~編程

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

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

(Istio 架構)api

做爲代理，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 年服務網格將成爲全部領先的容器管理系統的標配技術。本書適合全部對微服務和雲原生感興趣的讀者，推薦你們對本書進行深刻的閱讀。

參與公衆號留言互動，即有機會獲取下列福利！