Linkerd or Istio？哪一個Service Mesh框架更適合你？

翻譯 | 宋鬆
原文 | https://medium.com/solo-io/li...

本週我開始寫一篇比較Istio和Linked的帖子，而且告訴我本身：我將用一個表格來比較二者的特性，這將會很棒，人們會愛上它，這個世界將會幸福幾秒鐘。我向本身承諾這將是一個公平的比較，沒有任何偏見。雖然比較的表格仍然存在，但我轉移了文章的終點：目標再也不是哪一個更好，而是哪一個更適合你、你的應用程序和你的組織。

在職業生涯的一段時間中，我曾擔任某公司的售前架構師，記得有不少次咱們被要求填寫產品比較表。我常常須要運用創造力來確保產品看起來很好，幾乎不惜一切代價避免表格中使人不愉快的「不支持」的框。考慮到誠信工做，可是有時候不得不這樣作。

站在評價者的角度來看，我理解他們（但願）的目的是進行公平的比較，在這種程度上，對比的表格彷佛是一種可靠的方式。咱們知道一個項目的成功能夠預測職業的發展，咱們都喜歡這一點。但問題是：若是評估的最終目標是產品對比表格，而不是能讓企業更有競爭力的高質量軟件，那麼這個評估的最後將只是一些「表格」的工做。

產品比較並非最終目的，經過比較知道哪些對你的用例最好纔是最終目的。所以讓咱們經過七個方面來深刻研究Service Mesh，主要是如下幾個方面：

• 流量管理
• 安全
• 安裝/配置
• 支持的環境
• 監測
• 策略管理
• 性能

對於上述七個方面中的每個，我都將發表我的觀點，但願個人觀點可以幫你作出更接近於簡潔的決策。

流量管理

須要強調的是，Istio和Linkerd的區別在於數據平面使用了兩種不一樣的代理技術。

Istio使用Envoy做爲其代理。Envoy是C++編寫的，最初是由Lyft構建，以便以非Kubernetes方式促進微服務的流量管理。許多公司已經將Envoy擴展爲Kubernetes的ingress技術。

Linkerd（v2）使用的是一種名爲Linkerd-proxy的專用服務網格代理。這個代理是使用Rust編寫的，與該代理一塊兒，許多低級代理（網絡客戶機與服務器）功能在另外一個也是由rust編寫名爲Tower的項目中實現。Tower依賴於Tokio，Tokio是一個由Rust編寫的事件驅動非阻塞I/O庫。若是你和我同樣欣賞統計學，那麼Rust已經連續四年（201六、201七、201八、2019）一直是Stack-overflow最受歡迎的語言。

Istio是構建與Envoy之上的所以在流量管理方面它是佔據優點的，Envoy已經包含了重要的IMHO功能，好比子集路由。用戶仍然可使用Linkerd實現金絲雀/藍綠/a-b發佈，但必須依靠單獨的Kubernetes服務和可以分發流量的集羣ingress技術，好比Gloo（gloo.solo.io）。

Linkerd團隊在最近一次社區會議上公開表示，計劃在將來的版本中實現更加高級的L7流量管理功能。

安全

關於安全，我正在考慮保護通訊通道的能力。Istio和Linkerd二者都提供了合理的安全保護功能。

Istio和Linkerd都依賴於外部根證書，所以二者都能保證進行安全通訊。這聽起來像是一個很好的週末項目，你以爲呢？

安裝和配置

鑑於Istio能夠安裝在許多不一樣的平臺上，安裝說明可能會存在很大的不一樣。在寫這篇文章的時候，關於Linkerd的安裝，我對一些預先須要安裝功能的檢查印象很深入。有不少次我在共享的Kubernetes集羣中安裝一些Linkerd功能時，我不清楚我是否擁有必要的權限。對於Linkerd，pre-check（或check-pre）檢查你是否擁有在安裝過程當中建立Kubernetes所需資源的權限。

環境支持和部署模型

對因而選擇kubernetes或者是非Kubernetes安裝，這是一個很直接的問題，Linkerd2是用基於kubernetes方式構建的，至少目前是這樣的，而Istio收到了一下其餘的公司的貢獻，但願istio能在非kubernetes環境中運行。

考慮多集羣部署，客觀來講對於它的解釋可能很棘手。從技術上來說，共享根CA證書的多個不一樣集羣（具備不一樣的控制平面）上的服務之間能夠有效的通訊。

Istio擴展了上述概念，由於它支持不一樣情形下的多個集羣：

• 單個控制平面便可知足不一樣集羣之間網絡鏈接和pod之間IP尋址。
• 經過使用具備單個控制平面的集羣邊界網關（egress和ingress）便可訪問多個集羣上的kubernetes API服務器。

在上述兩種狀況下，包含控制平面的集羣將成爲mesh管理的SPOF（single point of failure）。在咱們這個能夠在同一區域下的多個可用區域上部署單個集羣的世界中，這將再也不是一個問題，但仍然不能徹底忽略它。

監測

能夠說Istio的管理控制檯是一個缺失的部分。 Kiali Observability Console確實解決了一些管理員對service mesh所需的一些需求。

Kiali（κιάλι）是一個希臘詞，意思是望遠鏡，從Kiali的網站上能夠清楚的看到它打算成爲一個可監測性的控制檯，而不只僅是一個Service Mesh管理控制檯。

Linkerd控制檯還不完整，可是社區決定也要構建一個管理儀表盤的目標是一個優點。

Linkerd未能提供請求追蹤。想要以非侵入方式查看請求追蹤跨度必須等待Linkerd實現該功能。Istio利用了Envoy支持添加追蹤headers的事實。

應該提醒用戶，應用程序須要準備好轉發跟蹤headers，若是沒有準備，代理能夠生成新的跟蹤IDS，這可能會無心中將單個請求分割爲多個請求跨度使請求之間失去必要的關聯性。大多數開發框架都有轉發headers的選項，而無需用戶編寫大量的代碼。

策略管理

Istio的愛好者，請歡欣鼓舞！Istio的策略管理能力使人印象深入。

該項目構建了一個可擴展的策略管理機制，容許其餘技術可從多個方面與Istio集成，請參閱下面的「template」列表以及一些集成的提供者。你能夠認爲「template」是一種集成。

爲了突出其餘策略類型，Istio也可適用於rating和limiting以及提供對主體身份驗證的開箱即用支持。Linkerd用戶依賴集羣ingress控制器提供rating和limiting。

對於主體身份驗證，我一直認爲它應該委託給應用程序。請記住#4分佈式計算的謬論：網絡是安全的。對此持零信任策略。

Istio使人印象深入的策略管理能力是須要代價的。考慮到他的普遍性，管理衆多的選項增長了本已昂貴的運營成本。

Istio（Mixer）的策略管理組件也增長了顯著的性能，咱們將在下面詳細討論。

性能

對比表在哪裏？幸運的是，就在最近，發佈了兩個很棒的博客，對Istio和Linkerd的性能進行了比較，我在下面引用了其中一些結論：

對於這種綜合工做負載，Istio的Envoy代理使用比Linkerd多50%的CPU。Linkerd的控制平面使用了一小部分Istio，特別是在考慮「core」組件時。

——Michael Kipper — Benchmarking Istio & Linkerd CPU（https://medium.com/@ihcsim/li...）

And…

在本實驗中，與基線設置相比，Linkerd2-meshed設置和Istio-meshed設置都經歷了更高的延遲和更低的吞吐量。在Istio-meshed設置中產生的延遲高於在Linkerd2-meshed設置中觀察到的延遲。Linkerd2-Meshed設置可以處理比Istio-Meshed設置更高的HTTP和GRPC ping吞吐量。

——Ivan Sim — Linkerd 2.0 and Istio Performance Benchmark（https://medium.com/@ihcsim/li...）

意識到Mixer所增長的處理時間，Istio團隊目前正致力於重寫Mixer組件：「Mixer將用c++從新並直接嵌入到Envoy中。將再也不有任何獨立的Mixer服務。這將提升性能並下降運營複雜性。」

—Source Mixer V2 Design Document（https://docs.google.com/docum...）

總結

是的，Istio比Linkerd2.3有多的特性。這是很好的，更多的特性意味着處理更復雜和邊緣用例的能力加強。這沒什麼神奇的，更多的特性一般意味着更多的配置，潛在的資源利用率和運營成本的增長，全部這裏有三條建議：

• 若是你不知道80%最多見的工做負載是什麼樣子的，那麼你將很難選擇服務網格。若是你不知道這些數字，你的企業可能尚未準備好進行服務網格的使用。若是你只是在探索，那就另當別論了。
• 若是你想計劃解決全部可能的當前和將來的cases（一般叫作comparison spreadsheet），那麼你將會有一段糟糕的時間。你極可能會過分獲取，這對你購買的任何軟件都是如此。
• 盲目的選擇一種技術或另外一種會讓你過的很糟糕。炒做可能很厲害，但請記住，你並非在炒做業務（除非真的在炒做）。

試試Istio和Linkerd！ Solo SuperGloo是最簡單的方式。

我使用SuperGloo是由於它很是簡單，能夠快速啓動兩個服務網格，而我幾乎不須要作任何努力。咱們並無在生產中使用它，可是它很是適合這樣的任務。每一個網格其實是兩個命令。

——Michael Kipper — Benchmarking Istio & Linkerd CPU — Shopify（https://medium.com/@michael_8...）。

在Solo.io（https://www.solo.io/），咱們但願爲你的服務網格採用之旅提供便利。 Solo SuperGloo咱們的服務Mesh orchestrator能夠經過直觀簡單的命令安裝和管理流行的服務網格技術。 正如Michael上面所指出的那樣，安裝Istio或Linkerd會成爲一個單行活動。 SuperGloo並不止於此，它在不一樣的服務網格技術之上提供了一個抽象，容許對多個網格進行一致且可重複的操做。 SuperGloo是徹底開源的，you can try it right now（https://supergloo.solo.io/）。

本文由博雲研究院原創翻譯發表，轉載請註明出處。