原文地址：https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a

作者：Matt Klein

譯者：敖小劍

校對(duì)：宋凈超

正如我之前所說(shuō)的，在如此短的時(shí)間內(nèi)，Envoy 帶來(lái)的興奮既神奇又震撼人心。我經(jīng)常問(wèn)自己：envoy 的哪些方面導(dǎo)致了我們所看到的異常的社區(qū)增長(zhǎng)？雖然 Envoy 具有很多引人注目的特征，但最終我認(rèn)為有三個(gè)主要特征在共同推動(dòng)：

性能：在具備大量特性的同時(shí)，Envoy 提供極高的吞吐量和低尾部延遲差異，而 CPU 和 RAM 消耗卻相對(duì)較少。

可擴(kuò)展性：Envoy 在 L4 和 L7 都提供了豐富的可插拔過(guò)濾器能力，使用戶(hù)可以輕松添加 開(kāi)源版本中沒(méi)有的功能。

API可配置性：或許最重要的是，Envoy 提供了一組可以通過(guò)控制平面服務(wù)實(shí)現(xiàn)的管理 API 。如果控制平面實(shí)現(xiàn)所有的 API，則可以使用通用引導(dǎo)配置在整個(gè)基礎(chǔ)架構(gòu)上運(yùn)行 Envoy。所有進(jìn)一步的配置更改通過(guò)管理服務(wù)器以無(wú)縫方式動(dòng)態(tài)傳送，因此 Envoy 從不需要重新啟動(dòng)。這使得 Envoy 成為通用數(shù)據(jù)平面，當(dāng)它與一個(gè)足夠復(fù)雜的控制平面相結(jié)合時(shí)，會(huì)極大的降低整體運(yùn)維的復(fù)雜性。

有代理具備超高性能。也有代理具備高度的可擴(kuò)展性和動(dòng)態(tài)可配置性。在我看來(lái)，性能、可擴(kuò)展性和動(dòng)態(tài)可配置性的結(jié)合 才使得 Envoy 如此的引人注目。

在這篇文章中，我將概述 Envoy 動(dòng)態(tài)配置 API 背后的歷史和動(dòng)機(jī)，討論從 v1 到 v2 的演變，最后，鼓勵(lì)更多的負(fù)載均衡，代理和控制平面社區(qū)來(lái)考慮在其產(chǎn)品中支持這些API。

Envoy API v1的歷史

Envoy 最初的設(shè)計(jì)目標(biāo)之一是實(shí)現(xiàn)最終一致的服務(wù)發(fā)現(xiàn)系統(tǒng)。為此，我們開(kāi)發(fā)了一個(gè)非常簡(jiǎn)單的發(fā)現(xiàn)服務(wù)和 Service Discovery Service (SDS) REST API，用來(lái)返回上游集群成員。該 API 克服了基于 DNS 的服務(wù)發(fā)現(xiàn)的一些限制（記錄限制、缺少額外元數(shù)據(jù)等），并使我們能夠快速實(shí)現(xiàn)高可靠性。

Envoy 開(kāi)源初期，我們收到了很多關(guān)于支持其他服務(wù)發(fā)現(xiàn)系統(tǒng)的要求，如 Consul、Kubernetes、Marathon、DNS SRV等。我擔(dān)心我們對(duì)這些系統(tǒng)直接支持的缺失會(huì)限制 Envoy 的使用范圍而不被人所接納。添加新的發(fā)現(xiàn)適配器的代碼編寫(xiě)并不困難，我希望有關(guān)方面能夠?qū)嵤┬碌倪m配器。而過(guò)去一年實(shí)際發(fā)生是什么？ 沒(méi)有一個(gè)新的適配器被貢獻(xiàn)到代碼中，但我們看到了令人難以置信的接受度。為什么？

事實(shí)證明，幾乎每個(gè)人都以自己的方式來(lái)實(shí)現(xiàn) SDS API。API 本身是微不足道的，但我不認(rèn)為這是人們實(shí)現(xiàn)它的唯一原因。另一個(gè)原因是，離數(shù)據(jù)平面越遠(yuǎn)，事情自然就會(huì)開(kāi)始變得更牢固。Envoy 的消費(fèi)者通常希望最終服務(wù)發(fā)現(xiàn)能夠集成到特定的工作流程中。API 的簡(jiǎn)單性使得其可以輕松集成到幾乎任何控制平面系統(tǒng)中。甚至像 Consul 系統(tǒng)的用戶(hù)（參見(jiàn)示例 Nelson）也發(fā)現(xiàn)中間 API 可以對(duì)成員和命名做更智能的處理。因此，即使在如此早期的階段，我們也看到了對(duì)通用數(shù)據(jù)平面 API 的渴望：一個(gè)簡(jiǎn)單的 API，從控制平面中抽象出數(shù)據(jù)平面。

在過(guò)去的一年中，Envoy 添加了多個(gè) v1/REST 管理 API。他們包括：

• 集群發(fā)現(xiàn)服務(wù)（CDS）：使用此 API，Envoy 可以動(dòng)態(tài)地添加/更新/刪除所有上游集群（每個(gè)集群本身都有自己的服務(wù)/端點(diǎn)發(fā)現(xiàn)）。

• 路由發(fā)現(xiàn)服務(wù)（RDS）：使用此API，Envoy 可以動(dòng)態(tài)地添加/更新 HTTP 路由表。

• 監(jiān)聽(tīng)器發(fā)現(xiàn)服務(wù)（LDS）：使用此 API，Envoy 可以動(dòng)態(tài)地添加/更新/刪除全體監(jiān)聽(tīng)器，包括其完整的 L4 和 L7 過(guò)濾器堆棧。

當(dāng)控制平面實(shí)現(xiàn) SDS/CDS/RDS/LDS 時(shí)，幾乎 Envoy 的所有方面都可以在運(yùn)行時(shí)動(dòng)態(tài)配置。Istio 和 Nelson 都是控制平面的例子，他們?cè)?V1 API 上構(gòu)建，具備極其豐富的功能。通過(guò)使用相對(duì)簡(jiǎn)單的 REST API，Envoy 可以快速迭代性能和數(shù)據(jù)平面功能，同時(shí)仍支持各種不同的控制平面方案。此時(shí)，通用數(shù)據(jù)平面概念正成為現(xiàn)實(shí)。

v1 API的缺點(diǎn)和v2的引入

v1 API 僅使用 JSON/REST，本質(zhì)上是輪詢(xún)。這有幾個(gè)缺點(diǎn)：

• 盡管 Envoy 在內(nèi)部使用的是 JSON 模式，但 API 本身并不是強(qiáng)類(lèi)型，而且安全實(shí)現(xiàn)它們的通用服務(wù)器也很難。

• 雖然輪詢(xún)工作在實(shí)踐中是很正常的用法，但更強(qiáng)大的控制平面更喜歡 streaming API，當(dāng)其就緒后，可以將更新推送給每個(gè) Envoy。這可以將更新傳播時(shí)間從 30-60 秒降低到 250-500 毫秒，即使在極其龐大的部署中也是如此。

在過(guò)去幾個(gè)月與 Google 的緊密合作中，我們一直在努力研究一組我們稱(chēng)之為 v2 的新 API。v2 API 具有以下屬性：

• 新的 API 模式使用 proto3 指定，并同時(shí)以 gRPC 和 REST + JSON/YAML 端點(diǎn)實(shí)現(xiàn)。另外，它們被定義在一個(gè)名為 envoy-api 的新的專(zhuān)用源代碼倉(cāng)庫(kù)中。proto3 的使用意味著這些 API 是強(qiáng)類(lèi)型的，同時(shí)仍然通過(guò) proto3 的 JSON/YAML 表示來(lái)支持 JSON/YAML 變體。專(zhuān)用存儲(chǔ)倉(cāng)庫(kù)的使用意味著項(xiàng)目可以更容易的使用 API 并用 gRPC 支持的所有語(yǔ)言生成存根（實(shí)際上，對(duì)于希望使用它的用戶(hù)，我們將繼續(xù)支持基于 REST 的 JSON/YAML 變體）。

譯者注：envoy-api 倉(cāng)庫(kù)在 Envoy 加入CNCF 后改為 envoyproxy/data-plane-api 倉(cāng)庫(kù)，問(wèn)題后面有提到。

• v2 API 是 v1 的演進(jìn)，而不是革命，它是 v1 功能的超集。v1 用戶(hù)會(huì)發(fā)現(xiàn) v2 非常接近他們已經(jīng)在使用的 API。實(shí)際上，我們一直以可以繼續(xù)永久支持 v1（盡管是最終被凍結(jié)的功能集）的方式在 Envoy 中實(shí)現(xiàn) v2。

• 不透明的元數(shù)據(jù)已被添加到各種 API 響應(yīng)中，這將極大的增強(qiáng)可擴(kuò)展性。例如，HTTP 路由中的元數(shù)據(jù)，附加到上游端點(diǎn)和自定義負(fù)載均衡器的元數(shù)據(jù)，以用來(lái)構(gòu)建站點(diǎn)特有的基于標(biāo)簽的路由。我們的目標(biāo)是可以在默認(rèn)的OSS發(fā)行版之上輕松插入豐富的功能。未來(lái)將有更強(qiáng)大的關(guān)于編寫(xiě) Envoy 擴(kuò)展的文檔。

• 對(duì)于使用 v2 gRPC（vs. JSON/REST）的 API 消費(fèi)者，雙向流會(huì)有一些有趣的增強(qiáng)，我將在下面進(jìn)行更多討論。

v2 API 由以下部分組成：

• Endpoint Discovery Service (EDS)：這是v1 SDS API的替代品。SDS是一個(gè)不幸的名字選擇，所以我們正在v2中修復(fù)這個(gè)問(wèn)題。此外，gRPC的雙向流性質(zhì)將允許將負(fù)載/健康信息報(bào)告回管理服務(wù)器，為將來(lái)的全局負(fù)載均衡功能開(kāi)啟大門(mén)。

• Cluster Discovery Service (CDS)：和v1沒(méi)有實(shí)質(zhì)性變化。

• Route Discovery Service (RDS)：和v1沒(méi)有實(shí)質(zhì)性變化。

• Listener Discovery Service (LDS)：和v1的唯一主要變化是：我們現(xiàn)在允許監(jiān)聽(tīng)器定義多個(gè)并發(fā)過(guò)濾棧，這些過(guò)濾棧可以基于一組監(jiān)聽(tīng)器路由規(guī)則（例如，SNI，源/目的地IP匹配等）來(lái)選擇。這是處理“原始目的地”策略路由的更簡(jiǎn)潔的方式，這種路由是透明數(shù)據(jù)平面解決方案（如Istio）所需要的。

• Health Discovery Service (HDS)：該 API 將允許 Envoy 成為分布式健康檢查網(wǎng)絡(luò)的成員。中央健康檢查服務(wù)可以使用一組 Envoy 作為健康檢查終點(diǎn)并將狀態(tài)報(bào)告回來(lái)，從而緩解N2健康檢查問(wèn)題，這個(gè)問(wèn)題指的是其間的每個(gè) Envoy 都可能需要對(duì)每個(gè)其他 Envoy 進(jìn)行健康檢查。

• Aggregated Discovery Service (ADS)：總的來(lái)說(shuō)，Envoy 的設(shè)計(jì)是最終一致的。這意味著默認(rèn)情況下，每個(gè)管理 API 都并發(fā)運(yùn)行，并且不會(huì)相互交互。在某些情況下，一次一個(gè)管理服務(wù)器處理單個(gè) Envoy 的所有更新是有益的（例如，如果需要對(duì)更新進(jìn)行排序以避免流量下降）。此 API 允許通過(guò)單個(gè)管理服務(wù)器的單個(gè) gRPC 雙向流對(duì)所有其他 API 進(jìn)行編組，從而實(shí)現(xiàn)確定性排序。

• Key Discovery Service (KDS)：該API尚未定義，但我們將添加一個(gè)專(zhuān)用的API來(lái)傳遞TLS密鑰材料。這將解耦通過(guò) LDS/CDS 發(fā)送主要監(jiān)聽(tīng)器、集群配置和通過(guò)專(zhuān)用密鑰管理系統(tǒng)發(fā)送秘鑰素材。

譯者注：目前 xds 中沒(méi)有 kds 的定義，但是有一個(gè)Secret Discovery Service，應(yīng)該是這個(gè) kds 的改名。以上 API 請(qǐng)參考 https://github.com/envoyproxy/data-plane-api/tree/master/envoy/api/v2

總的來(lái)說(shuō)，我們稱(chēng)所有上述 API 為 xDS。 從 JSON/REST 到 proto3 API 的過(guò)渡非常令人興奮，良好類(lèi)型的 proto3 API 可以更容易使用，我認(rèn)為這將進(jìn)一步提高 API 本身以及 Envoy 的接受度。

多代理多控制平面的 API？

服務(wù)網(wǎng)格/負(fù)載均衡領(lǐng)域現(xiàn)在非常活躍。代理包括 Envoy、Linkerd、NGINX、HAProxy、Traefik，來(lái)自所有主要云提供商的軟件負(fù)載均衡器，以及傳統(tǒng)硬件供應(yīng)商（如 F5 和思科）的物理設(shè)備。隨著眾多解決方案的出現(xiàn)，如 Istio、Nelson，集成云解決方案以及許多供應(yīng)商即將推出的產(chǎn)品等，控制平面領(lǐng)域也在不斷升溫。

特別討論一下 Istio，Linkerd 已經(jīng)宣布對(duì)它的支持，這意味著至少在某種程度上它已經(jīng)實(shí)現(xiàn)了 v1 Envoy API。其他人可能會(huì)跟隨。 在這個(gè)數(shù)據(jù)平面和控制平面快速發(fā)展的新世界中，我們將看到組件的混合和匹配；數(shù)據(jù)平面將與許多控制平面一起工作，反之亦然。我們是否可以讓業(yè)界受益于一種通用 API，讓這種混合和匹配更容易實(shí)現(xiàn)？ 這會(huì)有什么幫助？

在我看來(lái)，在接下來(lái)的幾年中，數(shù)據(jù)平面本身將大部分商品化。大部分創(chuàng)新（和商業(yè)機(jī)會(huì)擴(kuò)展）實(shí)際上將成為控制平面的一部分。使用 v2 Envoy API，控制平面功能的范圍可以會(huì)從使用 N2 健康檢查的扁平端點(diǎn)命名空間擴(kuò)展到一個(gè)非常豐富的全局負(fù)載均衡系統(tǒng)，該系統(tǒng)可進(jìn)行自動(dòng)構(gòu)造子集、負(fù)載裝卸和均衡、分布式局部健康檢查、區(qū)域感知路由、基于百分比的自動(dòng)部署和回滾等。供應(yīng)商將在提供無(wú)縫的微服務(wù)運(yùn)維環(huán)境方面展開(kāi)競(jìng)爭(zhēng)，而對(duì)路由的自動(dòng)化控制將是其競(jìng)爭(zhēng)中的主要部分。

在這個(gè)新的世界中，數(shù)據(jù)平臺(tái)可以用來(lái)與控制平面進(jìn)行通訊的通用API對(duì)每個(gè)參與者都是一個(gè)勝利。控制平面提供商可以將它們的服務(wù)提供給實(shí)現(xiàn)該API的任何數(shù)據(jù)平面。數(shù)據(jù)平面可以在功能，性能，規(guī)模和健壯性方面展開(kāi)競(jìng)爭(zhēng)。此外，解耦允許控制平面提供商提供 SaaS 解決方案，而不需要同時(shí)擁有數(shù)據(jù)平面部署，這是一個(gè)主要的痛點(diǎn)。

Envoy API 合作邀請(qǐng)

雖然很難知道未來(lái)幾年會(huì)發(fā)生什么，但我們對(duì) Envoy 及其相關(guān) API 的采用感到非常興奮。我們看到了通用的數(shù)據(jù)平面 API 的價(jià)值所在：可以橋接不同系統(tǒng)。根據(jù)這些原則，我們邀請(qǐng)更大的數(shù)據(jù)平面和控制平面供應(yīng)商以及用戶(hù)與我們?cè)?envoy-api 存儲(chǔ)倉(cāng)庫(kù)中進(jìn)行協(xié)作（請(qǐng)注意，當(dāng)Envoy 進(jìn)入 CNCF 并轉(zhuǎn)換到專(zhuān)用的 envoyproxy GitHub 組織時(shí)，我們將重命名該存儲(chǔ)倉(cāng)庫(kù)為 data-plane-api）。我們不保證我們將添加所有可能的功能，但我們希望看到其他系統(tǒng)使用這些 API 并幫助我們改進(jìn)它們以滿(mǎn)足他們自己的需求。我們的觀點(diǎn)是，數(shù)據(jù)平面的商品化將為最終用戶(hù)帶來(lái)巨大收益，這有助于控制平面領(lǐng)域提高迭代和競(jìng)爭(zhēng)速度，未來(lái)幾年大部分創(chuàng)新將會(huì)發(fā)生在控制平面。

英文原文發(fā)布于2017年9月6日，本文發(fā)出時(shí) Envoy 已經(jīng)進(jìn)入了 CNCF，成為了官方項(xiàng)目，Envoy 原來(lái)的代碼都已經(jīng)被重構(gòu)和遷移，本文中提到的很多鏈接都已過(guò)時(shí)，請(qǐng)大家參考 Envoy 官網(wǎng) https://www.envoyproxy.io/，也可以查看 Envoy 官方文檔中文版 https://servicemesher.github.io/envoy/。

本文譯者敖小劍老師將于11月24日在GIAC上海站發(fā)表重磅演講《knative: 重新定義Serverless》，歡迎屆時(shí)光臨。本周購(gòu)買(mǎi)GIAC門(mén)票可享88折優(yōu)惠，高可用架構(gòu)會(huì)員低至6折。

活動(dòng)預(yù)告：

11 月 23 ~ 24 日，GIAC 全球互聯(lián)網(wǎng)架構(gòu)大會(huì)將于上海舉行。GIAC 是高可用架構(gòu)技術(shù)社區(qū)推出的面向架構(gòu)師、技術(shù)負(fù)責(zé)人及高端技術(shù)從業(yè)人員的技術(shù)架構(gòu)大會(huì)。今年的 GIAC 已經(jīng)有微軟，騰訊、阿里巴巴、螞蟻金服，華為，科大訊飛、新浪微博、京東、七牛、美團(tuán)點(diǎn)評(píng)、餓了么，才云，格靈深瞳，Databricks，等公司專(zhuān)家出席。本周購(gòu)買(mǎi)可享門(mén)票88折優(yōu)惠，高可用架構(gòu)會(huì)員低至6折。

本期 GIAC 大會(huì)上，Cloud Native部分精彩的議題如下：

參加 GIAC，盤(pán)點(diǎn)2018最新技術(shù)。點(diǎn)擊“閱讀原文”了解大會(huì)更多詳情。

總結(jié)

以上是生活随笔為你收集整理的Service Mesh中的通用数据平面API设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。