知識星球導讀：隨著Service Mesh在最近一年的流行，Envoy作為其中很關鍵的元件，也開始被廣大技術人員熟悉。作者是Envoy的開發者之一，本文詳細說明瞭Envoy API的設計，對於理解Envoy如何工作非常有幫助。內容較為深入，建議細細品讀。
原文地址：https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a
作者：Matt Klein
譯者：敖小劍
校對：宋凈超
正如我之前所說的，在如此短的時間內，Envoy 帶來的興奮既神奇又震撼人心。我經常問自己：envoy 的哪些方面導致了我們所看到的異常的社群增長？雖然 Envoy 具有很多引人註目的特徵，但最終我認為有三個主要特徵在共同推動：
-
效能：在具備大量特性的同時，Envoy 提供極高的吞吐量和低尾部延遲差異，而 CPU 和 RAM 消耗卻相對較少。
-
可擴充套件性：Envoy 在 L4 和 L7 都提供了豐富的可插拔過濾器能力，使使用者可以輕鬆新增 開源版本中沒有的功能。
-
API可配置性：或許最重要的是，Envoy 提供了一組可以透過控制平面服務實現的管理 API 。如果控制平面實現所有的 API，則可以使用通用引導配置在整個基礎架構上執行 Envoy。所有進一步的配置更改透過管理伺服器以無縫方式動態傳送，因此 Envoy 從不需要重新啟動。這使得 Envoy 成為通用資料平面，當它與一個足夠複雜的控制平面相結合時，會極大的降低整體運維的複雜性。
有代理具備超高效能。也有代理具備高度的可擴充套件性和動態可配置性。在我看來，效能、可擴充套件性和動態可配置性的結合 才使得 Envoy 如此的引人註目。
在這篇文章中，我將概述 Envoy 動態配置 API 背後的歷史和動機，討論從 v1 到 v2 的演變，最後，鼓勵更多的負載均衡，代理和控制平面社群來考慮在其產品中支援這些API。
Envoy API v1的歷史
Envoy 最初的設計標的之一是實現最終一致的服務發現系統。為此，我們開發了一個非常簡單的發現服務和 Service Discovery Service (SDS) REST API，用來傳回上游叢集成員。該 API 剋服了基於 DNS 的服務發現的一些限制（記錄限制、缺少額外元資料等），並使我們能夠快速實現高可靠性。
Envoy 開源初期，我們收到了很多關於支援其他服務發現系統的要求，如 Consul、Kubernetes、Marathon、DNS SRV等。我擔心我們對這些系統直接支援的缺失會限制 Envoy 的使用範圍而不被人所接納。新增新的發現配接器的程式碼編寫並不困難，我希望有關方面能夠實施新的配接器。而過去一年實際發生是什麼？ 沒有一個新的配接器被貢獻到程式碼中，但我們看到了令人難以置信的接受度。為什麼？
事實證明，幾乎每個人都以自己的方式來實現 SDS API。API 本身是微不足道的，但我不認為這是人們實現它的唯一原因。另一個原因是，離資料平面越遠，事情自然就會開始變得更牢固。Envoy 的消費者通常希望最終服務發現能夠整合到特定的工作流程中。API 的簡單性使得其可以輕鬆整合到幾乎任何控制平面系統中。甚至像 Consul 系統的使用者（參見示例 Nelson）也發現中間 API 可以對成員和命名做更智慧的處理。因此，即使在如此早期的階段，我們也看到了對通用資料平面 API 的渴望：一個簡單的 API，從控制平面中抽象出資料平面。
在過去的一年中，Envoy 添加了多個 v1/REST 管理 API。他們包括：
-
叢集發現服務（CDS）：使用此 API，Envoy 可以動態地新增/更新/刪除所有上游叢集（每個叢集本身都有自己的服務/端點發現）。
-
路由發現服務（RDS）：使用此API，Envoy 可以動態地新增/更新 HTTP 路由表。
-
監聽器發現服務（LDS）：使用此 API，Envoy 可以動態地新增/更新/刪除全體監聽器，包括其完整的 L4 和 L7 過濾器堆疊。
當控制平面實現 SDS/CDS/RDS/LDS 時，幾乎 Envoy 的所有方面都可以在執行時動態配置。Istio 和 Nelson 都是控制平面的例子，他們在 V1 API 上構建，具備極其豐富的功能。透過使用相對簡單的 REST API，Envoy 可以快速迭代效能和資料平面功能，同時仍支援各種不同的控制平面方案。此時，通用資料平面概念正成為現實。
v1 API的缺點和v2的引入
v1 API 僅使用 JSON/REST，本質上是輪詢。這有幾個缺點：
-
儘管 Envoy 在內部使用的是 JSON 樣式，但 API 本身並不是強型別，而且安全實現它們的通用伺服器也很難。
-
雖然輪詢工作在實踐中是很正常的用法，但更強大的控制平面更喜歡 streaming API，當其就緒後，可以將更新推送給每個 Envoy。這可以將更新傳播時間從 30-60 秒降低到 250-500 毫秒，即使在極其龐大的部署中也是如此。
在過去幾個月與 Google 的緊密合作中，我們一直在努力研究一組我們稱之為 v2 的新 API。v2 API 具有以下屬性：
-
新的 API 樣式使用 proto3 指定，並同時以 gRPC 和 REST + JSON/YAML 端點實現。另外，它們被定義在一個名為 envoy-api 的新的專用原始碼倉庫中。proto3 的使用意味著這些 API 是強型別的，同時仍然透過 proto3 的 JSON/YAML 表示來支援 JSON/YAML 變體。專用儲存倉庫的使用意味著專案可以更容易的使用 API 並用 gRPC 支援的所有語言生成存根（實際上，對於希望使用它的使用者，我們將繼續支援基於 REST 的 JSON/YAML 變體）。
譯者註：envoy-api 倉庫在 Envoy 加入CNCF 後改為 envoyproxy/data-plane-api 倉庫，問題後面有提到。
-
v2 API 是 v1 的演進，而不是革命，它是 v1 功能的超集。v1 使用者會發現 v2 非常接近他們已經在使用的 API。實際上，我們一直以可以繼續永久支援 v1（儘管是最終被凍結的功能集）的方式在 Envoy 中實現 v2。
-
不透明的元資料已被新增到各種 API 響應中，這將極大的增強可擴充套件性。例如，HTTP 路由中的元資料，附加到上游端點和自定義負載均衡器的元資料，以用來構建站點特有的基於標簽的路由。我們的標的是可以在預設的OSS發行版之上輕鬆插入豐富的功能。未來將有更強大的關於編寫 Envoy 擴充套件的檔案。
-
對於使用 v2 gRPC（vs. JSON/REST）的 API 消費者，雙向流會有一些有趣的增強，我將在下麵進行更多討論。
v2 API 由以下部分組成：
-
Endpoint Discovery Service (EDS)：這是v1 SDS API的替代品。SDS是一個不幸的名字選擇，所以我們正在v2中修複這個問題。此外，gRPC的雙向流性質將允許將負載/健康資訊報告回管理伺服器，為將來的全域性負載均衡功能開啟大門。
-
Cluster Discovery Service (CDS)：和v1沒有實質性變化。
-
Route Discovery Service (RDS)：和v1沒有實質性變化。
-
Listener Discovery Service (LDS)：和v1的唯一主要變化是：我們現在允許監聽器定義多個併發過濾棧，這些過濾棧可以基於一組監聽器路由規則（例如，SNI，源/目的地IP匹配等）來選擇。這是處理“原始目的地”策略路由的更簡潔的方式，這種路由是透明資料平面解決方案（如Istio）所需要的。
-
Health Discovery Service (HDS)：該 API 將允許 Envoy 成為分散式健康檢查網路的成員。中央健康檢查服務可以使用一組 Envoy 作為健康檢查終點並將狀態報告回來，從而緩解N²健康檢查問題，這個問題指的是其間的每個 Envoy 都可能需要對每個其他 Envoy 進行健康檢查。
-
Aggregated Discovery Service (ADS)：總的來說，Envoy 的設計是最終一致的。這意味著預設情況下，每個管理 API 都併發執行，並且不會相互互動。在某些情況下，一次一個管理伺服器處理單個 Envoy 的所有更新是有益的（例如，如果需要對更新進行排序以避免流量下降）。此 API 允許透過單個管理伺服器的單個 gRPC 雙向流對所有其他 API 進行編組，從而實現確定性排序。
-
Key Discovery Service (KDS)：該API尚未定義，但我們將新增一個專用的API來傳遞TLS金鑰材料。這將解耦透過 LDS/CDS 傳送主要監聽器、叢集配置和透過專用金鑰管理系統傳送秘鑰素材。
譯者註：目前 xds 中沒有 kds 的定義，但是有一個Secret Discovery Service，應該是這個 kds 的改名。以上 API 請參考 https://github.com/envoyproxy/data-plane-api/tree/master/envoy/api/v2
總的來說，我們稱所有上述 API 為 xDS。 從 JSON/REST 到 proto3 API 的過渡非常令人興奮，良好型別的 proto3 API 可以更容易使用，我認為這將進一步提高 API 本身以及 Envoy 的接受度。
多代理多控制平面的 API？
服務網格/負載均衡領域現在非常活躍。代理包括 Envoy、Linkerd、NGINX、HAProxy、Traefik，來自所有主要雲提供商的軟體負載均衡器，以及傳統硬體供應商（如 F5 和思科）的物理裝置。隨著眾多解決方案的出現，如 Istio、Nelson，整合雲解決方案以及許多供應商即將推出的產品等，控制平面領域也在不斷升溫。
特別討論一下 Istio，Linkerd 已經宣佈對它的支援，這意味著至少在某種程度上它已經實現了 v1 Envoy API。其他人可能會跟隨。 在這個資料平面和控制平面快速發展的新世界中，我們將看到元件的混合和匹配；資料平面將與許多控制平面一起工作，反之亦然。我們是否可以讓業界受益於一種通用 API，讓這種混合和匹配更容易實現？ 這會有什麼幫助？
在我看來，在接下來的幾年中，資料平面本身將大部分商品化。大部分創新（和商業機會擴充套件）實際上將成為控制平面的一部分。使用 v2 Envoy API，控制平面功能的範圍可以會從使用 N² 健康檢查的扁平端點名稱空間擴充套件到一個非常豐富的全域性負載均衡系統，該系統可進行自動構造子集、負載裝卸和均衡、分散式區域性健康檢查、區域感知路由、基於百分比的自動部署和回滾等。供應商將在提供無縫的微服務運維環境方面展開競爭，而對路由的自動化控制將是其競爭中的主要部分。
在這個新的世界中，資料平臺可以用來與控制平面進行通訊的通用API對每個參與者都是一個勝利。控制平面提供商可以將它們的服務提供給實現該API的任何資料平面。資料平面可以在功能，效能，規模和健壯性方面展開競爭。此外，解耦允許控制平面提供商提供 SaaS 解決方案，而不需要同時擁有資料平面部署，這是一個主要的痛點。
Envoy API 合作邀請
雖然很難知道未來幾年會發生什麼，但我們對 Envoy 及其相關 API 的採用感到非常興奮。我們看到了通用的資料平面 API 的價值所在：可以橋接不同系統。根據這些原則，我們邀請更大的資料平面和控制平面供應商以及使用者與我們在 envoy-api 儲存倉庫中進行協作（請註意，當Envoy 進入 CNCF 並轉換到專用的 envoyproxy GitHub 組織時，我們將重新命名該儲存倉庫為 data-plane-api）。我們不保證我們將新增所有可能的功能，但我們希望看到其他系統使用這些 API 並幫助我們改進它們以滿足他們自己的需求。我們的觀點是，資料平面的商品化將為終端使用者帶來巨大收益，這有助於控制平面領域提高迭代和競爭速度，未來幾年大部分創新將會發生在控制平面。
英文原文釋出於2017年9月6日，本文發出時 Envoy 已經進入了 CNCF，成為了官方專案，Envoy 原來的程式碼都已經被重構和遷移，本文中提到的很多連結都已過時，請大家參考 Envoy 官網 https://www.envoyproxy.io/，也可以檢視 Envoy 官方檔案中文版 https://servicemesher.github.io/envoy/。
本文譯者敖小劍老師將於11月24日在GIAC上海站發表重磅演講《knative: 重新定義Serverless》，歡迎屆時光臨。本週購買GIAC門票可享88折優惠，高可用架構會員低至6折。
活動預告：
11 月 23 ~ 24 日，GIAC 全球網際網路架構大會將於上海舉行。GIAC 是高可用架構技術社群推出的面向架構師、技術負責人及高階技術從業人員的技術架構大會。今年的 GIAC 已經有微軟，騰訊、阿裡巴巴、螞蟻金服，華為，科大訊飛、新浪微博、京東、七牛、美團點評、餓了麼，才雲，格靈深瞳，Databricks，等公司專家出席。本週購買可享門票88折優惠，高可用架構會員低至6折。
本期 GIAC 大會上，Cloud Native部分精彩的議題如下：
參加 GIAC，盤點2018最新技術。點選“閱讀原文”瞭解大會更多詳情。