哪一種服務網格最適合你的企業?近年來,Kubernetes服務網格框架數量增長迅速,使得這成爲一個棘手的問題。git
下面將介紹9種較受歡迎的用以支撐微服務開發的服務網格框架,每種方案都給出了其適用場景。github
什麼是服務網格
服務網格近年來有很高的話題度,背後的緣由是什麼?安全
微服務已經成爲一種靈活快速的開發方式。然而,隨着微服務數量成倍數地增加,開發團隊開始遇到了部署和擴展性上的問題。網絡
容器和Kubernetes這樣的容器編排系統 ,將運行時和服務一塊兒打包進鏡像,調度容器到合適的節點,運行容器。這個方案能夠解決開發團隊遇到的很多問題。然而,在這個操做流程中仍存在短板:如何管理服務間的通訊。架構
在採用服務網格的場景下,以一種和應用代碼解耦的方式,加強了應用間統一的網絡通訊能力。服務網格擴展了集羣的管理能力,加強可觀測性、服務發現、負載均衡、IT運維監控及應用故障恢復等功能。負載均衡
服務網格概覽
服務網格一直有很高的熱度。正如Linkerd的做者William Morgan所提到的:「服務網格本質上無非就是和應用捆綁在一塊兒的用戶空間代理。」 此說法至關簡潔,他還補充道,「若是你能透過噪音看清本質,服務網格能給你帶來實實在在的重要價值。」框架
Envoy是許多服務網格框架的核心組件,是一個通用的開源代理,常被用於Pod內的sidecar以攔截流量。也有服務網格使用另外的代理方案。運維
若論具體服務網格方案的普及程度,Istio 和 Linkerd 得到了更多的承認。也有其它可選項,包括 Consul Connect,Kuma,AWS App Mesh和OpenShift。下文會闡述9種服務網格提供的關鍵特性。分佈式
Istioide
Istio是基於Envoy構建的一個可擴展的開源服務網格。開發團隊能夠經過它鏈接、加密、管控和觀察應用服務。Istio於2017年開源,目前 IBM 、Google、Lyft 仍在對其進行持續維護升級。Lyft 在2017年把 Envoy 捐贈給了CNCF。
Istio 花了很多時間去完善加強它的功能特性。Istio 的關鍵特性包括負載均衡、流量路由、策略建立、可度量性及服務間認證。
Istio 有兩個部分組成:數據平面和控制平面。數據平面負責處理流量管理,經過 Envoy 的 sidecar 代理來實現流量路由和服務間調用。控制平面是主要由開發者用來配置路由規則和觀測指標。
Istio 觀測指標是細粒度的屬性,其中包含和服務行爲相關的特定數據值。下面是個樣例:
request.path: xyz/abc request.size: 234 request.time: 12:34:56.789 04/17/2017 source.ip: [192 168 0 1] destination.service.name: example
與其餘服務網格相比,Istio 勝在其平臺成熟度以及經過其 Dashbaord
着重突出的服務行爲觀測和業務管理功能,然而也由於這些高級特性和複雜的配置流程,Istio 可能並不如其它一些替代方案那樣容易上手。
Linkerd
按照官網的說法,Linkerd 是一個輕量級、安全優先的 Kubernetes 服務網格。它的建立流程快到讓人難以置信(據稱在 Kubernetes 安裝只須要 60 秒),這是大多數開發者喜聞樂見的。Linkerd 並無採用基於 Envoy 的構建方案。而是使用了一個基於 Rust 的高性能代理 linkerd2-proxy,這個代理是專門爲 Linkerd 服務網格編寫的。
Linkerd 由社區驅動,是 100% 的 Apache 許可開源項目。它仍是 CNCF 孵化項目。Linkerd 始於 2016 年,維護者也花了很多時間去解決其中的缺陷。
使用 Linkerd 服務網格,應用服務能夠加強其可靠性、可觀測性及其在 Kubernetes 上部署的安全性。舉個例子,可觀測性的加強能夠幫助用戶解決服務間的延遲問題。使用 Linkerd 不要求用戶作不少代碼調整或是花費大量時間寫 YAML 配置文件。可靠的產品特性和正向的開發者使用回饋,使得 Linkerd 成爲服務網格中一個強有力的競爭者。
Consul Connect
Consul Connect 是來自 HashiCorp 的服務網格,專一於路由和分段,經過應用級的 sidecar 代理來提供服務間的網絡特性。 Consult Connect 側重於應用安全,提供應用間的雙向 TLS 鏈接以實現受權和加密。
Consult Connect 獨特的一點是提供了兩種代理模式。一種是它內建的代理,同時它還支持 Envoy 方案。Connect 強調可觀測性,集成了例如 Prometheus 這樣的工具來監控來自 sidecar 代理的數據。Consul Connect 能夠靈活地知足開發者使用需求。好比,它提供了多種方式註冊服務:能夠從編排系統註冊,能夠經過配置文件,經過 API 調用,或是命令行工具。
Kuma
Kuma 來源於 Kong,自稱是一個很是好用的服務網格替代方案。Kuma 是一個基於 Envoy 的平臺無關的控制平面。 Kuma 提供了安全、觀測、路由等網絡特性,同時加強了服務間的連通性。Kuma 同時支持 Kubernetes 和虛擬機。
Kuma 讓人感興趣的一點是,它的企業版能夠經過一個統一控制面板來運維管理多個互相隔離獨立的服務網格。這項能力能夠知足安全要求高的使用場景。既符合隔離的要求,又實現集中控制。
Kuma 也是相對容易安裝的一個方案。由於它預先內置了很多策略。這些策略覆蓋了常見需求,例如路由,雙向 TLS,故障注入,流量控制,加密等場景。
Kuma 原生兼容 Kong,對於那些已經採用 Kong API 管理的企業組織,Kuma 是個很是天然而然的候選方案。
Maesh
Maesh 是來自 Containous 的容器原生的服務網格,標榜本身是比市場其它服務網格更輕量級更易用的方案。和不少基於 Envoy 構建的服務網格不一樣,Maesh 採用了 Traefik, 一個開源的反向代理和負載均衡器。
Maesh 並無採用 sidecar 的方式進行代理,而是在每一個節點部署一個代理終端。這樣作的好處是不須要去編輯 Kubernetes 對象,同時可讓用戶有選擇性地修改流量,Maesh 相比其餘服務網格侵入性更低。Maesh 支持的配置方式:在用戶服務對象上添加註解或是在服務網格對象上添加註解來實現配置。
實際上,SMI 是一種新的服務網格規範格式,對 SMI 的支持 Maesh 獨有的一大亮點。隨着 SMI 在業界逐漸被採用,能夠提升可擴展性和減緩供應商綁定的擔心。
Maesh 要求 Kubernetes 1.11 以上的版本,同時集羣裏安裝了 CoreDNS/KubeDNS。這篇安裝指南演示瞭如何經過 Helm v3 快速安裝 Maesh。
helm repo add maesh https://containous.github.io/maesh/charts helm repo update helm install maesh maesh/maesh
ServiceComb-mesher
Apache 軟件基金會形容旗下的 ServiceComb-mesher 「是一款用 Go 語言實現的高性能服務網格」。Mesher 基於一個很是受歡迎的 Go 語言微服務開發框架 Go Chassis 來設計實現。所以,它沿襲了 Go Chassis 的一些特性如服務發現、負載均衡、錯誤容忍、路由管理和分佈式追蹤等特性。
Mesher 採用了 sidecar 方式;每一個服務有一個 Mesher sidecar 代理。開發人員經過 Admin API 和 Mesher 交互,查看運行時信息。Mesher 同時支持 HTTP 和 gRPC,可快速移植到不一樣的基礎設施環境,包括 Docker、Kubernetes、虛擬機和裸金屬機環境。
Network Service Mesh(NSM)
Network Service Mesh(NSM)是一款專門爲 telcos 和 ISPs 設計的服務網格。它提供了一層級用以加強服務在 Kubernetes 的低層級網絡能力。NSM 目前是 CNCF 的沙箱項目。
根據 NSM 的文檔說明,「常常接觸 L2/L3 層的網絡運維人員抱怨說,適合他們的下一代架構的容器網絡解決方案几乎沒有」。
所以,NSM 在設計時就考慮到一些不一樣使用場景,尤爲是網絡協議不一樣和網絡配置混雜的場景。這使得 NSM 對某些特殊場景具有至關吸引力,例如邊緣計算、5G 網絡和 IOT 設備等場景。NSM 使用簡單直接的 API 接口去實現容器和外部端點的之間的通訊。
和其餘服務網格相比,NSM 工做在另外一個不一樣的網絡層。 VMware 形容 NSM「專一於鏈接」。GitHub 的文檔演示了 NSM 是如何與 Envoy協同工做的。
AWS App Mesh
AWS APP Mesh 爲開發者提供了「適用於不一樣服務的應用層的網絡」。它接管了服務的全部網絡流量,使用開源的 Envoy 代理去控制容器的流量出入。AWS App Mesh 支持 HTTP/2 gRPC 。
AWS App Mesh 對於那些已經將容器平臺深度綁定 AWS 的公司而言,會是至關不錯的服務網格方案。AWS 平臺包括 AWS Fargate,Amazon Elastic Container Service,Amazon Elastic Kubernetes Service(EKS),Amazon Elastic Compute Cloud(EC2),Kubernetes on EC2,包括 AWS App Mesh 不須要付額外費用。
AWS App Mesh 和 AWS 生態內的監控工具無縫兼容。這些工具包括 CloudWatch 和 AWS X-Ray,以及一些來自第三方供應商的工具。由於 AWS 計算服務支持 AWS Outposts,AWS App Mesh 能夠和混合雲和已經部署的應用良好兼容。
AWS App Mesh 的缺點多是使得開發者深度綁定了單一供應商方案,相對閉源,可擴展性缺失。
OpenShift Service Mesh by Red Hat
OpenShift 是來自紅帽的一款幫助用戶「鏈接、管理、觀測微服務應用」的容器管理平臺。OpenShift 預裝了很多提高企業能力的組件,也被形容爲企業級的混合雲 Kubernetes 平臺。
OpenShift Service Mesh 基於開源的 Istio 構建,具有 Isito 的控制平面和數據平面等特性。OpenShift 利用兩款開源工具來加強 Isito 的追蹤能力和可觀測性。OpenShift 使用 Jaeger 實現分佈式追蹤,更好地跟蹤請求是如何在服務間調用處理的。
另外一方面,OpenShift 使用了 Kiali 來加強微服務配置、流量監控、跟蹤分析等方面的可觀測性。
如何選擇
正如文中所提到的,可供選擇的服務網格方案有不少,同時還有新的方案在涌現。固然,每一種方案在技術實現上都略有不一樣。選擇一款合適的服務網格,主要考慮的因素包括,你能接受它帶來多大的侵入性,它的安全性如何,以及平臺成熟度等。
如下幾點能夠幫助 DevOps 團隊選擇一款適合他們場景的服務網格:
-
是否依賴Envoy。Envoy 有一個活躍的社區生態。開源,同時是許多服務網格的底座。Envoy 具有的豐富特性使得其成爲一個很難繞過的因素。
-
具體使用場景。服務網格爲微服務而生。若是你的應用是一個單體的龐然大物,那你在服務網格上的投入可能達不到預期的收益。若是不是全部應用都部署在 Kubernetes,則應該優先考慮平臺無關的方案。
-
現有容器管理平臺。有些企業已經使用了特定供應商的生態來解決容器編排問題,例如 AWS 的 EKS,紅帽的 OpenShift,Consul。沿襲原有的生態,能夠繼承並拓展原有的特性。而這些多是開源方案所不能提供的。
-
所在行業。許多服務網格不是爲特定行業專門設計的。Kuma 統一管理多個隔離服務網格的能力可能更適用於收到高度管制的金融行業。底層網絡 telcos 和 ISPs 則更應該考慮 Network Service Mesh。
-
對可視化的要求。可觀測性是服務網格的核心能力之一。考慮進一步定製和更深度能力的團隊應該優先考慮 Istio 或 Consul。
-
是否遵循開發標準。遵循開發標準使得你的平臺更具有前瞻性和可擴展性。這使得企業會傾向於採用支持 SMI 的方案,Maesh 或其餘基金會孵化的項目如 Linkerd。
-
是否重視用戶體驗。考慮運維人員的易用性是評判新工具的關鍵指標。這方 Linkerd 彷佛在開發者中間口碑不錯。
-
團隊準備。評估你的團隊所具有的資源和技術儲備,在技術選型時決定大家適合用基於 Envoy 的 Istio,或是供應商抽象封裝的方案,例如 OpenShift。
這些考慮因素沒有覆蓋到所有場景。此處僅是拋磚引玉,引發讀者的思考。但願讀完上面所列的服務網格清單,和相關的決策因素以後,大家的團隊能找到新的方法去改善微服務應用的網絡特性。