哪種服務網格最適合你的企業？近年來，Kubernetes服務網格框架數量增加迅速，使得這成為一個棘手的問題。

下面將介紹9種較受歡迎的用以支撐微服務開發的服務網格框架，每種方案都給出了其適用場景。

什么是服務網格

服務網格近年來有很高的話題度，背后的原因是什么？

微服務已經成為一種靈活快速的開發方式。然而，隨著微服務數量成倍數地增長，開發團隊開始遇到了部署和擴展性上的問題。

容器和Kubernetes這樣的容器編排系統 ，將運行時和服務一起打包進鏡像，調度容器到合適的節點，運行容器。這個方案可以解決開發團隊遇到的不少問題。然而，在這個操作流程中仍存在短板：如何管理服務間的通信。

在采用服務網格的場景下，以一種和應用代碼解耦的方式，增強了應用間統一的網絡通信能力。服務網格擴展了集群的管理能力，增強可觀測性、服務發現、負載均衡、IT運維監控及應用故障恢復等功能。

服務網格概覽

服務網格一直有很高的熱度。正如Linkerd的作者William Morgan所提到的：“服務網格本質上無非就是和應用捆綁在一起的用戶空間代理。” 此說法相當簡潔，他還補充道，“如果你能透過噪音看清本質，服務網格能給你帶來實實在在的重要價值。”

Envoy是許多服務網格框架的核心組件，是一個通用的開源代理，常被用于Pod內的sidecar以攔截流量。也有服務網格使用另外的代理方案。

若論具體服務網格方案的普及程度，Istio 和 Linkerd 獲得了更多的認可。也有其它可選項，包括 Consul Connect，Kuma，AWS App Mesh和OpenShift。下文會闡述9種服務網格提供的關鍵特性。

Istio

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。

這些考慮因素沒有覆蓋到全部場景。此處僅是拋磚引玉，引起讀者的思考。希望讀完上面所列的服務網格清單，和相關的決策因素之后，你們的團隊能找到新的方法去改善微服務應用的網絡特性。
責編AJX