# Envoy 的架構與基本術語 **注意：本書中的 Service Mesh 章節已不再維護，請轉到 [istio-handbook](https://jimmysong.io/istio-handbook) 中瀏覽。** 在了解一門技術之前一開始就要了解其中的基本概念和術語，只有融入了該語境才能理解這門技術。本文將為大家介紹 Envoy 中的基本術語和重點概念。 ## 架構 下圖是 Envoy proxy 的架構圖，顯示了 host B 經過 Envoy 訪問 host A 的過程。每個 host 上都可能運行多個 service，Envoy 中也可能有多個 Listener，每個 Listener 中可能會有多個 filter 組成了 chain。  其中的基本術語將在下面解釋。 ## 基本術語 **Host**：能夠進行網絡通信的實體（在手機或服務器等上的應用程序）。在 Envoy 中主機是指邏輯網絡應用程序。只要每臺主機都可以獨立尋址，一塊物理硬件上就運行多個主機。 **Downstream**：下游（downstream）主機連接到 Envoy，發送請求并或獲得響應。 **Upstream**：上游（upstream）主機獲取來自 Envoy 的鏈接請求和響應。 **Cluster**: 集群（cluster）是 Envoy 連接到的一組邏輯上相似的上游主機。Envoy 通過[服務發現](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#arch-overview-service-discovery)發現集群中的成員。Envoy 可以通過[主動運行狀況檢查](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/health_checking#arch-overview-health-checking)來確定集群成員的健康狀況。Envoy 如何將請求路由到集群成員由負載均衡策略確定。 **Mesh**：一組互相協調以提供一致網絡拓撲的主機。Envoy mesh 是指一組 Envoy 代理，它們構成了由多種不同服務和應用程序平臺組成的分布式系統的消息傳遞基礎。 **運行時配置**：與 Envoy 一起部署的帶外實時配置系統。可以在無需重啟 Envoy 或 更改 Envoy 主配置的情況下，通過更改設置來影響操作。 **Listener**: 偵聽器（listener）是可以由下游客戶端連接的命名網絡位置（例如，端口、unix域套接字等）。Envoy 公開一個或多個下游主機連接的偵聽器。一般是每臺主機運行一個 Envoy，使用單進程運行，但是每個進程中可以啟動任意數量的 Listener（監聽器），目前只監聽 TCP，每個監聽器都獨立配置一定數量的（L3/L4）網絡過濾器。Listenter 也可以通過 Listener Discovery Service（**LDS**）動態獲取。 **Listener filter**：Listener 使用 listener filter（監聽器過濾器）來操作鏈接的元數據。它的作用是在不更改 Envoy 的核心功能的情況下添加更多的集成功能。Listener filter 的 API 相對簡單，因為這些過濾器最終是在新接受的套接字上運行。在鏈中可以互相銜接以支持更復雜的場景，例如調用速率限制。Envoy 已經包含了多個監聽器過濾器。 **Http Route Table**：HTTP 的路由規則，例如請求的域名，Path 符合什么規則，轉發給哪個 Cluster。 **Health checking**：健康檢查會與SDS服務發現配合使用。但是，即使使用其他服務發現方式，也有相應需要進行主動健康檢查的情況。詳見 [health checking](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/health_checking)。 ## xDS xDS 是一個關鍵概念，它是一類發現服務的統稱，其包括如下幾類： - CDS：Cluster Discovery Service - EDS：Endpoint Discovery Service - SDS：Service Discovery Service - RDS：Route Discovery Service - LDS：Listener Discovery Service 正是通過對 xDS 的請求來動態更新 Envoy 配置。 ## Envoy Mesh Envoy Mesh 指的是由 envoy 做負載均衡和代理的 mesh。該 Mesh 中會包含兩類 envoy： - Edge envoy：即流量進出 mesh 時候的 envoy，相當于 kubernetes 中的 ingress。 - Service envoy：服務 envoy 是跟每個 serivce 實例一起運行的，應用程序無感知的進程外工具，在 kubernetes 中會與應用容器以 sidecar 形式運行在同一個 pod 中。 Envoy 即可以單獨作為 edge envoy，也可以僅做 service envoy 使用，也可以兩者同時使用。Mesh 中的所有 envoy 會共享路由信息。 ## Envoy 配置 Envoy 中的配置包括兩大類：listenner 配置和 cluster 配置。 ### Listener 配置 我們知道 Envoy 中可以配置一組 listener 以實現復雜的處理邏輯。Listener 中設置監聽的 TCP 端口，還有一組 filter 對這些端口上的數據流進行處理。如下所示，該示例來自[使用Envoy 作為前端代理](envoy-front-proxy.md)。 ```yaml listeners: - address: socket_address: address: 0.0.0.0 port_value: 80 filter_chains: - filters: - name: envoy.http_connection_manager config: codec_type: auto stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: - "*" routes: - match: prefix: "/service/1" route: cluster: service1 - match: prefix: "/service/2" route: cluster: service2 ``` 這是一個 `http_connection_manager` 例子，其中必須包含 `virtual_hosts` 配置，而 `virtual_hosts` 配置中必須包含以下幾項配置： - `name`：服務名稱 - `domains`：DNS 域名，必須能跟 `virtual_host` 的 URL 匹配 - `routes`：路由列表 每個路由中還可以包含以下配置： - `prefix`：URL 路徑前綴 - `cluster`：處理該請求的 envoy cluster - `timeout_ms`：當出錯時的超時時間 如上面的例子中，我們還需要定義 `service1` cluster 和 `service2` cluster。 ### Cluster 配置 Cluster 是一組邏輯相似的主機配置，定義哪些主機屬于一個服務，cluster 的配置中包含了服務發現和負載均衡方式配置。依然是參考[使用Envoy 作為前端代理](envoy-front-proxy.md)中的配置： ```yaml clusters: - name: service1 connect_timeout: 0.25s type: strict_dns lb_policy: round_robin http2_protocol_options: {} hosts: - socket_address: address: service1 port_value: 80 - name: service2 connect_timeout: 0.25s type: strict_dns lb_policy: round_robin http2_protocol_options: {} hosts: - socket_address: address: service2 port_value: 80 ``` Cluster 的配置中至少包含以下信息： - `name`：cluster 名稱，就是服務名稱 - `type`：該 cluster 怎么知道主機是否啟動？即服務發現類型，有以下方式： - `static`：監聽 cluster 中的所有主機 - `strict_dns`：envoy 會監聽 DNS，每個匹配的 A 記錄都會認定為有效 - `logical_dns`：envoy 將使用 DNS 來增加主機，如果 DNS 不再返回該主機也不會刪除這些主機信息 - `sds`：即 Serivce Discovery Serivce，envoy 訪問外部的 REST 獲取 cluster 成員信息 - `lb_type`：cluster 的負載均衡類型，有以下方式： - `round_robin`：輪詢主機 - `weighted_least_request`：最近獲得最少請求的主機 - `random`：隨機 - `hosts`：能夠定義 cluster 中主機的 URL 地址，通常是`tcp://` URL ## 參考 - [Terminology - www.envoyproxy.io](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/terminology) - [Part 1: Getting started with Envoy Proxy for microservices resilience](https://www.datawire.io/envoyproxy/getting-started-envoyproxy-microservices-resilience/) - [Envoy作為前端代理](envoy-front-proxy.md)