Service Mesh框架對比：Linkerd vs. Istio

EAWorld發表於2019-03-25
框架

Service Mesh框架對比：Linkerd vs. Istio

本文由公眾號EAWorld翻譯發表，轉載需註明出處。

作者：Marcus Schiesser 

譯者：白小白 

原題：Comparing Service Meshes: Linkerd vs. Istio

原文：http://t.cn/Ext9FpD


引言：

各個細分行業和領域的組織機構正在持續的加速採用微服務架構。隨之而來的是容器的使用以及端點和服務通訊的爆炸式增長。企業內部的複雜性和不確定性正在不斷增加。如何在這樣的情況下實現對規模化通訊安全性和可見性的管理頗具挑戰。因此，無論是運營者或者開發者都強烈渴望將網路層的複雜性封裝為一個新的網路基礎架構層。當此之時，處理此事的最流行的方式是服務網格（Service Mesh）。

因此，在本文中，我們將對比兩種主流的服務網路的特性，以找出兩者的異同之處，即Linkerd和Istio。文中也會提及有關服務網格使用的爭論，探尋在某種特定的場景下，基於特定的用例和架構，何者比何者更具優勢。

一、服務網格是什麼？

服務網格是一個專有的基礎設施層，這一層級的存在可以使得微服務架構內部的服務間通訊更加可靠、快捷和安全。其基本的理念是在服務間插入一個代理組成的網路來實現對網路層的抽象。一言以蔽之，服務網格的設計初衷就是幫助開發者解決微服務間的互動挑戰。

二、Istio是什麼？

Istio是由Google、IBM和Lyft發起的開源的服務網格專案。該專案在2017年推出，並在2018年7月釋出了1.0版本。Istio基於Envoy代理並以之為資料層（data plane）。可以說Istio是如今最炙手可熱的服務網格，但由於僅應用於Kubernetes，其應用價值受到某種限制。

三、Linkerd是什麼?

Linkerd（音似chickadee），最初是由Buoyant團隊於2016年打造的一個服務網格專案。Linkerd是CNCF的官方專案，基於Twitter的Finagle專案並和後者一樣，最初是由Scala語言編寫，設計理念是支援基於主機（物理主機或者虛擬節點）的部署模式。由於最初版本的記憶體佔用廣受詬病，導致了Conduit專案的開發，Conduit是一個輕量級的服務網格，為Kubernetes定製，用Rust和Go語言編寫。Conduit專案目前已經合併到Linkerd專案，並在2018年7月釋出為Linkerd 2.0 版本。鑑於Linkerd 2.x 基於Kubernetes，而Linkerd 1.x 可以基於節點的模式部署，當面臨複雜環境的場景時，人們可以有更靈活的選擇。除非特指，本文的比較都是基於Linkerd 2.x。


四、特性和功能對比

  • 架構

Istio和Linkerd都支援以主流的外掛（Sidecar）模式部署。在這種模式下，每個微服務都被分配一個單獨的代理。微服務間的通訊並不直接進行，而是通過自身的代理轉發。代理會將請求路由到目標微服務的代理，該代理再將請求轉發到目標微服務。所有這些服務代理構成了資料層。在服務網格的架構下，資料層由控制層（control plane）來進行配置和監控，控制層一般另行獨立部署。

Service Mesh框架對比：Linkerd vs. Istio


架構圖示意：以Istio為例。Envoy代理以外掛形式部署。在這樣的部署模型中，代理將注入每個容器單元，因此可以獨立的配置。Istio控制層由很多的元件組成，用來對服務間通訊進行配置、度量、控制和安全管控。

  • 控制層

控制層的使命是通過一系列API和工具對服務網格內的代理實現控制。在控制層中，可以將整個資料層作為一個整體來指定認證策略，收集度量指標，進行配置。

Istio的控制層由三個元件構成。首先是Pilot，負責配置資料層。其次是Mixer，負責收集通訊流量的度量指標，並響應資料層各種不同的查詢請求，包括授權、訪問控制和配額查詢等。基於所啟用的介面卡的不同，Mixer也可與日誌和監控系統進行對接。最後是Citadel，這個元件允許開發者基於服務身份認證而非網路控制建立一個零信任（零信任，zero-trust，簡單講，即假定所有通訊方不可信賴並必須進行驗證）機制的網路環境。Citadel負責為每個服務指定證書，如果有需要，也可以接受外部的證書授權金鑰。


白小白：

Service Mesh框架對比：Linkerd vs. Istio


Linkerd的控制層由一個Web元件、一個控制元件和一個度量元件組成。Web元件提供了基於Web的管理控制皮膚。控制元件由多個容器部署組成。完成了控制層的多數功能（包括聚合遙測資料，提供使用者介面API，為資料層提供控制資料等）。度量元件由定製化的Prometheus和Grafana組成。Prometheus負責抓取Linkerd暴露的度量指標並儲存下來。Linkerd本身會生成很多外部皮膚，Grafana負責渲染和展現這些皮膚。

  • 資料層

在一個典型的服務網格環境中，服務的部署過程將納入一個專有的外掛代理。如前文所述，服務並不直接向網路傳遞訊息，而是由本身的代理來進行通訊。這樣的機制封裝了服務間通訊的複雜性。服務網格內的代理之間相互連線，構成了資料層。

預設情況下，Istio使用Envoy作為資料層，Envoy原本是設計用來與其他型別的代理（比如Nginx）來進行工作的。Linkerd使用自有的代理。

  • 平臺支援

儘管聲稱支援大量的環境和框架，但在實踐中，Istio僅能與kubernetes相處融洽，這嚴重限制了他的應用範疇。

Linkerd 2.x目前也需要與Kubernetes協同工作。然而Linkerd 1.x 部署廣泛，並處於活躍的研發狀態，可以在多種環境和框架下工作，包括與AWS ECS、DC/OS和Docker協同工作。能夠支援如此廣泛的環境，得益於Linkerd 1.x 可以基於主機的部署模式，這使得其可以與使用者的環境進行整合而無需以外掛的形式部署。

Service Mesh框架對比：Linkerd vs. Istio


Linkerd 1.x 主機部署模式：linkerd服務網格可以基於主機部署。基於這樣的模式，同一主機的多個微服務共享一個Linkerd（1.x）例項。

主機部署模式的主要缺點在於單點代理的失敗將影響多個微服務。從另一方面講，主機部署模式相對於外掛模式對資源的消耗更低。

  • 協議支援

基於外掛代理，Istio和Linkerd 2.x 都支援HTTP 1.1, HTTP2, gRPC和TCP協議的服務間通訊。但Linkerd 1.x 不支援TCP連線。

  • 實現語言

Istio的控制層和Linkerd 2.x 都是用Go語言編寫的，Istio資料層的Envoy代理是由C++編寫的，Linkerd 2.x 的資料層是用Rust編寫的。Linkerd 1.x 是用Scala編寫的。

  • 安全、加密和授權

Istio的控制層元件提供瞭如下的安全功能： Citadel：金鑰和證書管理。 Pilot：認證策略和安全命名資訊的分發。 Mixer：授權和審計的管理。 外掛：實現代理間基於TLS加密的安全通訊。

本文成文時，Linkerd的自動化的TLS加密還處於實驗階段，主機間認證也還未獲支援。

  • 外掛注入

將外掛加入到部署包並且在服務網格的控制層進行註冊的過程即為“外掛注入”。Istio和Linkerd都支援手動和自動的外掛注入。

  • 高可用性

Istio支援高可性，當且僅當配置了Kubernetes的多副本模式，並且開啟podAntiAffinity開關的情況下。

linkerd的高可用性目前仍處於實驗階段。

  • 監控和跟蹤

Istio原生支援Prometheus並且整合了Jaeger來進行分散式跟蹤。Linkerd支援Prometheus和Grafana從外部進行監控，但目前並不支援分散式跟蹤。

  • 效能

Linkerd 2.x 在效能上的常規開銷總體上比Istio要低一些。一項關於兩者的效能測試表明，基於一組由HTTP請求組成的測試負載，每秒的千次查詢數（kqps）基準值是30-35kqps，經由代理轉發後，效能會有所下降，Linkderd降到了10-12kqps，而Istio則降到了3.2-3.9kqps。


五、什麼時候應該謹慎使用服務網格？

有五個主要的原因，可能阻止你考慮使用服務網格來管理微服務架構所帶來的潛在的網路複雜性挑戰。

1、服務網格具有排他性

服務網格是一個平臺解決方案，因此是排他性的。這意味著你將被迫在“服從他們的方式”和“基於我自己的業務和技術考量選擇適合的方式”之間做出選擇。根據你所處的形勢，對服務網格的前期投資可能十分昂貴。

而且，如果說控制應用和服務間通訊對你的組織來說具有戰略性的重要意義的話，那麼使用一個現成的服務網格就沒有意義了。這樣或許可以受益於框架成長帶來的收益 ，但無法對你的目標實現控制。

2、服務網格具有複雜性

服務網格的部署將向你的架構引入相當可觀的複雜性。部署過程需要引入外掛代理，服務網格需要與現有的環境進行整合並在未來的時間裡反覆的配置，所有的加密可能需要重新設計。基於Kubernetes這樣的平臺建立服務網格的例項，會要求你不僅是服務網格的專家，並且是熟悉Kubernetes的專家。

3、服務網格可能執行緩慢

隨著網格的擴張和路由表的膨脹，通過一系列代理進行的路由通訊將慢的痛苦異常。

4、服務網格傾向於建立自治的架構藍圖

使用服務網格來追蹤服務間的通訊請求並不總是像最初那樣看起來有價值。比如，假設你的微服務環境與其他團隊的應用和服務相整合，在跨越不同的技術團隊和業務單元的邊界時，翻譯不同的追蹤記錄將十分挑戰，如果是企業級環境或者是雲端供應商的情況下，這種挑戰將更加嚴峻。

5、服務網格著眼於開發者層面的考量

服務網格著眼於典型的開發者視角的服務間通訊問題。對於規模化且不確定的應用和服務而言，元件之間的互動會天然衍生一系列的複雜性，對這些新興行為的管控，服務網格無能為力。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2639296/，如需轉載，請註明出處，否則將追究法律責任。

相關文章