翻譯 | 宋鬆
原文 | https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42
本週我開始寫一篇比較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已經連續四年（2016、2017、2018、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/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb）
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/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb）
意識到Mixer所增加的處理時間，Istio團隊目前正致力於重寫Mixer組件：“Mixer將用c++重新並直接嵌入到Envoy中。將不再有任何獨立的Mixer服務。這將提高性能並降低運營複雜性。”
—Source Mixer V2 Design Document（https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s/edit）
總結
是的，Istio比Linkerd2.3有多的特性。這是很好的，更多的特性意味着處理更復雜和邊緣用例的能力增強。這沒什麼神奇的，更多的特性通常意味着更多的配置，潛在的資源利用率和運營成本的增加，所有這裏有三條建議：
-
如果你不知道80%最常見的工作負載是什麼樣子的，那麼你將很難選擇服務網格。如果你不知道這些數字，你的企業可能還沒有準備好進行服務網格的使用。如果你只是在探索，那就另當別論了。
-
如果你想計劃解決所有可能的當前和未來的cases（通常叫做comparison spreadsheet），那麼你將會有一段糟糕的時間。你很可能會過度獲取，這對你購買的任何軟件都是如此。
- 盲目的選擇一種技術或另一種會讓你過的很糟糕。炒作可能很厲害，但請記住，你並不是在炒作業務（除非真的在炒作）。
試試Istio和Linkerd！ Solo SuperGloo是最簡單的方式。
我使用SuperGloo是因爲它非常簡單，可以快速啓動兩個服務網格，而我幾乎不需要做任何努力。我們並沒有在生產中使用它，但是它非常適合這樣的任務。每個網格實際上是兩個命令。
——Michael Kipper — Benchmarking Istio & Linkerd CPU — Shopify（https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781）。
在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/）。
本文由博雲研究院原創翻譯發表，轉載請註明出處。