原文連結：http://blog.csdn.net/zvayivqt0ufji/article/details/78351355

女主宣言

本文出自於ADDOPS團隊，該文章的譯者霍明明參與了360 HULK雲平臺容器化及虛擬化平臺相關服務建設，對微服務有著獨到的見解。今天的主角Istio是Google/IBM/Lyft聯合開發的開源專案，估計很多同學在此之前可能完全沒有聽過這個名字，請不必介意，因為Istio出世也才五個月而已。讓我們跟著作者一起揭開Service Mesh的神祕面紗。

PS：豐富的一線技術、多元化的表現形式，盡在“HULK一線技術雜談”，點關注哦！

前言

有人將 Service Mesh 看成是一次 "Network Application Revolution"，我還是非常認同的，所以也就有了進一步瞭解和學習Service Mesh的動力。

在看本文章前，強烈建議先看一下這兩篇文章《深度剖析Service Mesh服務網格新生代Istio》，《從分散式到微服務，深挖Service Mesh》，瞭解一下Service Mesh的歷史。

1

Envoy 簡介

在 Service Mesh 模式中，每個服務都配備了一個代理“sidecar”，用於服務之間的通訊。這些代理通常與應用程式程式碼一起部署，並且它不會被應用程式所感知。Service Mesh 將這些代理組織起來形成了一個輕量級網路代理矩陣，也就是服務網格。這些代理不再是孤立的元件，它們本身是一個有價值的網路。其部署模式如圖所示：

• 綠色部分代表應用程式

• 藍色部分

  則是sidecar

服務網格是用於處理服務到服務通訊的“專用基礎設施層”。它通過這些代理來管理複雜的服務拓撲，可靠地傳遞服務之間的請求。 從某種程度上說，這些代理接管了應用程式的網路通訊層。

Envoy是 Service Mesh 中一個非常優秀的 sidecar 的開源實現。我們就來看看 Envoy 都是做些什麼工作。

2

Envoy 用到的幾個術語

• Host: 通常我們將 Host 看做是一個具備網路通訊功能的實體(可以是一臺物理機，也可以是一臺移動裝置等等) 。在 Envoy 中，host 是一個邏輯網路中的應用. 可能執行在由有多個主機組成的底層硬體，只要它們各自獨立定址。

• Downstream: 請求發起者(服務請求方)。

• Upstream: 請求接收者(服務提供方)。

• Listener: 服務(程式)監聽者。就是真正幹活的。 envoy 會暴露一個或者多個listener監聽downstream的請求。

• Cluster: upstream 叢集。Envoy 通過服務發現定位叢集成員並獲取服務。具體請求到哪個叢集成員是由負載均衡策略決定。通過健康檢查服務來對叢集成員服務狀態進行檢查。

• Mesh: 在本文中 "Envoy mesh" 指的是由一組 Envoy 代理組成的，為不同服務之間可靠傳遞請求的服務網格。

• Runtime configuration: Envoy 配置是熱更新的，無需重啟。

• Filter： 過濾器。在 Envoy 中指的是一些“可插拔”和可組合的邏輯處理層。是 Envoy 核心邏輯處理單元。

3

Envoy 基礎概念

執行緒模型

Envoy 使用單程序多執行緒模式。一個主執行緒，多個工作執行緒。主執行緒協調和管理這多個執行緒來工作。每個執行緒都獨立監聽服務，並對請求進行過濾和資料的轉發等。

一個連線建立後，這個執行緒將會管理該連線的整個生命週期。通常 Envoy 是非阻塞的，對於大多數情況建議每個 Envoy 配置的工作執行緒數等於機器的 CPU 執行緒數。

Listeners

Envoy 中真正幹活的(通常是一個監聽服務埠的工作執行緒)。

Envoy 會啟動一個或者多個listener，監聽來自 downstream 的請求。當 listener 接收到新的請求時，會根據關聯的filters模板初始化配置這些 filters，並根據這些 filters 鏈對這些請求做出處理（例如：限速、TLS 認證、HTTP 連線管理、MongoDB 嗅探、TCP 代理等等）。

Envoy 是多執行緒模型，支援單個程序配置任意數量的 listeners。通常建議一個機器上執行一個 Envoy 程序，而不關心配置了多少個listerners（如上：大多數情況listener數量等於機器的CPU執行緒數）。

目前 Envoy 只支援 TCP 型別的 listeners。每個 listener 都可以獨立配置一些L3/L4層的 filters。

Listener 還可以通過 listener 發現服務來動態獲取。

Network (L3/L4) filters

network (L3/L4) filters 構成了Envoy連線處理的核心。 在 listener 部分我們介紹過, 每個 listener 可以組合使用多個 filters 來處理連線資料。

目前有三種類型的 network (L3/L4) filters:

• Read: 當 Envoy 接收來自下游服務請求資料時被呼叫。

• Write: 當 Envoy 向上遊服務傳送資料時被呼叫。

• Read/Write: 上面兩種fileter都是單向控制，Read/Write filters 在接收來自下游服務請求資料和向上遊服務傳送資料時被呼叫，是雙向控制。

這些 filter 通過分析原始位元組流和少量連線事件(例如，TLS握手完成，本地或遠端連線斷開等)對連線進行處理。

Network Filter(L7)/HTTP Filter

HTTP 協議是當前許多服務構建的基礎協議，作為核心元件，Envoy 內建了 HTTP 連線管理 filter。 該 filter 將原始資料位元組轉換成 HTTP 協議型別資料(比如： headers、body、trailers等)。它還會處理一些通用的問題(比如：request日誌、request ID生成和request追蹤、請求/響應頭控制、路由表管理和狀態資料統計等)。

HTTP 連線管理提供了三種類型的filter：

HTTP 協議是當前許多服務構建的基礎協議，作為核心元件，Envoy 內建了 HTTP 連線管理 filter。 該 filter 將原始資料位元組轉換成 HTTP 協議型別資料(比如： headers、body、trailers等)。它還會處理一些通用的問題(比如：request日誌、request ID生成和request追蹤、請求/響應頭控制、路由表管理和狀態資料統計等)。

HTTP 連線管理提供了三種類型的filter：

• Decoder: 解析請求資料流時(headers，body，trailers等)呼叫，屬於入口單方向控制。

• Encoder: 編碼響應資料流時(headers, body, and trailers)呼叫，屬於出口單方向控制.

• Decoder/Encoder: Decoder/Encoder 用於入/出口雙向控制.

HTTP Filters

（https://envoyproxy.github.io/envoy/configuration/http_filters/http_filters.html#config-http-filters）

HTTP protocols

Envoy HTTP 連線管理原生支援HTTP/1.1, WebSockets 和 HTTP/2，暫不支援 SPDY。

Envoy 對 HTTP 的支援在設計之初就是一個HTTP/2的多路複用代理。對於 HTTP/1.1 型別連線，編解碼器將 HTTP/1.1 的資料轉換為類似於 HTTP/2 或者更高層的抽象處理。這意味著大多數程式碼不用關心底層連線使用的是 HTTP/1.1 還是 HTTP/2。

access log

HTTP 連線管理支援 access log，可以記錄訪問日誌，且可以靈活的配置。

HTTP 路由

Envoy 包含了一個 HTTP router filter，該 filter 可以用來實現更高階的路由功能。它可以用來處理邊緣流量/請求(類似傳統的反向代理)，同時也可以構建一個服務與服務之間的 Envoy 網格(典型的是通過對HTTP header等的處理實現到特定服務叢集的轉發)。

每個HTTP連線管理 filter 都會關聯一個路由表。每個路由表會包含對 HTTP 頭、虛擬主機等的配置資訊。

{

  "cluster": "...",

  "route_config_name": "route_config_example",

  "refresh_delay_ms": "3000"

}

route_config_example:

{

  "validate_clusters": "example",

  "virtual_hosts": [

        {

          "name": "vh01",

          "domains": ["test.foo.cn"],

          "routes": [],

          "require_ssl": "...", 

          "virtual_clusters": [], 

          "rate_limits": 

          "request_headers_to_add": [

                  {"key": "header1", "value": "value1"},

                  {"key": "header2", "value": "value2"}

          ]

        },

  ],

  "internal_only_headers": [],

  "response_headers_to_add": [],

  "response_headers_to_remove": [],

  "request_headers_to_add": [

  ]

}

路由表有兩種配置方式：

• 靜態配置檔案。

• 通過RDS(Route discovery service) API動態配置。

RDS 是一組API用來動態獲取變更後的路由配置。

router filter 支援如下功能：

• 支援 Virtual hosts。對映 domains/authorities 到一系列的路由規則上。[和nginx等一樣]。

• 基於字首和精確path的規則匹配(有的對大小寫既敏感,有的不敏感)。 由於 Regex/slug 會使得用程式來判定路由規則是否與其它規則衝突很困難, 所以,目前暫不支援。由於這個原因，我們不建議在反向代理層面使用基於regex/slug的路由, 當然了，未來我們會根據需求新增對它的支援。

• Virual host 層面的 TLS 重定向。 分兩類：

• all： 所有請求都必須使用TLS。如果請求沒有使用TLS，返回302。

• external_only： 只要求外網請求使用TLS。如果來自外網的請求沒有使用TLS。 如果，改引數沒有配置，該virtual host將不會對TLS有要求。

• 路由層面對 Path/host 重定向。

• host重寫。 支援兩種重寫方式：

  1. 固定值。host_rewrite引數配置。

  2. 動態配置。根據upstream 主機的 DNS 型別動態配置。 具體的值是由cluster manager從upstream中選出來的，其主機名作為重寫的值。 這種方式只用在route的目的叢集是 strict_dns or logical_dns 型別的場景。其它叢集型別不起作用。 將 auto_host_rewrite 設定true即可。這兩個引數不能同時使用。

• 字首重寫(prefix)。

• 路由層面對 Websocket upgrades. 配置該規則後，來自 HTTP/1.1 客戶端到該路由規則的連線都會被轉換成 WebSocket 的連線。 如果配置為 true, Envoy 對於該路由的第一個請求需帶 WebSocket upgrade headers。如果沒有新增該header，請求江北拒絕。如果設定了, Envoy 將會在client和upstream server之間設定TCP代理 。upstream 負責斷開該連線，否則 Envoy 任然會轉發資料到該upstream server。

• 請求重試和超時設定 Envoy 有兩種方式來設定請求重試。

  1. 通過route設定。

  2. 通過request header設定。 支援的配置項有： 2.1 最大重試次數: 每次重試之間會使用指數退避演算法.另外，所有重試都包含在整體請求超時之內。這避免了由於大量重試而需要較長的請求時間。 2.2 重試條件: 可以根據應用的需求配置觸發重試的條件。例如： 網路錯誤, 5xx 返回碼, 冪等的4xx返回碼, 等等。

• 執行時對來自上下游資料的嗅探。

• 使用基於 weight/percentage-based 的路由，對來自多個上游的資料進行拆分。

• 任意 HTTP 頭匹配路由規則。

• 支援虛擬叢集。

• 基於路由的優先順序。

• 基於路由的 hash 負載均衡。需要在 header 中設定 hash 使用的策略。

• 對於非 TLS 的轉發支援絕對 urls。

其中：重定向、超時、重試對於 websocket upgrades 是不支援的。

Connection pooling

對於 HTTP 型別，Envoy 提供了對連線池的抽象，連線池遮蔽底層協議型別(HTTP/1.1、HTTP/2)，向上層提供統一的介面。使用者不用關心底層是基於HTTP/1.1的多執行緒還是基於HTTP/2的多路複用方式實現細節。

TCP proxy

TCP 代理，L3/L4層連線的轉發。這應該是 Envoy 最基礎的功能。一般是作為 downstream 客戶端與 upstream 服務叢集之間的連線代理。TCP 代理既可以單獨使用，也可以與其它 filter 組合使用，例如( MongoDB filter 或者 限速filter)。

在 TCP 代理層還可以配置 route 策略，比如： 允許哪些IP段和哪些埠進來的請求訪問，允許訪問哪些IP段和哪些埠的服務。

TCP 代理配置如下：

{

  "name": "tcp_proxy",

  "config": {

    "stat_prefix": "...",

    "route_config": "{...}"

  }

}

• stat_prefix： 統計資料字首，主要是用於區分統計資料。

• route_config： filter 的路由表。

例如：

{

  "name": "tcp_proxy",

  "config": {

    "stat_prefix": "...",

    "route_config": "{

      "routes": [

        {

            "cluster": "...",

            "destination_ip_list": [

                  "192.168.3.0/24",

                  "50.1.2.3/32",

                  "10.15.0.0/16",

                  "2001:abcd::/64"

            ],

            "destination_ports": "1-1024,2048-4096,12345",

            "source_ip_list": [

                  "192.168.3.0/24",

                  "50.1.2.3/32",

                  "10.15.0.0/16",

                  "2001:abcd::/64"

            ],

            "source_ports": "1-1024,2048-4096,12345"

        },

      ]

    }"

  }

}

簡單說，就是上下游服務的訪問控制。

TPC 代理支援的一些統計資料：

• downstream_cx_total 處理的連線總數.

• downstream_cx_no_route 不匹配route的總數.

• downstream_cx_tx_bytes_total 傳送給下游的總位元組數

• downstream_cx_tx_bytes_buffered Gauge 當前為下游服務快取的位元組數

• downstream_flow_control_paused_reading_total 被流控暫停從下游服務讀取資料的次數

• downstream_flow_control_resumed_reading_total 被流控控制重新從下游服務讀取資料的次數

gRPC 的支援

Envoy 在傳輸層和應用層兩個層給予gRPC的高度支援。

• Envoy 是當前極少數能同時正確支援HTTP/2 trailers和傳輸gRPC請求和響應的的HTTP代理。

• gRPC 執行時對於一些語言而言還是不太成熟。為此，Envoy 支援一個叫 gRPC bridge 的 filter，它允許gRPC請求能夠通過HTTP/1.1傳送給Envoy。 Envoy 會將該請求轉換成HTTP/2傳輸到目的server。響應會被轉換成 HTTP/1.1 返回。

• 當裝了bridge filter後, bridge filter 除了收集全域性HTTP統計之外，橋接過濾器還收集每個RPC統計資訊。

• gRPC-Web is supported by a filter that allows a gRPC-Web client to send requests to Envoy over HTTP/1.1 and get proxied to a gRPC server. It’s under active development and is expected to be the successor to the gRPC bridge filter.

• 支援 gRPC-web。通過 filter 能夠將使用 HTTP/1.1 傳送到Envoy 的 gRPC-Web 客戶端請求代理到 gRPC server。該 feature 正在開發階段。

• JSON 轉換器支援基於 JSON 的 RESTFUL 客戶端通過 HTTP 傳送請求給 Envoy 並代理給 gRPC 服務.

WebSocket 的支援

Envoy 支援HTTP/1.1連線到WebSocket連線的切換(預設是支援的)。

條件：

1. client 需要顯示新增 upgrade headers 。

2. HTTP 路由規則中顯示的設定了對 websocket的支援(use_websocket)。

因為 Envoy 將 WebSocket connections 作為 TCP connection 來處理，因此，一些HTTP的特性它不支援，例如： 重定向、超時、重試、限速、 shadowing . 但是, prefix 重寫, host 重寫, traffic shifting and splitting 都是支援的.

Envoy對WebSocket的代理是TCP層，它理解不了WebSocket層的語義，所以對於連線斷開應該由upstream的client來主動關閉。

Envoy對WebSocket的支援與nginx對WebSocket的支援是相同的。

關於 Envoy 對 WebSocket 的支援可以參考 nginx 對 WebSocket 的支援。

(http://www.itfanwan.com/xinwen/6385)

4

高階概念

叢集管理器(Cluster manager)

Envoy 叢集管理器管理所有 upstream 叢集節點。

upstream 叢集節點都由一些列 L3/L4/L7 層 filter 鏈組成，它們可用於任意數量的不同代理服務。

叢集管理器向 filter 鏈暴露一組API，這組API允許 filters 獲取發往 upstream 叢集的L3/L4層的連線或抽象的 HTTP 連線池的資料。在 filter 處理階段通過對原始位元組流的分析確定是一個連線是 L3/L4 層的連線還是一個新的 HTTP 流。

除了基本的連線型別分析外，叢集管理器還要處理一些列的複雜工作，例如：知道哪些主機可用和健康，負載均衡，網路連線資料的本地儲存，連線型別(TCP/IP, UDS)，協議型別(HTTP/1.1,HTTP/2)等。

叢集管理器支援兩種方式獲取它管理的叢集節點：

• 通過靜態的配置檔案

• 通過動態的叢集發現API(CDS)。

CDS：Cluster discovery service，是一個可選的API，Envoy用它來動態的獲取cluster manager的成員。

叢集管理器配置項如下：

{

  "clusters": [], 

  "sds": "{...}",

  "local_cluster_name": "...",

  "outlier_detection": "{...}",

  "cds": "{...}"

}

Service discovery(SDS)

服務發現有幾種方式：

1. 靜態配置。通過配置檔案配置(IP/PORT、unix domain socket等)。

2. 基於DNS的服務發現。

3. Original destination

4. Service discovery service (SDS)

5. On eventually consistent service discovery

更多服務發現內容

(https://envoyproxy.github.io/envoy/intro/arch_overview/service_discovery.html)

主動健康檢查

根據配置的不同, Envoy 支援3種健康檢查方式。

1. 基於 HTTP

   Envoy 向 upstream 節點發送一個 HTTP 請求，返回 200 代表健康, 返回 503 代表該host不再接收請求/流量。

   基於 HTTP 的健康檢查支援3種策略：

   1.1 No pass through

   這種模式 Envoy 不會將健康檢查的請求轉發給本地的服務，而是根據當前節點是否被 draining 返回 200 或者 503.

   1.2 Pass through

   與第一種模式不同，這種模式 Envoy 會將健康檢查的請求轉發給本地服務，呼叫本地服務的健康檢查介面，返回 200 或 503.

   1.3 Pass through with caching

   這種模式是前兩種模式的高階版，第一種方案資料不一定準，第二種請求太頻繁會對效能有影響。

   該模式加了個快取的支援，在快取週期內結果直接從快取中取，快取失效後再請求一次本地服務載入到快取中。

   這是推薦的一種模式。 健康檢查時 Envoy 與 Envoy之間是長連線，他們不會消耗太大效能；對於 upstream 節點而言，則是新請求新連線。

2. 基於 HTTP 的健康檢查支援身份認證。

   如果你在雲平臺中用了最終一致性的服務發現服務或者容器環境中，趕上服務水平擴充套件，這個時候其中一個節點掛掉後又"回到平臺"且使用的是同一個 IP 是有可能的，但是確是不同的服務(在容器服務中尤為明顯)。一種解決方案是，對不同的服務使用不同的健康檢查URL，但是這種配置複雜度非常高。Envoy 採用的方案是在 header 中新增一個 service_name 選項來支援。如果設定了該選項，在健康檢查時會對比 header 中的 x-envoy-upstream-healthchecked-cluster 是否和該選項值匹配，如果不匹配則會忽略該請求。

3. L3/L4

   基於L3/L4層的健康檢查, Envoy 向 upstream 節點發送定義好的一個字串. 如果 upstream 節點返回該值，則代表健康, 否則不健康。

4. Redis

   Envoy 向 Redis 傳送一個 PING 命令, 返回 PONG 代表健康, 其它的代表不健康。

Passive health checking(鈍態檢查)

Envoy 通過 Outlier detection 進行鈍態(實在是找不出太合適的詞)檢查

Outlier detection，用來檢查某些叢集成員在給定範圍內是否“正常”,不正常則將其從負載均衡列表中移除。

有時候一個節點雖然在進行主動健康檢查是是正常的，但是會存在某些不正常的狀態被遺漏的情況，而 Outlier detection 則是彌補這個“漏洞”的 。它通過跟高階的一些演算法來判定該節點是否是正常的。

Outlier detection 有兩種檢查型別：

• 基於連續的 5xx 錯誤碼

  upstream 成員連續N次返回5xx錯誤碼, N預設為5(可配置)。

• 基於成功率

基於成功率的檢查在兩種情況下是不處理的：

1. 針對叢集中單個節點

   單個節點的請求數量在聚合區間內少於outlier_detection.success_rate_request_volume值時(預設100)。

2. 叢集級別

   叢集中 outlier_detection.success_rate_minimum_hosts 個節點在檢查週期內請求量都小於 outlier_detection.success_rate_request_volume 時。

配置項：

  {

  "consecutive_5xx": "...",

  "interval_ms": "...",

  "base_ejection_time_ms": "...",

  "max_ejection_percent": "...",

  "enforcing_consecutive_5xx" : "...",

  "enforcing_success_rate" : "...",

  "success_rate_minimum_hosts" : "...",

  "success_rate_request_volume" : "...",

  "success_rate_stdev_factor" : "..."

}

“

主動健康檢查和鈍態檢查可以配合使用，也可以單獨使用。

Circuit breaking(斷路器)

斷路器是一種分散式的限速機制，它針對每個upstream的host設定，有時候也需要針對整個cluster進行限制， 這個時候全域性的限速就非常有必要了。Envoy支援全侷限速(L3/L4、HTTP 都支援)，它有一個集中的限速服務， 對於到達該叢集的每個連線，都會從限速服務那裡查詢全侷限速進行判斷。 Envoy 是通過一個全域性的gRPC限速服務來實現全侷限速。通過redis來做後端儲存。

Envoy 的斷路器可以控制 envoy 與 downstream 節點的最大連線數、叢集最大支援的 pending 請求數、叢集最大支援的請求數(適用HTTP/2)、叢集存活最大探測次數。

斷路器配置：

{

  "max_connections": "...", 

  "max_pending_requests": "...", # 預設 1024

  "max_requests": "...", # 預設  1024

  "max_retries": "...", 預設 3

}

• max_connections：Envoy 與 upstream 叢集所有節點能夠建立的最大連線數量。該引數適用於HTTP/1.1，因為HTTP/2是使用單個連線與每個host建連，連線複用(預設1024)。

• max_pending_requests: 等待執行緒池有可用連線時的最大排隊請求數量。該引數適用於HTTP/1.1，HTTP/2採用多路複用方式，無需排隊請求(預設 1024)。

• max_requests: 給定時間內最大請求數，該引數適用於HTTP/2，HTTP/1.1 通過max_connections來限制。(預設 1024)。

• max_retries: 給定時間內Envoy與請求upstream叢集時的最大重試次數，該值不宜設定過大，重試過多可能會帶來更多其它的級聯故障，甚至導致雪崩。(預設 3)。

熱更新

簡化操作是Envoy一個非常重要的設計目標。除了強大的統計和本地管理介面， Envoy還具備自身熱重啟的功能。 這意味著 Envoy 能夠全自動的更新自己(包括程式碼和配置的變更)，而不會丟失任何連線。

看下熱更新的過程:

1. 統計資料和一些lock都放到了共享記憶體中。程序在重啟時這些資料是持久的，不會丟失。

2. 新舊程序通過RPC協議進行通訊。

3. 新的程序在接管舊程序的unix domain socket前，先完成一系列的初始化(比如：載入配置, 初始化服務發現和健康檢查, 其它)。然後，新的程序開始監聽服務，並告訴老的Envoy程序進入驅逐階段。

4. 在舊程序驅逐階段, 舊的程序嘗試平滑的關閉已存在的連線。具體如何做要依賴於配置的filters。 --drain-time-s 配置項用來配置等待平滑退出的時間。如果平滑退出花費的時間超過了這個值，程序會強制關閉和回收。

5. 驅逐過程結束後, 新的Envoy程序告訴舊的Envoy程序關閉自己。引數 --parent-shutdown-time-s 用來配置關閉自己的超時時間。

6. Envoy 的熱重啟的設計支援新老程序同時存在時也能正常工作。新舊程序之間的通訊只能是通過unix domain socket。

5

Envoy 部署方式

這一塊是大家關注的重點，也就是應用程式如何與 Envoy 結合來使用的、請求是如何轉到 Envoy 的等等。

根據不同的使用場景，Envoy有不同的部署方式。

Service to service only

這是最簡單的部署和使用方式，在這種方式中 Envoy 作為內部與外部服務通訊的匯流排。Envoy 啟動多個 listeners 用於本地流量轉發和服務與服務之間的流量轉發。

上圖展示了最簡單的 Envoy 部署方式。在這種部署方式中 Envoy 承擔的是SOA服務內部流量的訊息匯流排角色。在這種場景中， Envoy 會暴露一些 listeners 用於本地流量或者本地服務與遠端服務之間流量的轉發。

listener 型別：

• Service to service egress listener

  本地服務到遠端服務的出口 listener。該型別 listener 會監聽在某個指定的埠上，所有內部應用出去的請求都重定向到該埠上，由該 listener 處理並轉發到目的服務叢集節點。

  例如：http://localhost:9001 或 tcp://localhost:9001。 HTTP 和 gRPC 型別請求使用 host header，HTTP/2使用 authority header 來指定訪問的遠端服務叢集。 在資料流經 Envoy 過程中會進行服務發現、負載均衡、限速等處理。

  本地 Services 只需要知道本地的Envoy，無需關心它們自己所處的網路拓撲及環境。

• Service to service ingress listener

  本地服務到遠端服務的入口 listener。該 listener 提供遠端 Envoy 呼叫本地 Envoy 的埠。

  例如：http://localhost:9211。 進入本地 Envoy 的請求都被路由/重定向到本地 service 的監聽埠。根據需要，本地的Envoy 會進行一些快取、斷路檢查等處理。

• Optional external service egress listeners

  有時，需要訪問外部的服務，此時需要提供一個埠提供訪問。因為，有些外部服務SDK不支援host header的重寫來支援標準的HTTP反向代理行為。

  例如：http://localhost:9250 might be allocated for connections destined for DynamoDB.我們建議為所有外部服務使用本地埠路由，而不是使用主機路由和專用本地埠路由

• Discovery service integration

  整合外部服務發現元件來提供服務到服務的發現功能。

  service to service 模式配置模板

  (https://github.com/envoyproxy/envoy/blob/master/configs/envoy_service_to_service.template.json)

Service to service plus front proxy

上圖展示了在 service to service 模式前增加 Envoy 叢集作為7層反向代理的部署模式。

該部署模式有以下特點：

• TLS 解除安裝

• 同時支援 HTTP/1.1 和 HTTP/2

• 完整的 HTTP 7層路由支援

• 前端的 Envoy 代理叢集使用標準的 ingress 埠與後端的 service to service 叢集通訊。對於後端服務叢集節點使用服務發現方式獲取。前端的 Envoy 叢集節點是完全對等的提供服務，沒有任何差異。

這種方式和 service to service 方式相比多出了 前端七層代理的部分。可以適配更多的使用場景。

Service to service plus front proxy 配置模板

(https://github.com/envoyproxy/envoy/blob/master/configs/envoy_front_proxy.template.json)

Service to service, front proxy, and double proxy

雙代理模式

雙代理模式的設計理念是： 更加高效的解除安裝TLS、更快速的與client端建立連線（更短的TLS握手時間，更快的TCP擁塞視窗調整，更少的丟包等等）。 這些在雙代理上解除安裝TLS後的連線最終都會複用 已經與資料中心完成連線建立的 HTTP/2 連線。

Service to service, front proxy, and double proxy 配置模板

(https://github.com/envoyproxy/envoy/blob/master/configs/envoy_double_proxy.template.json)

總結

以上就是ServiceMesh 資料面板 Envoy

的基本介紹。如果大家對 Istio 感興趣，可以之後自行瀏覽 Istio 的官方網站，我也預期會在之後閱讀其原始碼，更深入的瞭解 Envoy 工作原理，並會陸續給出Istio相關的文章和分享。

掃描下方二維碼瞭解更多內容