爲何Linkerd不使用Envoy

你填了嗎？2020年CNCF中國雲原生問卷

問卷連接（https://www.wjx.cn/jq/9714648...）

---

做者：William Morgan

(Photo by Paul Felberbauer on Unsplash)

在這篇文章中，我將描述爲何Linkerd不是創建在Envoy之上。

這是一篇寫起來有點奇怪的文章。畢竟，Linkerd沒有使用過上百萬個項目，並且這些決策都不值得在博客上發表。可是Linkerd沒有特別使用Envoy這一事實已經成爲一個足夠常見的討論話題，所以它可能值得一個很好的解釋。

我還要聲明，這不是一篇「糟糕的Envoy」的博客文章。Envoy是一個偉大的項目，顯然是許多人的選擇，咱們對從事這項工做的優秀人士只有尊敬。咱們天天都向Linkerd用戶推薦使用了Envoy的入口控制器，像Ambassador，而在世界各地的生產系統中，你能夠發現Envoy和Linkerd並肩工做。

可是咱們沒有選擇在Envoy之上創建Linkerd。相反，咱們構建了一個專用的「微代理」，簡稱爲Linkerd2-proxy，它是針對服務網格邊車用例進行優化的。在日益擁擠的同類服務網格項目領域，Linkerd在這方面獨樹一幟。但咱們爲何要走這條路呢？

對這個問題的完整回答本質上是細緻入微的和技術性的--確切地說，就是那些在流行的、博客驅動的雲原生應用世界中容易被淹沒的內容。因此在這篇文章中，我將盡我最大的努力以一種坦率和專一於工程的方式來闡述緣由。畢竟，Linkerd是由工程師建立的，也是爲工程師服務的，若是說有一件事讓我感到驕傲的話，那就是咱們是在工程權衡的基礎上作出決定的，而不是市場壓力。

簡而言之：Linkerd不使用Envoy，由於使用Envoy不容許咱們創建世界上最輕、最簡單、最安全的Kubernetes服務網格。

做爲最輕、最簡單、最安全的Kubernetes服務網格是Linkerd對用戶的承諾，這也使得Linkerd在服務網格中獨一無二：它很是簡單，更輕，更安全。而咱們可以作到這一點的緣由是--你猜對了--由於咱們創建在Linkerd2-proxy而不是Envoy的基礎上。不是由於Envoy很差，而是由於Linkerd2-proxy更好--至少對於做爲Kubernetes邊車代理的很是具體和有限的用例來講。

讓咱們來看看緣由。

Linkerd2-proxy是什麼？

在深刻討論細節以前，有必要進一步瞭解一下Linkerd2-proxy。

Linkerd2-proxy是專門爲服務網格邊車用例設計的「微代理」。Linkerd2-proxy構建在大約2020年的世界上最現代的網絡編程環境之上，並驅動了許多需求：Rust異步網絡生態系統，包括像Tokio、Tower和Hyper這樣的庫。就純粹的技術進步而言，Linkerd2-proxy是整個CNCF景觀中最早進的技術之一。

像Envoy同樣，Linkerd2-proxy是一個100%開源的Apache v2 CNCF項目，其特色是按期的第三方審計，一個活躍的社區，以及在世界各地的關鍵任務系統中的大規模生產使用。與Envoy不一樣的是，Linkerd2-proxy僅設計用於一種用例：在從Linkerd控制平面接收配置的同時，將請求從一個Kubernetes pod代理到另外一個Kubernetes pod。與Envoy不一樣的是，Linkerd2-proxy被設計成一個實現細節：它不是面向用戶的，它不能做爲一個通用的構建塊使用，它有一個無聊的名字。這意味着Linkerd2-proxy每每會被忽視，儘管咱們最近在一些文章中對其進行了深刻研究，並在路線圖中給出了一些解釋。

那麼，爲何叫「微代理（micro-proxy）」呢？儘管咱們要在詞典中引入另外一個術語，但「代理」這個詞並不能徹底表明Linkerd2-proxy。代理相似於Envoy、NGINX、Apache或httproxy。這些項目能夠作各類各樣的事情（「將帶有匹配此通配符的路徑的HTTP請求發送到此後端，同時重寫這些頭文件、壓縮任何Javascript文件和旋轉訪問日誌」），而且它們有一個配置和調優表面來匹配。在生產環境中使用代理須要大量的操做投資：若是你正在運行Apache，那麼你將在某個地方找到Apache專家。

可是Linkerd2-proxy是不一樣的。它被設計成一個實現細節，不須要專門的知識或專門的操做投資（儘管Linkerd做爲一個總體，固然，確實須要投資）。沒有面向用戶的YAML；相反，經過注入時設置的少許環境變量和運行時由Linkerd控制平面自動配置Linkerd2-proxy。咱們將Linkerd2-proxy的調優範圍保持在最低限度，以便最終用戶不多須要直接接觸它。簡而言之：Linkerd2-proxy被設計成隱藏在幕後，做爲一個實現細節，而且僅僅工做。

簡而言之：Linkerd2-proxy與Envoy、NGINX和Apache等代理有很大的不一樣，「proxy」這個詞並不能很好地表明它。

複雜性

那麼爲何咱們要創建Linkerd2-proxy而不是Envoy呢？一個主要緣由是複雜性。

Envoy是一種靈活的、通用的代理，這也是它受歡迎的主要緣由。你可使用Envoy做爲一個入口，做爲一個出口，做爲一個服務網格邊車，以及在許多其餘方式。可是這種靈活性帶來了複雜性。

做爲一個比較，截至2020年11月，Envoy倉庫的C++代碼爲172 KLOC，「複雜性得分」（以分支和循環衡量）爲19k。相比之下，Linkerd2-proxy只有30 KLOC，複雜度得分爲1.5k。換句話說：Linkerd2-proxy代碼基比Envoy小5倍，經過這種方法，它的複雜性比Envoy小10倍

固然，這不是一個蘋果對蘋果的計算。它不捕獲倉庫以外的庫或依賴項；複雜性分數不能在語言之間嚴格地移植；等等。但它可讓你大體瞭解這些項目的相對規模：就內部而言，Linkerd2-proxy比Envoy要小几個數量級，也要簡單幾個數量級。

這種複雜性是Envoy的失敗嗎？不。Envoy有不少複雜的代碼由於它能夠作不少複雜的事情。可是，這種複雜性是構建專一於簡單性（尤爲是操做簡單性）的項目的很是困難的基礎。

簡而言之：Envoy是瑞士軍刀。Linkerd2-proxy是一根針。

資源消耗

對於任何基於邊車的服務網格，有一點是清楚的：你將會有不少代理。

這意味着數據平面消耗的CPU和內存是運行服務網格成本的關鍵組成部分，尤爲是在應用程序擴展時。

使用Linkerd2-proxy容許咱們嚴格控制Linkerd的資源消耗。例如，在咱們使用Kinvolk的開源基準測試工具對Linkerd和Istio進行的內部基準測試中，以每秒4000個請求的接入流量，咱們看到Linkerd2-proxy實例的內存始終在14mb到15mb之間，而Istio的Envoy的內存在135mb到175mb之間，是這個大小的10倍。相似地，Linkerd2-proxy在測試運行中的CPU使用始終爲每一個實例15ms （CPU毫秒），而Istio的Envoy在22ms到156ms之間--多50%到多10倍。

一樣，這不是一個徹底公平的比較。這些是針對特定應用程序和特定配置的內部基準測試，毫無疑問，Istio的一些設計決策在這裏扮演了重要角色。但Istio是由世界一流的工程師建造的，關鍵是：若是Linkerd是在Envoy上建造的，咱們將不得不本身作出許多一樣的設計決定。

簡而言之：在實踐中，在服務網格上下文中，Linkerd2-proxy使用的系統資源只是Envoy所使用的系統資源的一部分。

安全

最後一點也許是最富哲理的一點：安全。數據平面的安全性對於任何服務網絡都是一個巨大的問題。例如，Linkerd在世界各地的生產中被用於處理異常敏感的數據，從健康信息到我的可識別的細節再到金融交易。

咱們沒有理由認爲Envoy是不安全的。可是從某種程度上說，它是安全的（特別是在C++代碼的170+ KLOC的狀況下），它是安全的，它是經過讓許多很是聰明的工程師使用它、檢查它、歸檔CVEs、修復bug和重複的手工和昂貴的過程來實現的。這是軟件安全的「傳統過程」，並且至少在適當的時候是有效的。它也很昂貴、困難並且容易失敗。C++代碼的安全性是出了名的難，即便對最有經驗的程序員也是如此。

更重要的是，這不是咱們但願Linkerd所依賴的安全模型，也不是咱們所相信的系統編程安全的將來。咱們選擇Rust做爲Linkerd2-proxy是有意爲之的：Rust的內存安全性使咱們能夠放心地在Linkerd2-proxy中編寫安全代碼，從而將咱們對人類發現問題的依賴最小化。固然，這並非說Linkerd2-proxy不存在安全漏洞！相反，它將擁有更少的；咱們須要少依賴本身卑微的才能來避免它們；咱們將再也不常常要求咱們的用戶對他們的系統進行關鍵升級，以保持安全。

簡而言之：Linkerd2-proxy的Rust基礎讓咱們對Linkerd的數據平面的安全性有了信心。

Linkerd可使用Envoy嗎？

簡單性、資源消耗和安全性是咱們決定不採用Envoy的驅動因素。然而，咱們相信代理的選擇最終是一個實現細節。雖然咱們在Linkerd2-proxy上投入了大量的資金，但咱們也會按期從新評估Envoy。我能夠明確地說，若是對咱們的用戶來講，這個折衷方案對Envoy有利，咱們將毫無疑問地採用它。

不過，咱們對將來的服務網絡採納者的建議很簡單：忽略這些噪音。你的工做不是「使用服務網絡」或「採用Envoy」，甚至「只使用CNCF技術」。你的工做是清楚地瞭解你要解決的問題，而後選擇最能解決它的解決方案。不管你選擇什麼，你都將不得不接受它--因此確保你的決策是基於具體的需求和充分理解的工程權衡，而不是基於時尚或趨勢。

常見問題解答

那麼爲何這麼多的服務網格使用Envoy？

由於編寫本身的現代、可伸縮、高性能網絡（微）代理很是困難。真的很難。在過去的幾年裏，構建Linkerd2-proxy和Rust網絡庫使之成爲多是許多人付出的巨大努力。除非你的項目既具有技術實力，又有解決這一挑戰的願望，不然使用Envoy要容易得多。

可是Envoy不是服務網格的「標準」嗎？

不是。一個標準是互操做性所必需的東西。對服務網格相當重要的標準是TCP或HTTP，或者像SMI這樣容許在服務網格之上構建工具的標準。（例如，這是Argo經過SMI爲canary發佈驅動Linkerd的絕佳例子。）

Envoy做爲服務網格數據平面代理的廣泛選擇並非一個標準，而是一個簡單的共性。Envoy成爲一個「服務網格標準」意味着什麼？咱們能夠把數據平面保留在原來的位置，而後換掉控制平面？咱們能夠用不一樣的控制平面操做同一個數據平面？這些都是牽強附會的用例。

但若是咱們要求使用Envoy呢？

我認爲這不是一個真正的要求。你的工做不是採用某一特定的技術。你的工做是解決問題。

若是你的問題是「咱們須要創建一個可靠的、安全的、可觀察的Kubernetes平臺，而不須要付出瘋狂的複雜性成本」，那麼我強烈建議你考慮看看Linkerd。

如今誰在生產中使用Linkerd2-proxy？

每一個使用Linkerd的人都使用Linkerd2-proxy。這意味着你能夠找到Linkerd2-proxy爲Nordstrom、微軟、H-E-B、Chase、Clover Health、HP等公司的關鍵生產架構提供支持。

其餘的服務網格項目可使用Linkerd2-proxy嗎？

不太可以。可是任何對構建高性能超輕網絡代理感興趣的人均可以使用支持Linkerd的底層Rust網絡庫。

聽起來使人驚歎！我如何開始使用Linkerd？

我沒想到你會問。你能夠在大約5分鐘內安裝Linkerd，包括相互TLS，不須要配置。從咱們的入門指南開始。

Linkerd適用於全部人

Linkerd是一個社區項目，由CNCF託管。若是你有功能需求、問題或評論，咱們歡迎你加入咱們快速增加的社區！Linkerd託管在GitHub上，咱們在Slack、Twitter和郵件列表上都有一個蓬勃發展的社區。來一塊兒玩吧！

點擊閱讀網站原文。

---

CNCF (Cloud Native Computing Foundation)成立於2015年12月，隸屬於Linux  Foundation，是非營利性組織。
CNCF（雲原生計算基金會）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。咱們經過將最前沿的模式民主化，讓這些創新爲大衆所用。掃描二維碼關注CNCF微信公衆號。