9種主流的用以支撐微服務(wù)開發(fā)的服務(wù)網(wǎng)格框架及應(yīng)用場(chǎng)景

哪種服務(wù)網(wǎng)格最適合你的企業(yè)？近年來(lái)，Kubernetes服務(wù)網(wǎng)格框架數(shù)量增加迅速，使得這成為一個(gè)棘手的問(wèn)題。

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

什么是服務(wù)網(wǎng)格

服務(wù)網(wǎng)格近年來(lái)有很高的話題度，背后的原因是什么？

微服務(wù)已經(jīng)成為一種靈活快速的開發(fā)方式。然而，隨著微服務(wù)數(shù)量成倍數(shù)地增長(zhǎng)，開發(fā)團(tuán)隊(duì)開始遇到了部署和擴(kuò)展性上的問(wèn)題。

容器和Kubernetes這樣的容器編排系統(tǒng) ，將運(yùn)行時(shí)和服務(wù)一起打包進(jìn)鏡像，調(diào)度容器到合適的節(jié)點(diǎn)，運(yùn)行容器。這個(gè)方案可以解決開發(fā)團(tuán)隊(duì)遇到的不少問(wèn)題。然而，在這個(gè)操作流程中仍存在短板：如何管理服務(wù)間的通信。

在采用服務(wù)網(wǎng)格的場(chǎng)景下，以一種和應(yīng)用代碼解耦的方式，增強(qiáng)了應(yīng)用間統(tǒng)一的網(wǎng)絡(luò)通信能力。服務(wù)網(wǎng)格擴(kuò)展了集群的管理能力，增強(qiáng)可觀測(cè)性、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、IT運(yùn)維監(jiān)控及應(yīng)用故障恢復(fù)等功能。

服務(wù)網(wǎng)格概覽

服務(wù)網(wǎng)格一直有很高的熱度。正如Linkerd的作者William Morgan所提到的：“服務(wù)網(wǎng)格本質(zhì)上無(wú)非就是和應(yīng)用捆綁在一起的用戶空間代理?！?此說(shuō)法相當(dāng)簡(jiǎn)潔，他還補(bǔ)充道，“如果你能透過(guò)噪音看清本質(zhì)，服務(wù)網(wǎng)格能給你帶來(lái)實(shí)實(shí)在在的重要價(jià)值。”

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

若論具體服務(wù)網(wǎng)格方案的普及程度，Istio 和 Linkerd 獲得了更多的認(rèn)可。也有其它可選項(xiàng)，包括 Consul Connect，Kuma，AWS App Mesh和OpenShift。下文會(huì)闡述9種服務(wù)網(wǎng)格提供的關(guān)鍵特性。

Istio

Istio是基于Envoy構(gòu)建的一個(gè)可擴(kuò)展的開源服務(wù)網(wǎng)格。開發(fā)團(tuán)隊(duì)可以通過(guò)它連接、加密、管控和觀察應(yīng)用服務(wù)。Istio于2017年開源，目前 IBM 、Google、Lyft 仍在對(duì)其進(jìn)行持續(xù)維護(hù)升級(jí)。Lyft 在2017年把 Envoy 捐贈(zèng)給了CNCF。

Istio 花了不少時(shí)間去完善增強(qiáng)它的功能特性。Istio 的關(guān)鍵特性包括負(fù)載均衡、流量路由、策略創(chuàng)建、可度量性及服務(wù)間認(rèn)證。

Istio 有兩個(gè)部分組成：數(shù)據(jù)平面和控制平面。數(shù)據(jù)平面負(fù)責(zé)處理流量管理，通過(guò) Envoy 的 sidecar 代理來(lái)實(shí)現(xiàn)流量路由和服務(wù)間調(diào)用?？刂破矫媸侵饕?a target="_blank">開發(fā)者用來(lái)配置路由規(guī)則和觀測(cè)指標(biāo)。

Istio 觀測(cè)指標(biāo)是細(xì)粒度的屬性，其中包含和服務(wù)行為相關(guān)的特定數(shù)據(jù)值。下面是個(gè)樣例：

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

與其他服務(wù)網(wǎng)格相比，Istio 勝在其平臺(tái)成熟度以及通過(guò)其 Dashbaord

著重突出的服務(wù)行為觀測(cè)和業(yè)務(wù)管理功能，然而也因?yàn)檫@些高級(jí)特性和復(fù)雜的配置流程，Istio 可能并不如其它一些替代方案那樣容易上手。

Linkerd

按照官網(wǎng)的說(shuō)法，Linkerd 是一個(gè)輕量級(jí)、安全優(yōu)先的 Kubernetes 服務(wù)網(wǎng)格。它的創(chuàng)建流程快到讓人難以置信（據(jù)稱在 Kubernetes 安裝只需要 60 秒），這是大多數(shù)開發(fā)者喜聞樂(lè)見的。Linkerd 并沒(méi)有采用基于 Envoy 的構(gòu)建方案。而是使用了一個(gè)基于 Rust 的高性能代理 linkerd2-proxy，這個(gè)代理是專門為 Linkerd 服務(wù)網(wǎng)格編寫的。

Linkerd 由社區(qū)驅(qū)動(dòng)，是 100% 的 Apache 許可開源項(xiàng)目。它還是 CNCF 孵化項(xiàng)目。Linkerd 始于 2016 年，維護(hù)者也花了不少時(shí)間去解決其中的缺陷。

使用 Linkerd 服務(wù)網(wǎng)格，應(yīng)用服務(wù)可以增強(qiáng)其可靠性、可觀測(cè)性及其在 Kubernetes 上部署的安全性。舉個(gè)例子，可觀測(cè)性的增強(qiáng)可以幫助用戶解決服務(wù)間的延遲問(wèn)題。使用 Linkerd 不要求用戶做很多代碼調(diào)整或是花費(fèi)大量時(shí)間寫 YAML 配置文件?？煽康?a target="_blank">產(chǎn)品特性和正向的開發(fā)者使用回饋，使得 Linkerd 成為服務(wù)網(wǎng)格中一個(gè)強(qiáng)有力的競(jìng)爭(zhēng)者。

Consul Connect

Consul Connect 是來(lái)自 HashiCorp 的服務(wù)網(wǎng)格，專注于路由和分段，通過(guò)應(yīng)用級(jí)的 sidecar 代理來(lái)提供服務(wù)間的網(wǎng)絡(luò)特性。 Consult Connect 側(cè)重于應(yīng)用安全，提供應(yīng)用間的雙向 TLS 連接以實(shí)現(xiàn)授權(quán)和加密。

Consult Connect 獨(dú)特的一點(diǎn)是提供了兩種代理模式。一種是它內(nèi)建的代理，同時(shí)它還支持 Envoy 方案。Connect 強(qiáng)調(diào)可觀測(cè)性，集成了例如 Prometheus 這樣的工具來(lái)監(jiān)控來(lái)自 sidecar 代理的數(shù)據(jù)。Consul Connect 可以靈活地滿足開發(fā)者使用需求。比如，它提供了多種方式注冊(cè)服務(wù)：可以從編排系統(tǒng)注冊(cè)，可以通過(guò)配置文件，通過(guò) API 調(diào)用，或是命令行工具。

Kuma

Kuma 來(lái)源于 Kong，自稱是一個(gè)非常好用的服務(wù)網(wǎng)格替代方案。Kuma 是一個(gè)基于 Envoy 的平臺(tái)無(wú)關(guān)的控制平面。 Kuma 提供了安全、觀測(cè)、路由等網(wǎng)絡(luò)特性，同時(shí)增強(qiáng)了服務(wù)間的連通性。Kuma 同時(shí)支持 Kubernetes 和虛擬機(jī)。

Kuma 讓人感興趣的一點(diǎn)是，它的企業(yè)版可以通過(guò)一個(gè)統(tǒng)一控制面板來(lái)運(yùn)維管理多個(gè)互相隔離獨(dú)立的服務(wù)網(wǎng)格。這項(xiàng)能力可以滿足安全要求高的使用場(chǎng)景。既符合隔離的要求，又實(shí)現(xiàn)集中控制。

Kuma 也是相對(duì)容易安裝的一個(gè)方案。因?yàn)樗A(yù)先內(nèi)置了不少策略。這些策略覆蓋了常見需求，例如路由，雙向 TLS，故障注入，流量控制，加密等場(chǎng)景。

Kuma 原生兼容 Kong，對(duì)于那些已經(jīng)采用 Kong API 管理的企業(yè)組織，Kuma 是個(gè)非常自然而然的候選方案。

Maesh

Maesh 是來(lái)自 Containous 的容器原生的服務(wù)網(wǎng)格，標(biāo)榜自己是比市場(chǎng)其它服務(wù)網(wǎng)格更輕量級(jí)更易用的方案。和很多基于 Envoy 構(gòu)建的服務(wù)網(wǎng)格不同，Maesh 采用了 Traefik， 一個(gè)開源的反向代理和負(fù)載均衡器。

Maesh 并沒(méi)有采用 sidecar 的方式進(jìn)行代理，而是在每個(gè)節(jié)點(diǎn)部署一個(gè)代理終端。這樣做的好處是不需要去編輯 Kubernetes 對(duì)象，同時(shí)可以讓用戶有選擇性地修改流量，Maesh 相比其他服務(wù)網(wǎng)格侵入性更低。Maesh 支持的配置方式：在用戶服務(wù)對(duì)象上添加注解或是在服務(wù)網(wǎng)格對(duì)象上添加注解來(lái)實(shí)現(xiàn)配置。

實(shí)際上，SMI 是一種新的服務(wù)網(wǎng)格規(guī)范格式，對(duì) SMI 的支持 Maesh 獨(dú)有的一大亮點(diǎn)。隨著 SMI 在業(yè)界逐漸被采用，可以提高可擴(kuò)展性和減緩供應(yīng)商綁定的擔(dān)憂。

Maesh 要求 Kubernetes 1.11 以上的版本，同時(shí)集群里安裝了 CoreDNS/KubeDNS。這篇安裝指南演示了如何通過(guò) Helm v3 快速安裝 Maesh。

helm repo add maesh https://containous.github.io/maesh/charts helm repo update helm install maesh maesh/maesh

ServiceComb-mesher

Apache 軟件基金會(huì)形容旗下的 ServiceComb-mesher “是一款用 Go 語(yǔ)言實(shí)現(xiàn)的高性能服務(wù)網(wǎng)格”。Mesher 基于一個(gè)非常受歡迎的 Go 語(yǔ)言微服務(wù)開發(fā)框架 Go Chassis 來(lái)設(shè)計(jì)實(shí)現(xiàn)。因此，它沿襲了 Go Chassis 的一些特性如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、錯(cuò)誤容忍、路由管理和分布式追蹤等特性。

Mesher 采用了 sidecar 方式;每個(gè)服務(wù)有一個(gè) Mesher sidecar 代理。開發(fā)人員通過(guò) Admin API 和 Mesher 交互，查看運(yùn)行時(shí)信息。Mesher 同時(shí)支持 HTTP 和 gRPC，可快速移植到不同的基礎(chǔ)設(shè)施環(huán)境，包括 Docker、Kubernetes、虛擬機(jī)和裸金屬機(jī)環(huán)境。

Network Service Mesh（NSM）

Network Service Mesh（NSM）是一款專門為 telcos 和 ISPs 設(shè)計(jì)的服務(wù)網(wǎng)格。它提供了一層級(jí)用以增強(qiáng)服務(wù)在 Kubernetes 的低層級(jí)網(wǎng)絡(luò)能力。NSM 目前是 CNCF 的沙箱項(xiàng)目。

根據(jù) NSM 的文檔說(shuō)明，“經(jīng)常接觸 L2/L3 層的網(wǎng)絡(luò)運(yùn)維人員抱怨說(shuō)，適合他們的下一代架構(gòu)的容器網(wǎng)絡(luò)解決方案幾乎沒(méi)有”。

因此，NSM 在設(shè)計(jì)時(shí)就考慮到一些不同使用場(chǎng)景，尤其是網(wǎng)絡(luò)協(xié)議不同和網(wǎng)絡(luò)配置混雜的場(chǎng)景。這使得 NSM 對(duì)某些特殊場(chǎng)景具備相當(dāng)吸引力，例如邊緣計(jì)算、5G 網(wǎng)絡(luò)和 IOT 設(shè)備等場(chǎng)景。NSM 使用簡(jiǎn)單直接的 API 接口去實(shí)現(xiàn)容器和外部端點(diǎn)的之間的通信。

和其他服務(wù)網(wǎng)格相比，NSM 工作在另一個(gè)不同的網(wǎng)絡(luò)層。 VMware 形容 NSM“專注于連接”。GitHub 的文檔演示了 NSM 是如何與 Envoy協(xié)同工作的。

AWS App Mesh

AWS APP Mesh 為開發(fā)者提供了“適用于不同服務(wù)的應(yīng)用層的網(wǎng)絡(luò)”。它接管了服務(wù)的所有網(wǎng)絡(luò)流量，使用開源的 Envoy 代理去控制容器的流量出入。AWS App Mesh 支持 HTTP/2 gRPC 。

AWS App Mesh 對(duì)于那些已經(jīng)將容器平臺(tái)深度綁定 AWS 的公司而言，會(huì)是相當(dāng)不錯(cuò)的服務(wù)網(wǎng)格方案。AWS 平臺(tái)包括 AWS Fargate，Amazon Elastic Container Service，Amazon Elastic Kubernetes Service（EKS），Amazon Elastic Compute Cloud（EC2），Kubernetes on EC2，包括 AWS App Mesh 不需要付額外費(fèi)用。

AWS App Mesh 和 AWS 生態(tài)內(nèi)的監(jiān)控工具無(wú)縫兼容。這些工具包括 CloudWatch 和 AWS X-Ray，以及一些來(lái)自第三方供應(yīng)商的工具。因?yàn)?AWS 計(jì)算服務(wù)支持 AWS Outposts，AWS App Mesh 可以和混合云和已經(jīng)部署的應(yīng)用良好兼容。

AWS App Mesh 的缺點(diǎn)可能是使得開發(fā)者深度綁定了單一供應(yīng)商方案，相對(duì)閉源，可擴(kuò)展性缺失。

OpenShift Service Mesh by Red Hat

OpenShift 是來(lái)自紅帽的一款幫助用戶“連接、管理、觀測(cè)微服務(wù)應(yīng)用”的容器管理平臺(tái)。OpenShift 預(yù)裝了不少提升企業(yè)能力的組件，也被形容為企業(yè)級(jí)的混合云 Kubernetes 平臺(tái)。

OpenShift Service Mesh 基于開源的 Istio 構(gòu)建，具備 Isito 的控制平面和數(shù)據(jù)平面等特性。OpenShift 利用兩款開源工具來(lái)增強(qiáng) Isito 的追蹤能力和可觀測(cè)性。OpenShift 使用 Jaeger 實(shí)現(xiàn)分布式追蹤，更好地跟蹤請(qǐng)求是如何在服務(wù)間調(diào)用處理的。

另一方面，OpenShift 使用了 Kiali 來(lái)增強(qiáng)微服務(wù)配置、流量監(jiān)控、跟蹤分析等方面的可觀測(cè)性。

如何選擇

正如文中所提到的，可供選擇的服務(wù)網(wǎng)格方案有很多，同時(shí)還有新的方案在涌現(xiàn)。當(dāng)然，每一種方案在技術(shù)實(shí)現(xiàn)上都略有不同。選擇一款合適的服務(wù)網(wǎng)格，主要考慮的因素包括，你能接受它帶來(lái)多大的侵入性，它的安全性如何，以及平臺(tái)成熟度等。

以下幾點(diǎn)可以幫助 DevOps 團(tuán)隊(duì)選擇一款適合他們場(chǎng)景的服務(wù)網(wǎng)格：

是否依賴Envoy。Envoy 有一個(gè)活躍的社區(qū)生態(tài)。開源，同時(shí)是許多服務(wù)網(wǎng)格的底座。Envoy 具備的豐富特性使得其成為一個(gè)很難繞過(guò)的因素。

具體使用場(chǎng)景。服務(wù)網(wǎng)格為微服務(wù)而生。如果你的應(yīng)用是一個(gè)單體的龐然大物，那你在服務(wù)網(wǎng)格上的投入可能達(dá)不到預(yù)期的收益。如果不是所有應(yīng)用都部署在 Kubernetes，則應(yīng)該優(yōu)先考慮平臺(tái)無(wú)關(guān)的方案。

現(xiàn)有容器管理平臺(tái)。有些企業(yè)已經(jīng)使用了特定供應(yīng)商的生態(tài)來(lái)解決容器編排問(wèn)題，例如 AWS 的 EKS，紅帽的 OpenShift，Consul。沿襲原有的生態(tài)，可以繼承并拓展原有的特性。而這些可能是開源方案所不能提供的。

所在行業(yè)。許多服務(wù)網(wǎng)格不是為特定行業(yè)專門設(shè)計(jì)的。Kuma 統(tǒng)一管理多個(gè)隔離服務(wù)網(wǎng)格的能力可能更適用于收到高度管制的金融行業(yè)。底層網(wǎng)絡(luò) telcos 和 ISPs 則更應(yīng)該考慮 Network Service Mesh。

對(duì)可視化的要求?？捎^測(cè)性是服務(wù)網(wǎng)格的核心能力之一。考慮進(jìn)一步定制和更深度能力的團(tuán)隊(duì)?wèi)?yīng)該優(yōu)先考慮 Istio 或 Consul。

是否遵循開發(fā)標(biāo)準(zhǔn)。遵循開發(fā)標(biāo)準(zhǔn)使得你的平臺(tái)更具備前瞻性和可擴(kuò)展性。這使得企業(yè)會(huì)傾向于采用支持 SMI 的方案，Maesh 或其他基金會(huì)孵化的項(xiàng)目如 Linkerd。

是否重視用戶體驗(yàn)?？紤]運(yùn)維人員的易用性是評(píng)判新工具的關(guān)鍵指標(biāo)。這方 Linkerd 似乎在開發(fā)者中間口碑不錯(cuò)。

團(tuán)隊(duì)準(zhǔn)備。評(píng)估你的團(tuán)隊(duì)所具備的資源和技術(shù)儲(chǔ)備，在技術(shù)選型時(shí)決定你們適合用基于 Envoy 的 Istio，或是供應(yīng)商抽象封裝的方案，例如 OpenShift。

這些考慮因素沒(méi)有覆蓋到全部場(chǎng)景。此處僅是拋磚引玉，引起讀者的思考。希望讀完上面所列的服務(wù)網(wǎng)格清單，和相關(guān)的決策因素之后，你們的團(tuán)隊(duì)能找到新的方法去改善微服務(wù)應(yīng)用的網(wǎng)絡(luò)特性。
責(zé)編AJX