Envoy 是一個開源的邊緣服務代理，也是 Istio Service Mesh 默認的數據平面，專為云原生應用程序設計。

與HAProxy以及Nginx等傳統Proxy依賴靜態配置文件來定義各種資源以及數據轉發規則不同，Envoy幾乎所有配置都可以通過訂閱來動態獲取。對應的發現服務以及各種各樣的API統稱為xDS。Envoy與xDS之間通過Proto約定請求和響應的數據模型，不同類型資源，對應的數據模型也不同。

1 Envoy整體架構

Envoy 的架構如圖所示:

Envoy 中也可能有多個 Listener，每個 Listener 中可能會有多個 filter 組成了 chain。

Envoy 接收到請求后，會先走 FilterChain，通過各種 L3/L4/L7 Filter 對請求進行微處理，然后再路由到指定的集群，并通過負載均衡獲取一個目標地址，最后再轉發出去。

在Envoy中，具有最為核心的四種資源：Listener，Router，Cluster，以及Filter。

1.1 Listener：Envoy工作的基礎

簡單理解，Listener是Envoy打開的一個監聽端口，用于接收來自Downstream（客戶端）連接。Envoy可以支持復數個Listener。多個Listener之間幾乎所有的配置都是隔離的。Listener配置中核心包括監聽地址、Filter鏈等。

Listener對應的配置/資源發現服務稱之為LDS。LDS是Envoy正常工作的基礎，沒有LDS，Envoy就不能實現端口監聽（如果啟動配置也沒有提供靜態Listener的話），其他所有xDS服務也失去了作用。

1.2 Cluster：對上游服務的抽象

在Envoy中，每個Upstream上游服務都被抽象成一個Cluster。Cluster包含該服務的連接池、超時時間、endpoints地址、端口、類型（類型決定了Envoy獲取該Cluster具體可以訪問的endpoint方法）等等。

Cluster對應的配置/資源發現服務稱之為CDS。一般情況下，CDS服務會將其發現的所有可訪問服務全量推送給Envoy。與CDS緊密相關的另一種服務稱之為EDS。CDS服務負責Cluster資源的推送。而當該Cluster類型為EDS時，說明該Cluster的所有endpoints需要由xDS服務下發，而不使用DNS等去解析。下發endpoints的服務就稱之為EDS。

1.3 Router：上下游之間的橋梁

Listener可以接收來自下游的連接，Cluster可以將流量發送給具體的上游服務，而Router則決定Listener在接收到下游連接和數據之后，應該將數據交給哪一個Cluster處理。它定義了數據分發的規則。雖然說到Router大部分時候都可以默認理解為HTTP路由，但是Envoy支持多種協議，如Dubbo、Redis等，所以此處Router泛指所有用于橋接Listener和后端服務（不限定HTTP）的規則與資源集合。

Route對應的配置/資源發現服務稱之為RDS。Router中最核心配置包含匹配規則和目標Cluster，此外，也可能包含重試、分流、限流等等。

1.4 Filter：強大源于可擴展

Filter，通俗的講，就是插件。通過Filter機制，Envoy提供了極為強大的可擴展能力。

利用Filter機制，Envoy理論上可以實現任意協議的支持以及協議之間的轉換，可以對請求流量進行全方位的修改和定制。強大的Filter機制帶來的不僅僅是強大的可擴展性，同時還有優秀的可維護性。Filter機制讓Envoy的使用者可以在不侵入社區源碼的基礎上對Envoy做各個方面的增強。

• 網絡過濾器（Network Filters）: 工作在 L3/L4，是 Envoy 網絡連接處理的核心，處理的是原始字節，分為 Read、Write 和 Read/Write 三類。
• HTTP 過濾器（HTTP Filters）: 工作在 L7，由特殊的網絡過濾器 HTTP connection manager 管理，專門處理 HTTP1/HTTP2/gRPC 請求。它將原始字節轉換成 HTTP 格式，從而可以對 HTTP 協議進行精確控制。

2 配置

Envoy流程中每一個環節可以靜態配置，也可以動態服務發現。

2.1 靜態配置

下面的配置將所有流量代理到 baidu.com，配置完成后我們應該能夠通過請求 Envoy 的端點就可以直接看到百度的主頁了，而無需更改 URL 地址。

static_resources:# 1. 監聽器listeners:- name: listener_0address:socket_address: { address: 0.0.0.0, port_value: 10000 }# 2. 過濾器filter_chains:- filters:- name: envoy.http_connection_managerconfig:stat_prefix: ingress_httproute_config:name: local_routevirtual_hosts:- name: local_servicedomains: ["*"]routes:- match: { prefix: "/" }route: { host_rewrite: www.baidu.com, cluster: service_baidu }http_filters:- name: envoy.router# 3. 集群clusters:- name: service_baiduconnect_timeout: 0.25stype: LOGICAL_DNSdns_lookup_family: V4_ONLYlb_policy: ROUND_ROBINhosts: [{ socket_address: { address: www.baidu.com, port_value: 443 }}]tls_context: { sni: baidu.com }# 4. 管理 admin:access_log_path: /tmp/admin_access.logaddress:socket_address: { address: 0.0.0.0, port_value: 9901 }

2.2 動態配置xDS協議（動態服務發現）

Envoy 通過查詢文件或管理服務器來動態發現資源。這些發現服務及其相應的 API 被統稱為 xDS。

Envoy 通過訂閱（subscription）方式來獲取資源，如監控指定路徑下的文件、啟動 gRPC 流（streaming）或輪詢 REST-JSON URL。后兩種方式會發送 DiscoveryRequest 請求消息，發現的對應資源則包含在響應消息 DiscoveryResponse 中。

xDS 協議是 “X Discovery Service” 的簡寫，這里的 “X” 表示它不是指具體的某個協議，是一組基于不同數據源的服務發現協議的總稱：

• CDS：Cluster Discovery Service
• EDS：Endpoint Discovery Service
• SDS：Secret Discovery Service
• RDS：Route Discovery Service
• LDS：Listener Discovery Service

xDS 協議是由 Envoy 提出的，目前已成為服務網格的協議標準之一。

Envoy是 Istio 中默認的 sidecar 代理，但只要實現了 xDS 協議，理論上也可以作為 Istio 中的 sidecar 代理 —— 比如螞蟻集團開源的 MOSN。

比如每個 Envoy 流以發送一個 DiscoveryRequest 開始，包括了列表訂閱的資源、訂閱資源對應的類型 URL、節點標識符和空的 version_info。EDS 請求示例如下：

version_info: node: { id: envoy } resource_names: - foo - bar type_url: type.googleapis.com/envoy.api.v2.ClusterLoadAssignment response_nonce

管理服務器可立刻或等待資源就緒時發送 DiscoveryResponse 作為響應，示例如下：

version_info: X resources: - foo ClusterLoadAssignment proto encoding - bar ClusterLoadAssignment proto encoding type_url: type.googleapis.com/envoy.api.v2.ClusterLoadAssignment nonce: A

參考

Envoy 入門教程
https://www.envoyproxy.io/docs/envoy/v1.18.3/

總結

以上是生活随笔為你收集整理的Envoy架构理解--理解xDS/Listener/Cluster/Router/Filter的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。