Service Mesh中的通用數據平面API設計
原文地址：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 作為健康檢查終點並將狀態報告回來，從而緩解N2健康檢查問題，這個問題指的是其間的每個 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 為 。 從 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，控制平面功能的範圍可以會從使用 N2 健康檢查的扁平端點命名空間擴展到一個非常豐富的全局負載均衡系統，該系統可進行自動構造子集、負載裝卸和均衡、分散式局部健康檢查、區域感知路由、基於百分比的自動部署和回滾等。供應商將在提供無縫的微服務運維環境方面展開競爭，而對路由的自動化控制將是其競爭中的主要部分。
在這個新的世界中，數據平台可以用來與控制平面進行通訊的通用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/。
活動預告
TAG:ServiceMesher |