9 大開源 Service Mesh 平臺橫向對比
鏈接：http://soft.zhiding.cn/software_zone/2021/0222/3132265.shtml
本文將與大家深入探討九大流行開源 Service Mesh，瞭解它們如何支持微服務開發工作，並針對不同選項提出用例建議。
Service mesh 正是爲此而生——它以獨立於應用程序代碼之外的方式，爲整體堆棧帶來統一的網絡功能。Service Mesh 擴展了 Kubernetes 等集羣管理器的功能範疇，提供豐富的可觀察指標、服務發現、負載均衡、IT 運營監控以及微服務 / 容器故障恢復等功能選項。
Service mesh 現狀
如今，關於 Service Mesh 存在着諸多炒作甚至誤解。Linkerd 締造者 William Morgan 強調，“Service Mesh 其實就是一大堆與服務本體緊密相鄰的用戶空間代理。” 雖然實質非常簡單，但 “在排除掉種種噪聲與誤解之後，Service Mesh 確實帶來了切實、具體且重要的價值。”
如今，Envoy 已經成爲大部分 Service Mesh 的核心。Envoy 是一種通用開源代理，以輔助方式實現流量攔截。當然，也有一些 Service Mesh 會使用其他代理選項。
在 Service Mesh 的實際應用方面，Istio 與 Linkerd 已經佔據主流。除此之外，Consul Connect、Kuma、AWS App Mesh 以及 OpenShift 等也都擁有自己的受衆。下面來看九大 service mesh 產品的功能特性。
Istio
Istio 是一種基於 Envoy 的可擴展開源 Service Mesh，允許團隊連接、保護、控制並觀察各項服務。作爲 IBM 與谷歌的持續合作產物，Istio 於 2017 年正式開源，連同 Lyft 一道被捐贈給雲原生計算基金會。
在此之後，Istio 不斷完善並改進自身功能集。目前 Istio 的核心功能包括負載均衡、流量路由、策略創建、指標跟蹤以及服務到服務身份驗證等。
Istio 分爲兩個組成部分：數據平面與控制平面。Istio 的數據平面使用 Envoy 邊車代理在各服務之間實現流量與調用路由，藉此實現流量管理。Istio 的控制平面則可供開發人員用於配置路由並查看各項指標。
Istio 提供的各項指標均提供細粒度屬性，其中包含與服務行爲相關的特定數據值，參見以下屬性示例：
與其他 Service Mesh 相比，Istio 的平臺成熟度更高，主要偏重行爲洞見與操作控制，同時提供監控儀表板。但由於包含大量先進功能與密集的配置流程，Istio 在易用性及開發者友好度方面往往不及其他更爲簡單的 Service Mesh。
Linkerd
根據官方網站的說明，Linkerd 是一套 “面向 Kubernetes 的超輕量級、安全優先型 Service Mesh。” 它是開發者們的最愛，設置過程非常簡單，據稱只需要 60 秒左右即可安裝至 Kubernetes 集羣。不同於採用 Envoy 的 Istio，Linkerd 採用名爲 linkerd2-proxy 的調整精簡 Rust 代理，從名稱就能看出其爲 Linkerd 量身打造之意。
Linkerd 屬於社區驅動型項目，採用 100% Apche 許可開源代碼，同時也是雲原生計算基金會（CNCF）旗下的孵化項目。誕生於 2016 年的 Linkerd 一直不斷髮展，諸多原有問題已經在維護人員手中得到解決。
使用 Linkerd Service Mesh，應用程序能夠爲其 Kubernetes 部署帶來更強大的可靠性、可觀察性與安全性。例如，更好的可觀察性使工程師們能夠高效解決不同服務之間的通信延遲問題。Linkerd 無需對代碼做出過多更改，也不需要耗費時間編寫 YAML 配置文件。優秀的功能與積極的開發者社區響應態度，讓 Linkerd 在受衆當中積累起良好的口碑。
Consul Connect
HashiCorp 開發的 Consul Connect Service Mesh 專注於路由與分段功能，可通過應用層級的邊車代理提供服務到服務網絡功能。Consult Connect 特別強調應用程序安全性，其代理能夠爲應用程序提供雙向傳輸層安全（TLS）連接以實現授權與加密。
Consul Connect 的獨特之處，在於提供兩種代理選項。首先是 Connect 的內置層代理，主要用於測試場景；此外，Connect 還支持 Envoy。在可觀察性方面，Connect 提供良好的工具集成能力，可監控 Prometheus 等邊車代理的相關數據。Consul Connect 也能夠靈活滿足開發人員的實際需求，提供的註冊服務選項包括：通過編排器註冊、使用配置文件註冊、通過 API 註冊或通過命令行界面（CLI）註冊。
Kuma
由 Kong 打造的 Kuma 同樣是一套強大的 Service Mesh 解決方案。Kuma 屬於基於 Envoy 構建的平臺中立型控制平面。Kuma 提供多種網絡功能，用以保護、觀察、路由並增強服務之間的連接性。除虛擬機之外，Kuma 還支持 Kubernetes。
Kuma 的一大特性，在於允許企業用戶通過統一的控制平面操作並控制多個隔離網格。對於需要分段並進行集中控制的高安全性用例，這項功能無疑至關重要。
Kuma 也相對易於使用，其中預裝有捆綁策略，全面涵蓋多種通行需求，例如路由、雙向 TLS、故障注入、流量控制、安全保護等等。Kuma 原生與 Kong 相兼容，因此成爲已經使用 Kong API 的組織的首選 Service Mesh 方案。
Maesh
Maesh 是 Containous 打造的原生容器 Service Mesh，以輕量化設計著稱，而且比市面上的其他 Service Mesh 更易於使用。不同於以 Envoy 爲基礎的主流選擇，Maesh 採用了開源反向代理與負載均衡方案 Traefik。
Maesh 並沒有採用邊車容器格式，而是爲每個節點提供代理端點。這種方式使 Maesh 的侵入性較其他 Service Mesh 更低——除非明確指定，否則其不會編輯任何 Kubernetes 對象或者修改流量內容。Maesh 支持兩種配置選項：用戶服務對象以及 Service Mesh Interface (SMI) 對象。
事實上，對 SMI（一種新型標準服務網格規範格式）的支持已經成爲 Maesh 的獨特特徵。如果後續 SMI 在行業中的採用率有所提高，Maesh 將進一步增強自身可擴展性優勢，並有望藉此緩解供應商鎖定問題。
根據 Apache 軟件基金會的介紹，ServiceComb-mesher 是一套 “以 Go 語言編寫的高性能 Service Mesh 實現方案。”Mesher 基於 Go Chassis（一種流行的 Go 語言微服務開發框架），因此繼承了 Go Chassis 提供的服務發現、負載均衡、高容錯、路由管理以及分佈式跟蹤等功能。
Mesher 採用邊車設計方法；每項服務都對應專門的 Mesher Sidecar 代理。開發者能夠與 Mesher 進行交互，並通過 Admin API 查看運行時信息。Mesher 支持 HTTP 與 gRPC，能夠移植到多種不同的基礎設施類型，包括 Docker、Kubernetes、虛擬機以及裸機環境。
Network Service Mesh (NSM)
Network Service Mesh (NSM) 屬於專爲電信公司及互聯網服務供應商（ISP）構建的 Service Mesh，可提供向 Kubernetes 添加底層網絡功能的層。NSM 目前爲雲原生計算基金會的沙箱孵化項目。
根據 NSM 說明文檔的介紹，“目前，需要運營高級 L2/L3 用例的多層網絡運營商，往往很難找到適合其下一代架構的容器網絡解決方案。”
爲此，NSM 在構建過程中會充分考慮到不同的假設性條件，包括強調 “跨域” 協議與異構網絡配置。憑藉這種能力，NSM 成爲邊緣計算、5G 網絡以及物聯網設備等特定用例中的首選方案。NSM 使用簡單的 API 套件實現容器與外部端點之間的通信。
NSM 與本份榜單中的其他 service mesh 動作在不同的層上。VMware 將 NSM 描述爲 “連接中心”；從 GitHub 軟件包來看，NSM 以 Envoy 爲代理基礎。
AWS App Mesh
Amazon Web Services 推出的 App Mesh 能夠爲所有服務提供 “應用級網絡” 支持。App Mesh 能夠管理服務間的所有網絡流量，並使用開源 Envoy 代理控制流入與流出服務容器的流量。AWS App Mesh 支持 HTTP/2 gRPC 服務。
對於已經在容器平臺內使用 AWS 基礎設施的用戶來說，AWS App Mesh 應該是個理想的 Service Mesh 選項。目前，包括 AWS Fargate、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service (EKS)、Amazon Elastic Compute Cloud (EC2) 以及 Kubernetes on EC2 在內的各類 AWS 平臺都提供 AWS App Mesh，且無需額外付費。
AWS App Mesh 還與 AWS 生態系統內的各類監控工具相兼容，包括 Amazon 工具（例如 CloudWatch 與 AWS X-Ray）以及多種第三方服務商的工具。由於 AWS 計算服務支持 AWS Outposts，因此 AWS App Mesh 可以與混合雲及本地部署協同運行。
AWS App Mesh 的缺點主要體現在開源或可擴展工具選項較少，可能導致用戶遭遇嚴重的供應商鎖定。
Red Hat 的 OpenShift Service Mesh
OpenShift 是 Red Hat 打造的容器管理平臺，可幫助 “連接、管理並觀察基於微服務架構的應用程序。” 作爲一套企業級混合雲 Kubernetes 平臺，OpenShift 已經預裝有多項功能，也已經在企業受衆中得到廣泛採用。
選擇 service mesh 時的注意事項
本份榜單列出了多種 Service Mesh 選項，而且各個項目的發展態勢也在不斷變化。當然，每種 Service Mesh 的實現方式互不相同，也在具體功能上有所體現。在實際選擇中，大家需要考慮到 Service Mesh 的侵入度、默認安全水平、平臺成熟度以及其他問題。
DevOps 團隊也應參考以下因素，判斷哪種 service mesh 最適合當前需求：
• 能否脫離 Envoy？Envoy 擁有充滿活力的社區生態系統，屬於開源項目而且作爲多種 Service Mesh 的實現基礎。其豐富的功能幾乎找不到真正全面的替代方案。
• 用例提出哪些現實需求？Service mesh 面向微服務架構。如果需要構建單體式應用，大家顯然無需使用 Service Mesh。另外，如果您的某些應用程序並不使用 Kubernetes，最好選擇具有良好平臺中立性的方案。
• 您的現有容器管理工具中存在哪些依賴關係？已經在容器編排體系中引入某些供應商生態要素（例如 AWS EKS、Red Hat OpenShift 以及 Consul）的用戶不妨直接選擇原生工具，藉此將功能擴展至開源軟件包之外。
• 您身處哪個行業？大多數 Service Mesh 並非針對特定行業進行設計與構建。但是，Kuma 擁有強大的網格分區能力，因此特別適合需要遵循嚴格監管的金融平臺。而底層網絡電信企業與互聯網服務供應商則更適合選擇 Network Service Mesh。
• 您需要怎樣的可觀察性？可觀察性是 Service Mesh 中的一項核心指標。需要這類深層定製化功能的用戶，可以優先考慮 Istio 與 Consul。
• 您是否關心開放標準？使用開放標準，可以保證您的技術隨時跟進時代發展，並通過其他工具完成持續擴展。如果您有這類訴求，不妨選擇支持 SMI 的工具（例如 Maesh）或者由基金會支持的項目（例如 Linkerd）。
• 您是否關心開發者體驗？在選擇新工具時，很多企業都會關注運維工程師的實際體驗。Linkerd 在開發者羣體中享有良好聲譽，可能符合您的需求。
• 您的團隊是否爲 Service Mesh 做好了準備？評估組織內是否具有資源及技能，用以實施 Service Mesh 技術。這個問題的答案將直接決定您選擇基於 Envoy 的 Istio，或者使用 OpenShift 等經由供應商層進行抽象化的解決方案。
當然，以上事項並不完全，只是爲大家提供一點討論思路。希望您在審視以上列出的各項要點之後能夠得到一點啓發，探索出微服務網絡開發的更多實現途徑。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/B-Vv08ePWXnna9xsBgx7Eg