微服務「新秀」之Service Mesh

時間 2021-08-15

標籤 html 前端 nginx git github web redis 算法 json 後端欄目 HTML 简体版

原文原文鏈接

ADDOPS團隊霍明明 360雲計算html

女主宣言前端

本文出自於ADDOPS團隊，該文章的譯者霍明明參與了360 HULK雲平臺容器化及虛擬化平臺相關服務建設，對微服務有着獨到的看法。今天的主角Istio是Google/IBM/Lyft聯合開發的開源項目，估計不少同窗在此以前可能徹底沒有聽過這個名字，請沒必要介意，由於Istio出世也才五個月而已。讓咱們跟着做者一塊兒揭開Service Mesh的神祕面紗。nginx

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

前言github

有人將 Service Mesh 當作是一次 "Network Application Revolution"，我仍是很是認同的，因此也就有了進一步瞭解和學習Service Mesh的動力。web

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

1算法

Envoy 簡介json

在 Service Mesh 模式中，每一個服務都配備了一個代理「sidecar」，用於服務之間的通訊。這些代理一般與應用程序代碼一塊兒部署，而且它不會被應用程序所感知。Service Mesh 將這些代理組織起來造成了一個輕量級網絡代理矩陣，也就是服務網格。這些代理再也不是孤立的組件，它們自己是一個有價值的網絡。其部署模式如圖所示：後端

綠色部分表明應用程序
藍色部分則是sidecar

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

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

Envoy 用到的幾個術語

Host: 一般咱們將 Host 看作是一個具有網絡通訊功能的實體(能夠是一臺物理機，也能夠是一臺移動設備等等) 。在 Envoy 中，host 是一個邏輯網絡中的應用. 可能運行在由有多個主機組成的底層硬件，只要它們各自獨立尋址。
Downstream: 請求發起者(服務請求方)。
Upstream: 請求接收者(服務提供方)。
Listener: 服務(程序)監聽者。就是真正幹活的。 envoy 會暴露一個或者多個listener監聽downstream的請求。
Cluster: upstream 集羣。Envoy 經過服務發現定位集羣成員並獲取服務。具體請求到哪一個集羣成員是由負載均衡策略決定。經過健康檢查服務來對集羣成員服務狀態進行檢查。
Mesh: 在本文中 "Envoy mesh" 指的是由一組 Envoy 代理組成的，爲不一樣服務之間可靠傳遞請求的服務網格。
Runtime configuration: Envoy 配置是熱更新的，無需重啓。
Filter：過濾器。在 Envoy 中指的是一些「可插拔」和可組合的邏輯處理層。是 Envoy 核心邏輯處理單元。

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：

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.一、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鏈接的切換(默認是支持的)。

條件：

client 須要顯示添加 upgrade headers 。
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)

高級概念

集羣管理器(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)

服務發現有幾種方式：

靜態配置。經過配置文件配置(IP/PORT、unix domain socket等)。
基於DNS的服務發現。
Original destination
Service discovery service (SDS)
On eventually consistent service discovery

更多服務發現內容

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

主動健康檢查

根據配置的不一樣, Envoy 支持3種健康檢查方式。

基於 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 節點而言，則是新請求新鏈接。
基於 HTTP 的健康檢查支持身份認證。
若是你在雲平臺中用了最終一致性的服務發現服務或者容器環境中，遇上服務水平擴展，這個時候其中一個節點掛掉後又"回到平臺"且使用的是同一個 IP 是有可能的，可是確是不一樣的服務(在容器服務中尤其明顯)。一種解決方案是，對不一樣的服務使用不一樣的健康檢查URL，可是這種配置複雜度很是高。Envoy 採用的方案是在 header 中添加一個 service_name 選項來支持。若是設置了該選項，在健康檢查時會對比 header 中的 x-envoy-upstream-healthchecked-cluster 是否和該選項值匹配，若是不匹配則會忽略該請求。
L3/L4
基於L3/L4層的健康檢查, Envoy 向 upstream 節點發送定義好的一個字符串. 若是 upstream 節點返回該值，則表明健康, 不然不健康。
Redis
Envoy 向 Redis 發送一個 PING 命令, 返回 PONG 表明健康, 其它的表明不健康。

Passive health checking(鈍態檢查)

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

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

有時候一個節點雖然在進行主動健康檢查是是正常的，可是會存在某些不正常的狀態被遺漏的狀況，而 Outlier detection 則是彌補這個「漏洞」的。它經過跟高級的一些算法來斷定該節點是不是正常的。

Outlier detection 有兩種檢查類型：

基於連續的 5xx 錯誤碼
upstream 成員連續N次返回5xx錯誤碼, N默認爲5(可配置)。
基於成功率

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

針對集羣中單個節點
單個節點的請求數量在聚合區間內少於outlier_detection.success_rate_request_volume值時(默認100)。
集羣級別
集羣中 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/L四、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 可以全自動的更新本身(包括代碼和配置的變動)，而不會丟失任何鏈接。

看下熱更新的過程:

統計數據和一些lock都放到了共享內存中。進程在重啓時這些數據是持久的，不會丟失。
新舊進程經過RPC協議進行通訊。
新的進程在接管舊進程的unix domain socket前，先完成一系列的初始化(好比：加載配置, 初始化服務發現和健康檢查, 其它)。而後，新的進程開始監聽服務，並告訴老的Envoy進程進入驅逐階段。
在舊進程驅逐階段, 舊的進程嘗試平滑的關閉已存在的鏈接。具體如何作要依賴於配置的filters。 --drain-time-s 配置項用來配置等待平滑退出的時間。若是平滑退出花費的時間超過了這個值，進程會強制關閉和回收。
驅逐過程結束後, 新的Envoy進程告訴舊的Envoy進程關閉本身。參數 --parent-shutdown-time-s 用來配置關閉本身的超時時間。
Envoy 的熱重啓的設計支持新老進程同時存在時也能正常工做。新舊進程之間的通訊只能是經過unix domain socket。

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相關的文章和分享。