在討論微服務(wù)架構(gòu)和容器化時(shí)，一組經(jīng)過(guò)生產(chǎn)驗(yàn)證的工具近年來(lái)引起了很大關(guān)注：服務(wù)網(wǎng)格。

確實(shí)，微服務(wù)架構(gòu)和Kubernetes（通常是K8S）已迅速成為可伸縮應(yīng)用程序的規(guī)范，這使得管理服務(wù)之間的通信問(wèn)題成為熱門話題，并且服務(wù)網(wǎng)格成為一種有吸引力的解決方案。我本人在生產(chǎn)中使用了服務(wù)網(wǎng)格，特別是Linkerd，Istio和早期的Ambassador形式。但是，服務(wù)網(wǎng)格的作用到底是什么？最好使用哪一個(gè)？您怎么知道是否應(yīng)該使用那一個(gè)？

要回答這些問(wèn)題，有助于理解為什么開(kāi)發(fā)服務(wù)網(wǎng)格。從歷史上看，傳統(tǒng)的IT基礎(chǔ)架構(gòu)具有作為整體運(yùn)行的應(yīng)用程序。一種服務(wù)在一臺(tái)服務(wù)器上運(yùn)行；如果需要更多容量，解決方案是通過(guò)配置更大的機(jī)器來(lái)垂直擴(kuò)展它。

由于達(dá)到了這種方法的局限性，大型科技公司迅速采用了三層架構(gòu)，將負(fù)載均衡器與應(yīng)用程序服務(wù)器和數(shù)據(jù)庫(kù)層分開(kāi)。盡管該體系結(jié)構(gòu)仍具有一定的可伸縮性，但他們決定將應(yīng)用程序?qū)臃纸鉃槲⒎?wù)。為了擴(kuò)展應(yīng)用程序，這些服務(wù)之間的通信對(duì)于監(jiān)控和保護(hù)變得至關(guān)重要。

為了允許服務(wù)間通信，這些公司開(kāi)發(fā)了內(nèi)部庫(kù)：Twitter上的Finagle，Netflix上的Hystrix和Google上的Stubby（于2016年成為gRPC）。這些庫(kù)旨在解決微服務(wù)架構(gòu)引起的問(wèn)題：服務(wù)之間的安全性，延遲，監(jiān)控和負(fù)載均衡。但是，將大型庫(kù)作為多種語(yǔ)言作為依賴項(xiàng)進(jìn)行管理是復(fù)雜且耗時(shí)的。

最后，該類型的庫(kù)被更易于使用的輕量級(jí)代理所替代。此類代理在外部獨(dú)立于應(yīng)用程序?qū)?#xff08;對(duì)于應(yīng)用程序可能是透明的），并且更易于更新、維護(hù)和部署。這樣，服務(wù)網(wǎng)格就誕生了。

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

服務(wù)網(wǎng)格是用于控制服務(wù)之間的通信的軟件基礎(chǔ)結(jié)構(gòu)層。它通常由兩個(gè)部分組成：

• 在數(shù)據(jù)平面，它處理應(yīng)用程序近通信。如前所述，通常將其與應(yīng)用程序一起部署為一組網(wǎng)絡(luò)代理。

• 在控制平面，這是服務(wù)網(wǎng)的“大腦”。控制平面與代理交互以推送配置，確保服務(wù)發(fā)現(xiàn)并集中可觀察性。

服務(wù)網(wǎng)格圍繞服務(wù)間通信具有三個(gè)主要目標(biāo)：

• 連接性

• 安全

• 可觀察性

連接性

服務(wù)網(wǎng)格體系結(jié)構(gòu)的這一方面允許服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)路由。它還涵蓋了通信彈性，例如重試、超時(shí)、中斷和速率限制。

服務(wù)網(wǎng)格的主要特征是負(fù)載平衡。通過(guò)代理劃分網(wǎng)格的所有服務(wù)都允許在服務(wù)之間實(shí)施負(fù)載平衡策略，例如輪詢，隨機(jī)請(qǐng)求和最少請(qǐng)求。這些策略是服務(wù)網(wǎng)格用來(lái)決定哪個(gè)副本將接收原始請(qǐng)求的策略，就像您在每個(gè)服務(wù)前面都裝有很小的負(fù)載平衡器一樣。

最后，服務(wù)網(wǎng)格以流量轉(zhuǎn)移和鏡像的形式提供路由控制。

安全

在傳統(tǒng)的微服務(wù)體系結(jié)構(gòu)中，服務(wù)之間使用未加密的流量進(jìn)行通信。如今，就安全性而言，未加密的內(nèi)部流量被認(rèn)為是一種不良做法，尤其是對(duì)于公有云基礎(chǔ)架構(gòu)和零信任網(wǎng)絡(luò)而言。

除了在無(wú)法直接控制硬件的情況下保護(hù)客戶端數(shù)據(jù)的私密性之外，對(duì)內(nèi)部流量進(jìn)行加密還會(huì)在系統(tǒng)出現(xiàn)漏洞的情況下增加一層額外的復(fù)雜性。因此，所有服務(wù)網(wǎng)格都使用相互TLS（mTLS）加密進(jìn)行服務(wù)間通信，即所有代理間通信。

服務(wù)網(wǎng)格甚至可以強(qiáng)制執(zhí)行復(fù)雜的授權(quán)策略矩陣，基于針對(duì)特定環(huán)境和服務(wù)的策略允許或拒絕流量。

可觀察性

服務(wù)網(wǎng)格的目標(biāo)是使服務(wù)間通信具有可見(jiàn)性。通過(guò)控制網(wǎng)絡(luò)，服務(wù)網(wǎng)格可增強(qiáng)可觀察性，提供七層度量，從而在流量達(dá)到某些可自定義閾值時(shí)自動(dòng)發(fā)出警報(bào)。

通常由第三方工具或Jaeger或Zipkin之類的插件支持，此類控件還允許通過(guò)注入HTTP頭進(jìn)行注入跟蹤。

服務(wù)網(wǎng)格的好處

創(chuàng)建服務(wù)網(wǎng)格是為了抵消微服務(wù)體系結(jié)構(gòu)所帶來(lái)的一些運(yùn)營(yíng)負(fù)擔(dān)。那些具有微服務(wù)架構(gòu)經(jīng)驗(yàn)的人知道，他們每天需要花費(fèi)大量的工作來(lái)進(jìn)行操作。要充分利用微服務(wù)的潛力，通常需要外部工具來(lái)處理集中式日志記錄，配置管理和可伸縮性機(jī)制等。使用服務(wù)網(wǎng)格可標(biāo)準(zhǔn)化這些功能及其設(shè)置和集成。

尤其是服務(wù)網(wǎng)格的可觀察性，提供了極其通用的調(diào)試和優(yōu)化方法。借助對(duì)服務(wù)之間的交換的詳盡而完整的可見(jiàn)性，工程師（尤其是SRE）可以更快地解決可能的錯(cuò)誤和系統(tǒng)配置錯(cuò)誤。借助服務(wù)網(wǎng)格跟蹤，他們可以跟蹤從請(qǐng)求進(jìn)入系統(tǒng)（在負(fù)載平衡器或外部代理處）到堆棧內(nèi)部私有服務(wù)的請(qǐng)求。他們可以使用日志記錄來(lái)映射請(qǐng)求并記錄每個(gè)服務(wù)中遇到的延遲。最終深入了解系統(tǒng)性能指標(biāo)。

流量管理提供了強(qiáng)大的可能性，然后才能逐步發(fā)布服務(wù)的新版本：

• 重新路由少量請(qǐng)求。

• 更好的是，將生產(chǎn)請(qǐng)求到鏡像新版本以通過(guò)實(shí)時(shí)流量測(cè)試其行為。

• A / B測(cè)試任何服務(wù)或服務(wù)組合。

服務(wù)網(wǎng)格簡(jiǎn)化了上述所有場(chǎng)景，從而更容易避免或減輕生產(chǎn)中的任何意外情況。

Kubernetes服務(wù)網(wǎng)格比較

在許多方面，服務(wù)網(wǎng)格是微服務(wù)體系結(jié)構(gòu)的終極工具集。他們中的許多人都在頂級(jí)容器編排工具之一Kubernetes上運(yùn)行。我們選擇了當(dāng)今在Kubernetes上運(yùn)行的三個(gè)主要服務(wù)網(wǎng)格：Linkerd（v2），Istio和Consul Connect。我們還將討論其他一些服務(wù)網(wǎng)格：Kuma，Traefik Mesh和AWS App Mesh。盡管目前在使用和社區(qū)方面不那么突出，但他們有足夠的希望在這里進(jìn)行評(píng)論并保持常規(guī)狀態(tài)。

關(guān)于Sidecar代理的快速說(shuō)明

并非所有的Kubernetes服務(wù)網(wǎng)格都采用相同的架構(gòu)，但是一種常見(jiàn)的方法是利用sidecar模式。這涉及將代理（sidecar）附加到主應(yīng)用程序，以攔截和管理應(yīng)用程序的入站和出站網(wǎng)絡(luò)流量。實(shí)際上，這是在Kubernetes中通過(guò)每個(gè)應(yīng)用程序容器中的輔助容器完成的，該容器將遵循應(yīng)用程序容器的生命周期。

服務(wù)網(wǎng)格的sidecar方法有兩個(gè)主要優(yōu)點(diǎn)：

• Sidecar代理與運(yùn)行時(shí)甚至應(yīng)用程序的編程語(yǔ)言無(wú)關(guān)。這意味著很容易在整個(gè)堆棧中啟用要使用的服務(wù)網(wǎng)格的所有功能。

• Sidecar具有與應(yīng)用程序相同級(jí)別的權(quán)限和對(duì)資源的訪問(wèn)。Sidecar可以幫助監(jiān)控主應(yīng)用程序使用的資源，而無(wú)需將監(jiān)控集成到主應(yīng)用程序代碼庫(kù)中。

但是，Sidecar是好運(yùn)參半，因?yàn)樗鼈兊男袨閷⒅苯佑绊憫?yīng)用程序：

• Sidecar初始化可能會(huì)鎖死應(yīng)用程序的啟動(dòng)。

• Sidecar代理會(huì)在您的應(yīng)用程序頂部增加潛在的延遲。

• Sidecar代理還會(huì)增加資源占用量，這可能會(huì)花費(fèi)大量資金。

鑒于這些優(yōu)點(diǎn)和缺點(diǎn)，在服務(wù)網(wǎng)格社區(qū)中，sidecar方法經(jīng)常成為爭(zhēng)論的主題。也就是說(shuō)，這里比較的六個(gè)服務(wù)網(wǎng)格中的四個(gè)使用Envoy Sidecar代理，而Linkerd使用其自己的Sidecar實(shí)現(xiàn)。Traefik Mesh在其設(shè)計(jì)中不使用邊車。

Linkerd

Linkerd于2017年首次亮相，是市場(chǎng)上最古老的服務(wù)網(wǎng)格。Linkerd v1由Buoyant（由兩名前Twitter工程師創(chuàng)立的公司）創(chuàng)建，它基于Finagle和Netty。

由于Linkerd v1是一個(gè)完整的，可立即投入生產(chǎn)的服務(wù)網(wǎng)格，因此被描述為領(lǐng)先于時(shí)代。同時(shí)，在資源使用方面有點(diǎn)繁重。同樣，文檔方面的巨大差距也使得在生產(chǎn)中難以設(shè)置和運(yùn)行。

這樣，Buoyant就有機(jī)會(huì)使用完整的生產(chǎn)模型，從中獲得經(jīng)驗(yàn)，并運(yùn)用這種智慧。結(jié)果就是Conduit，這是Linkerd的完整重寫，于2018年發(fā)布，并于當(dāng)年晚些時(shí)候重命名了Linkerd v2。Linkerd v2帶來(lái)了一些引人注目的改進(jìn)。由于Buoyant很早就停止了對(duì)Linkerd v1的積極開(kāi)發(fā)，因此本文其余部分中對(duì)Linkerd的提及均指v2。

Linkerd是完全開(kāi)源的，它用Rust編寫的自制代理作為數(shù)據(jù)平面，而控制平面依賴于Go編寫。

連接性

Linkerd代理具有重試和超時(shí)功能，但在撰寫本文時(shí)，沒(méi)有中斷或延遲注入。入口支持廣泛；Linkerd擁有與以下入口控制器的集成：

• Traefik

• Nginx

• GCE

• Ambassador

• Gloo

• Contour

• Kong

Linkerd中的服務(wù)配置文件提供增強(qiáng)的路由功能，為每個(gè)路由提供用戶指標(biāo)，重試調(diào)整和超時(shí)設(shè)置。至于負(fù)載均衡，Linkerd提供自動(dòng)代理注入，其自己的儀表板以及對(duì)Grafana的本地支持。

安全

Linkerd中的mTLS支持非常方便，因?yàn)樗某跏荚O(shè)置是自動(dòng)的，并且它的每日自動(dòng)密鑰輪換也是自動(dòng)的。

可觀察性

開(kāi)箱即用，可通過(guò)CLI觀察Linkerd的統(tǒng)計(jì)信息和路由。在GUI方面，選項(xiàng)包括預(yù)制的Grafana儀表板和本機(jī)Linkerd儀表板。

Linkerd可以插入Prometheus實(shí)例。

可以通過(guò)使用OpenTelemetry（以前稱為OpenCensus）作為收集器的插件來(lái)啟用跟蹤，而Jaeger可以自己進(jìn)行跟蹤。

安裝

Linkerd安裝是通過(guò)注入sidecar代理完成的，該代理是通過(guò)在Kubernetes中的資源中添加注釋來(lái)完成的。有兩種方法可以解決此問(wèn)題：

• 使用helm。（對(duì)于許多人來(lái)說(shuō)，Helm是Kubernetes資源的首選配置和模板管理器。）

• 安裝Linkerd CLI，然后使用該命令行將Linkerd安裝到集群中。

第二種方法從下載并運(yùn)行安裝腳本開(kāi)始：

curl?-sL?https://run.linkerd.io/install?|?sh

從那里開(kāi)始，Linkerd CLI工具linkerd提供了一個(gè)有用的工具包，可以幫助安裝其余的Linkerd并與應(yīng)用程序集群和控制平面進(jìn)行交互。

linkerd check --pre將運(yùn)行Linkerd安裝所需的所有初步檢查，并提供清晰準(zhǔn)確的日志，說(shuō)明為何潛在的Linkerd安裝可能尚無(wú)法進(jìn)行。如果不使用--pre，則此命令可用于安裝后調(diào)試。

下一步是通過(guò)運(yùn)行以下命令在集群中安裝Linkerd：

linkerd?install?|?kubectl?apply?-f?-

然后，Linkerd將安裝許多不同的組件，而這些組件的資源占用卻很小。因此，他們本身就有一種微服務(wù)方法：

• linkerd-controller，提供CLI和儀表板與之交互的公共API

• linkerd-identity，提供實(shí)現(xiàn)mTLS的證書頒發(fā)機(jī)構(gòu)

• linkerd-proxy-injector，它通過(guò)更改pod的配置來(lái)處理代理的注入

• linkerd-web，它提供一個(gè)儀表板，可用于監(jiān)視部署和Pod以及內(nèi)部Linkerd組件

Linkerd的大多數(shù)配置都基于CustomResourceDefinitions（CRD）。在開(kāi)發(fā)Kubernetes附加軟件時(shí)，這被認(rèn)為是最佳實(shí)踐-就像在Kubernetes集群中持久地安裝插件一樣。

由于一些常見(jiàn)的誤解，添加分布式跟蹤（Linkerd用戶實(shí)際上可能會(huì)或可能不會(huì)跟隨它）需要添加linkerd-collector和linkerd-jaeger的另一步驟。為此，我們將首先創(chuàng)建一個(gè)配置文件：

cat?>>?config.yaml?<<?EOF tracing:enabled:?true EOF

要啟用跟蹤，我們將運(yùn)行：

linkerd?upgrade?--config?config.yaml?|?kubectl?apply?-f?-

與任何基于Sidecar代理的服務(wù)網(wǎng)格一樣，您將需要修改應(yīng)用程序代碼以啟用跟蹤。大部分工作只是添加一個(gè)客戶端庫(kù)來(lái)傳播跟蹤頭。然后需要將其包含在每個(gè)服務(wù)中。

Linkerd的流量拆分功能通過(guò)其符合Service Mesh Interface（SMI）的API公開(kāi)，已經(jīng)允許發(fā)布canary版本。但是要使它們自動(dòng)化和流量管理，您還需要外部工具，例如Flagger。

Flagger是一種漸進(jìn)式交付工具，它將評(píng)估Linkerd所謂的黃金指標(biāo)：請(qǐng)求量、成功率和等待時(shí)間分布。（最初，Google SRE使用 黃金信號(hào)一詞，并包含第四個(gè)信號(hào)-飽和度，但Linkerd并未涵蓋該信號(hào)，因?yàn)槟菍⑿枰獰o(wú)法直接訪問(wèn)的指標(biāo)（例如CPU和內(nèi)存使用情況）。）Flagger在拆分流量時(shí)會(huì)跟蹤這些指標(biāo)使用反饋回路；因此，您可以實(shí)施自動(dòng)化的，具有指標(biāo)功能的金絲雀版本。

在深入研究安裝過(guò)程之后，很明顯，要使Linkerd服務(wù)網(wǎng)格能夠運(yùn)行并利用通常需要的功能，很容易最終至少運(yùn)行十多個(gè)服務(wù)。也就是說(shuō)，Linkerd在安裝時(shí)會(huì)比其他服務(wù)網(wǎng)格提供更多的服務(wù)。

Linkerd服務(wù)網(wǎng)格摘要

優(yōu)點(diǎn)：

Linkerd受益于其創(chuàng)建者的經(jīng)驗(yàn)，兩位曾在內(nèi)部工具Finagle上工作的前Twitter工程師，后來(lái)從Linkerd v1中學(xué)習(xí)。作為最早的服務(wù)網(wǎng)格之一，Linkerd擁有一個(gè)蒸蒸日上的社區(qū)（其Slack有5,000多個(gè)用戶，還有一個(gè)活動(dòng)的郵件列表和Discord服務(wù)器）以及大量的文檔和教程。Linkerd的2.9版已經(jīng)很成熟，這一點(diǎn)已被Nordstrom，eBay，Strava，Expedia和Subspace等大公司采用。對(duì)于Linkerd，Buoyant提供了有償?shù)钠髽I(yè)級(jí)支持。

缺點(diǎn)：

要使用Linkerd服務(wù)網(wǎng)格發(fā)揮其全部潛能，有一條相當(dāng)強(qiáng)的學(xué)習(xí)曲線。Linkerd僅在Kubernetes容器中受支持（即，沒(méi)有基于VM的“通用”模式）。Linkerd Sidecar代理不是Envoy。盡管這確實(shí)使Buoyant可以按照自己的意愿進(jìn)行調(diào)整，但它消除了Envoy提供的固有可擴(kuò)展性。這也意味著Linkerd缺少對(duì)斷路，延遲注入和速率限制的支持。沒(méi)有公開(kāi)任何特定的API來(lái)輕松控制Linkerd控制平面。（不過(guò)，您可以找到gRPC API綁定。）

自v1以來(lái)，Linkerd在可用性和易于安裝方面取得了長(zhǎng)足的進(jìn)步。缺少正式公開(kāi)的API是一個(gè)明顯的遺漏。但是由于有了其他經(jīng)過(guò)深思熟慮的文檔，Linkerd中的開(kāi)箱即用功能易于測(cè)試。

Consul

我們的下一個(gè)服務(wù)網(wǎng)格競(jìng)爭(zhēng)者Consul Connect是一個(gè)獨(dú)特的混合體。HashiCorp的Consul以其分布式結(jié)構(gòu)的鍵值存儲(chǔ)而聞名，這種存儲(chǔ)已經(jīng)存在了很多年。在Consul演變?yōu)橐徽追?wù)工具之后，HashiCorp決定在其之上構(gòu)建服務(wù)網(wǎng)格：Consul Connect。

確切地說(shuō)，它具有混合性：

Consul Connect數(shù)據(jù)平面基于以C ++編寫的Envoy。Consul Connect的控制平面用Go編寫。這是由Consul KV（鍵值存儲(chǔ)）支持的部分。

像大多數(shù)其他服務(wù)網(wǎng)格一樣，Consul Connect通過(guò)在應(yīng)用程序pod內(nèi)注入sidecar代理來(lái)工作。在架構(gòu)方面，Consul Connect基于代理和服務(wù)器。開(kāi)箱即用，Consul Connect旨在使用三臺(tái)或五臺(tái)服務(wù)器作為StatefulSet指定的Pod Anti-affinity來(lái)具有高可用性（HA）。Pod反親和力是確保分布式軟件系統(tǒng)的Pod不會(huì)最終出現(xiàn)在同一節(jié)點(diǎn)（服務(wù)器）上的做法，從而在任何單個(gè)節(jié)點(diǎn)發(fā)生故障的情況下保證可用性。

連接性

沒(méi)有什么可以使Consul Connect在這一領(lǐng)域脫穎而出。它提供的任何服務(wù)網(wǎng)做什么（這是相當(dāng)多的），加上層七個(gè)特征為基于路徑的路由、故障切換和負(fù)載均衡。

安全

與其他服務(wù)網(wǎng)格一樣，Consul Connect提供基本的mTLS功能。它還具有Consul和Vault之間的本機(jī)集成（也由HashiCorp提供），可以用作CA提供程序來(lái)管理和簽署群集中的證書。

可觀察性

Consul Connect采用最常見(jiàn)的可觀察性方法，將Envoy合并為Sidecar代理，以提供7層代理功能。將Consul Connect的UI配置為獲取指標(biāo)涉及更改內(nèi)置配置文件，還需要啟用Prometheus之類的指標(biāo)提供程序。還可以配置一些Grafana儀表板以顯示相關(guān)的特定于服務(wù)的指標(biāo)。

安裝

使用Helm圖表將Consul Connect安裝到Kubernetes集群中：helm repo add hashicorp https://helm.releases.hashicorp.com

values.yaml如果要啟用UI或使Consul Connect模塊注入其sidecar代理，則需要修改默認(rèn)值：helm install -f consul-values.yml hashicorp hashicorp/consul

要咨詢成員并檢查各個(gè)節(jié)點(diǎn)，Consul建議先exec進(jìn)入其中一個(gè)容器，然后使用CLI工具consul。要提供Consul提供的現(xiàn)成的Web UI，請(qǐng)運(yùn)行kubectl port-forward service/hashicorp-consul-ui 18500:80。

Consul Connect摘要

優(yōu)點(diǎn)：

• Consul Connect由HashiCorp支持；作為免費(fèi)增值產(chǎn)品，還有一個(gè)具有附加功能的企業(yè)版，可提供企業(yè)級(jí)支持。就開(kāi)發(fā)團(tuán)隊(duì)的經(jīng)驗(yàn)而言，Consul是市場(chǎng)上最古老的工具之一。

• Consul Connect擁有堅(jiān)實(shí)的企業(yè)社區(qū)，并且眾所周知，它可以在具有50,000個(gè)節(jié)點(diǎn)的基礎(chǔ)架構(gòu)上運(yùn)行。此外，自2014年以來(lái)一直存在，使其成為相對(duì)于市場(chǎng)而言成熟的產(chǎn)品。

• 依靠本機(jī)支持，Consul Connect在VM內(nèi)運(yùn)行良好。

• 借助Consul Connect，有可能實(shí)現(xiàn)與頂級(jí)科技公司的服務(wù)前網(wǎng)格實(shí)施一樣深入的應(yīng)用程序集成。這要?dú)w功于公開(kāi)了完整文檔的庫(kù)級(jí)API。

缺點(diǎn)：

• Consul Connect具有比其他服務(wù)網(wǎng)格更陡峭的學(xué)習(xí)曲線，并且需要更多的調(diào)整才能運(yùn)行可視化的儀表板和指標(biāo)。

• HashiCorp的文檔并不簡(jiǎn)單明了，讓用戶進(jìn)行挖掘和嘗試以正確配置它。

• 流量管理文檔很難找到，并且主要包含Envoy文檔的鏈接，該文檔沒(méi)有特別提供有關(guān)Consul Connect流量管理的詳細(xì)信息。

• Consul Connect的SMI接口仍處于試驗(yàn)階段。對(duì)于那些尋求企業(yè)級(jí)產(chǎn)品的人來(lái)說(shuō)，Consul Connect是一個(gè)很好的選擇。HashiCorp以其產(chǎn)品質(zhì)量而聞名，Consul Connect也不例外。與其他服務(wù)網(wǎng)格相比，我在這里可以看到兩個(gè)強(qiáng)大的優(yōu)勢(shì)：公司對(duì)企業(yè)版的強(qiáng)大支持以及適用于各種架構(gòu)（不僅僅是Kubernetes）的工具。

Istio

2017年5月，谷歌，IBM和Lyft宣布了Istio。當(dāng)Istio進(jìn)入服務(wù)網(wǎng)格工具競(jìng)賽時(shí)，它在技術(shù)領(lǐng)域獲得了很好的曝光。它的作者從1.9版開(kāi)始就一直基于用戶反饋添加了功能。

Istio承諾在當(dāng)時(shí)向競(jìng)爭(zhēng)對(duì)手提供重要的新功能：自動(dòng)負(fù)載均衡、故障注入等等。這引起了社區(qū)的廣泛關(guān)注，但是，正如我們將在下面詳述的那樣，使用Istio絕非易事：Istio被公認(rèn)為投入生產(chǎn)特別復(fù)雜。

從歷史上看，Istio項(xiàng)目經(jīng)常在源代碼更改方面反彈。一旦在控制平面上采用微服務(wù)架構(gòu)，Istio現(xiàn)在（從版本1.5開(kāi)始）又回到了單一架構(gòu)。Istio重返集中化的理由是，微服務(wù)難以為操作員監(jiān)控，代碼庫(kù)過(guò)于冗余，并且該項(xiàng)目已經(jīng)達(dá)到組織成熟度–不再需要許多小團(tuán)隊(duì)在孤島上工作。

但是，一路走來(lái)，Istio因擁有數(shù)量最多的公開(kāi)GitHub問(wèn)題之一而聲名狼藉。截至撰寫本文時(shí)，bug的未結(jié)數(shù)量約為800個(gè)，已結(jié)bug的數(shù)量約為12,000個(gè)。盡管問(wèn)題可能很多，但在這種情況下，它們確實(shí)代表了以前損壞的功能和資源失控所帶來(lái)的有意義的改進(jìn)。

連接性

與Consul Connect和Linkerd相比，Istio在流量管理方面非常強(qiáng)大。這要?dú)w功于子功能的廣泛提供：請(qǐng)求路由、故障注入、流量轉(zhuǎn)移、請(qǐng)求超時(shí)、斷開(kāi)以及控制到服務(wù)網(wǎng)格的入口和出口流量。虛擬服務(wù)和目標(biāo)規(guī)則的概念使其在流量管理方面非常完整。

但是，所有這些可能性都伴隨著學(xué)習(xí)曲線，以及對(duì)Kubernetes集群上那些新資源的管理。

安全

Istio擁有一套全面的與安全性相關(guān)的工具，具有兩個(gè)主軸：身份驗(yàn)證和授權(quán)。Istio可以在不同的范圍內(nèi)實(shí)施不同級(jí)別的策略：特定于工作負(fù)載，整個(gè)命名空間或網(wǎng)格范圍。所有此類安全資源都通過(guò)Istio CRD（例如AuthorizationPolicy或）進(jìn)行管理PeerAuthentication。

除了標(biāo)準(zhǔn)的mTLS支持之外，還可以將Istio配置為接受或拒絕未加密的流量。

可觀察性

在這里，Istio相當(dāng)先進(jìn)，提供多種遙測(cè)功能，可提供對(duì)服務(wù)網(wǎng)格的深入了解。指標(biāo)基于四個(gè)黃金信號(hào)（等待時(shí)間，流量，錯(cuò)誤和某種程度上的飽和度）。

值得注意的是，Istio為控制平面本身提供了度量。它還提供分布式跟蹤和訪問(wèn)日志，與Jaeger，Lightstep和Zipkin具有顯式兼容性，以啟用跟蹤。

沒(méi)有本機(jī)儀表板，但對(duì)Kiali管理控制臺(tái)有官方支持。

安裝

安裝非常簡(jiǎn)單，只需遵循官方步驟即可。Istio本身也作為beta功能集成到GKE中，但是GKE使用Istio 1.4.X，它是舊的微服務(wù)版本，而不是最新的整體版本。

本地安裝從下載最新版本開(kāi)始：

curl -L https://istio.io/downloadIstio | sh -

之后cd到新創(chuàng)建的istio-文件夾，您可以將其添加到您的路徑，所以你可以使用istioctl實(shí)用工具：export PATH=$PWD/bin:$PATH在這里，您可以通過(guò)istioctl以下方式將Istio安裝到Kubernetes集群中：istioctl install

這將使用default配置文件安裝Istio 。istioctl配置文件允許您創(chuàng)建不同的安裝配置，并在必要時(shí)在它們之間切換。但是，即使在單配置文件方案中，您也可以通過(guò)修改某些CRD來(lái)深度自定義Istio的安裝。

Istio資源將很難管理，你將需要管理CRDs-的幾種VirtualService，DestinationRule以及Gateway在最低限度，以確保流量管理是否到位。

• 一個(gè)VirtualService資源是聲明的服務(wù)和不同的路由應(yīng)用到請(qǐng)求的規(guī)則的配置。

• 一個(gè)DestinationRule資源被用于分組和強(qiáng)制實(shí)施特定目標(biāo)的流量策略。

• Gateway創(chuàng)建了一個(gè)資源來(lái)管理入站和出站服務(wù)網(wǎng)格流量（即，其他Envoy代理，但在邊緣而不是作為邊車運(yùn)行）。

但讓我們來(lái)看一個(gè)簡(jiǎn)單的例子顯示了每個(gè)這些一起工作。假設(shè)我們有一個(gè)電子商務(wù)網(wǎng)站，其服務(wù)名為products。我們VirtualService可能看起來(lái)像這樣：

apiVersion:?networking.istio.io/v1alpha3 kind:?VirtualService metadata:name:?products-routenamespace:?ecommerce spec:hosts:-?products?#?interpreted?as?products.ecommerce.svc.cluster.localhttp:-?match:-?uri:prefix:?"/listv1"-?uri:prefix:?"/catalog"rewrite:uri:?"/listproducts"route:-?destination:host:?products?#?interpreted?as?products.ecommerce.svc.cluster.localsubset:?v2-?route:-?destination:host:?products?#?interpreted?asproducts.ecommerce.svc.cluster.localsubset:?v1

相應(yīng)的DestinationRule可以是：

apiVersion:?networking.istio.io/v1alpha3 kind:?DestinationRule metadata:name:?products spec:host:?productstrafficPolicy:loadBalancer:simple:?RANDOM?#?or?LEAST_CONN?or?ROUND_ROBINsubsets:-?name:?v1labels:version:?v1-?name:?v2labels:version:?v2-?name:?v3labels:version:?v3

最后，我們的Gateway：

apiVersion:?networking.istio.io/v1alpha3 kind:?Gateway metadata:name:?cert-manager-gatewaynamespace:?istio-system spec:selector:istio:?ingressgatewayservers:-?port:number:?80name:?httpprotocol:?HTTPhosts:-?"*"

有了這三個(gè)文件后，一個(gè)Istio安裝就可以處理基本流量了。

Istio服務(wù)網(wǎng)格摘要

優(yōu)點(diǎn)：

• 在撰寫本文時(shí)，在不同的服務(wù)網(wǎng)格中，Istio是最大的在線社區(qū)之一。作為其主要競(jìng)爭(zhēng)對(duì)手之一，Stack Overflow的結(jié)果超過(guò)10倍，它是Web上最受關(guān)注的服務(wù)網(wǎng)格。

• 它在GitHub貢獻(xiàn)者同樣超出了Linkerd。Istio支持Kubernetes和VM模式。后者是1.9版的beta版。

缺點(diǎn)：

Istio并非免費(fèi)，有兩種含義：

• 就閱讀文檔，設(shè)置文檔，使其正常工作和維護(hù)所需的時(shí)間而言，其要求很高。根據(jù)基礎(chǔ)架構(gòu)規(guī)模和服務(wù)數(shù)量，Istio將需要數(shù)周至數(shù)月的全職工作才能完全發(fā)揮作用并將其集成到生產(chǎn)中。

• 它還增加了大量的資源開(kāi)銷：每秒每1000個(gè)請(qǐng)求（RPS）將需要350毫安（mCPU）的Envoy容器。甚至控制平面本身也會(huì)消耗資源。（以前，很難預(yù)測(cè)資源的使用情況，但是經(jīng)過(guò)一番努力，istiod使用1個(gè)vCPU和1.5 GB的內(nèi)存已經(jīng)穩(wěn)定下來(lái)了。）

• 與Linkerd不同，它沒(méi)有本機(jī)管理儀表板。

• Istio需要使用其自己的入口網(wǎng)關(guān)。

• Istio控制平面僅在Kubernetes容器內(nèi)受支持（即，沒(méi)有VM模式，與Istio的數(shù)據(jù)平面不同）。

Istio是技術(shù)巨頭齊心協(xié)力創(chuàng)建一個(gè)開(kāi)源項(xiàng)目來(lái)應(yīng)對(duì)他們所面臨的挑戰(zhàn)的一個(gè)很好的例子。整個(gè)Istio項(xiàng)目花了一些時(shí)間來(lái)構(gòu)造自身（回想起微服務(wù)到整體架構(gòu)的轉(zhuǎn)變）并解決了許多最初的問(wèn)題。如今，Istio完全可以滿足人們對(duì)服務(wù)網(wǎng)格的所有期望，并且可以大大擴(kuò)展。但是，所有這些可能性都對(duì)知識(shí)、工作時(shí)間和計(jì)算資源提出了苛刻的要求，以支持其在生產(chǎn)環(huán)境中的使用。

Kuma快速評(píng)論

由Kong創(chuàng)建并開(kāi)放源代碼，Kuma在2020年末達(dá)到1.0。在某種程度上，它是響應(yīng)于第一個(gè)服務(wù)網(wǎng)格相當(dāng)沉重且難以操作而創(chuàng)建的。

它的功能列表表明它是非常模塊化的。Kuma背后的想法是將其定位為與已經(jīng)在Kubernetes或其他基礎(chǔ)架構(gòu)上運(yùn)行的應(yīng)用程序集成。

• 在流量管理領(lǐng)域，Kuma提供了常見(jiàn)的服務(wù)網(wǎng)格功能，例如故障注入和斷路。

• 除了服務(wù)間mTLS加密之外，還可以通過(guò)數(shù)據(jù)平面代理令牌在Kuma中保護(hù)數(shù)據(jù)平面和控制平面之間的交換。

• 在Kuma中，通過(guò)圍繞度量標(biāo)準(zhǔn)，跟蹤和日志記錄的不同流量策略定義了可觀察性。

• 由于Kuma在控制平面的端口5653上運(yùn)行了自己的DNS解析器，因此可以通過(guò)Kuma進(jìn)行服務(wù)發(fā)現(xiàn)。

• Kuma十分強(qiáng)調(diào)多網(wǎng)格功能：您可以輕松地將多個(gè)Kubernetes群集或VM環(huán)境結(jié)合到具有其多區(qū)域部署類型的常見(jiàn)Kuma群集中。

• 對(duì)于現(xiàn)有的Kong用戶，Kuma可以輕松地與Kong Gateway集成。

Kuma的通用（非Kubernetes）版本要求將PostgreSQL作為依賴項(xiàng)，并且Kong的CTO特別反對(duì)支持SMI。但是Kuma最初是基于多云和多集群部署的思想開(kāi)發(fā)的，其儀表板反映了這一點(diǎn)。

盡管Kuma在服務(wù)網(wǎng)格領(lǐng)域還很年輕，但到目前為止很少有生產(chǎn)使用案例，但這是一個(gè)有趣且有希望的競(jìng)爭(zhēng)者。

Traefik Mesh快速評(píng)論

Traefik Mesh（由Traefik Labs提供）最初名為Maesh，是服務(wù)網(wǎng)格工具競(jìng)賽中的另一個(gè)新來(lái)者。該項(xiàng)目的任務(wù)是通過(guò)易于使用和配置來(lái)使服務(wù)網(wǎng)格民主化。開(kāi)發(fā)人員在深思熟慮的Traefik Proxy方面的經(jīng)驗(yàn)使他們處于實(shí)現(xiàn)這一目標(biāo)的首要位置。

• Traefik Mesh中的流量管理功能包括斷路和速率限制。

• 在可觀察性方面，Traefik Mesh具有本機(jī)OpenTracing支持和開(kāi)箱即用的度量標(biāo)準(zhǔn)（標(biāo)準(zhǔn)安裝自動(dòng)包括Prometheus和Grafana），從而節(jié)省了設(shè)置時(shí)間。

• 為了安全起見(jiàn)，除了mTLS之外，該規(guī)范還符合SMI要求，并且Traefik Mesh允許通過(guò)訪問(wèn)控制對(duì)流量許可進(jìn)行微調(diào)。

Traefik Mesh需要在群集上安裝CoreDNS。（雖然從1.12開(kāi)始，Azure默認(rèn)使用CoreDNS，但在撰寫本文時(shí)，GKE默認(rèn)使用kube-dns，這意味著在這種情況下還涉及很多重要步驟。）它還缺乏多群集功能。

就是說(shuō)，Traefik Mesh在我們的服務(wù)網(wǎng)格比較中是獨(dú)一無(wú)二的，因?yàn)樗皇褂眠呠囎⑷搿６菍⑵渥鳛镈aemonSet部署在所有節(jié)點(diǎn)上，充當(dāng)服務(wù)之間的代理，從而使其具有非侵入性。總體而言，Traefik Mesh易于安裝和使用。

AWS App Mesh快速審閱

在云提供商的世界中，AWS是第一個(gè)實(shí)現(xiàn)可與Kubernetes（尤其是EKS）以及其他服務(wù)一起插入的本機(jī)服務(wù)網(wǎng)格的服務(wù)商。AWS App Mesh于2018年11月發(fā)布，自那時(shí)以來(lái)AWS一直在對(duì)其進(jìn)行迭代。AWS App Mesh的主要優(yōu)勢(shì)是預(yù)先存在的AWS生態(tài)系統(tǒng)和市場(chǎng)地位；整個(gè)AWS背后的大型社區(qū)將繼續(xù)推動(dòng)其使用和可用性。

• AWS App Mesh中的流量管理包括在常見(jiàn)功能之上的斷路。

• 由于AWS App Mesh由AWS托管，因此它是一項(xiàng)完全托管的服務(wù)，這意味著不必?fù)?dān)心資源使用或控制平面可用性。

• 可以通過(guò)Prometheus或AWS X-Ray實(shí)現(xiàn)AWS App Mesh中的可觀察性。

該項(xiàng)目不是開(kāi)源的，不支持SMI，并且在線上沒(méi)有太多有關(guān)控制平面的HA標(biāo)準(zhǔn)的信息。AWS App Mesh的設(shè)置比其他Kubernetes本地服務(wù)網(wǎng)格更復(fù)雜，并且在線社區(qū)很少（Stack Overflow上有24個(gè)答案，GitHub上有400個(gè)星），但這是因?yàn)橛脩舯仨殢腁WS支持中受益。

AWS App Mesh與AWS進(jìn)行了本機(jī)集成，從EKS開(kāi)始，并擴(kuò)展到其他AWS服務(wù)，例如ECS（Fargate）和EC2。與Traefik Mesh不同，它具有多集群支持。另外，像大多數(shù)服務(wù)網(wǎng)格一樣，它是基于Envoy注入的，該Envoy是經(jīng)過(guò)大量測(cè)試的Sidecar代理。

Kubernetes服務(wù)網(wǎng)格比較表

這里介紹的六個(gè)Kubernetes服務(wù)網(wǎng)格選項(xiàng)有一些共同點(diǎn)：

• 協(xié)議支持：它們都可與HTTP，HTTP / 2，gRPC，TCP和WebSockets一起使用。

• 默認(rèn)情況下，它們?cè)诖碇g均具有mTLS形式的基本安全性。

• 通過(guò)設(shè)計(jì)，服務(wù)網(wǎng)格可提供某種形式的負(fù)載平衡。

• 至少這六個(gè)工具在其流量管理功能中還至少包括一個(gè)請(qǐng)求重試選項(xiàng)。

• 最后，服務(wù)發(fā)現(xiàn)是任何服務(wù)網(wǎng)格的核心功能。

但是，在服務(wù)網(wǎng)格基礎(chǔ)結(jié)構(gòu)，流量管理，可觀察性，部署和其他方面，肯定有一些值得強(qiáng)調(diào)的差異。

基礎(chǔ)設(shè)施

流量管理

可觀察性

OpenCensus和OpenTracing在2019年合并為OpenTelemetry，但您可能會(huì)發(fā)現(xiàn)Linkerd文章涉及OpenCensus，以及Istio和Traefik Mesh文章涉及OpenTracing。

部署方式

注意事項(xiàng)

我們應(yīng)該使用Kubernetes服務(wù)網(wǎng)格嗎？

現(xiàn)在，我們已經(jīng)了解了什么是服務(wù)網(wǎng)格，它們?nèi)绾喂ぷ饕约八鼈冎g的眾多差異，我們可以問(wèn)：我們是否需要服務(wù)網(wǎng)格？

這是過(guò)去幾年中SRE和云工程師面臨的一個(gè)大問(wèn)題。實(shí)際上，微服務(wù)給服務(wù)網(wǎng)格可以解決的網(wǎng)絡(luò)通信帶來(lái)了運(yùn)營(yíng)挑戰(zhàn)。但是，在安裝和操作方面，服務(wù)網(wǎng)格在大多數(shù)情況下會(huì)帶來(lái)自身的挑戰(zhàn)。

我們可以看到，在許多項(xiàng)目中出現(xiàn)的一個(gè)問(wèn)題是，服務(wù)網(wǎng)格在概念驗(yàn)證階段和生產(chǎn)階段之間存在差距。也就是說(shuō)，對(duì)于公司而言，實(shí)現(xiàn)在各個(gè)方面都與生產(chǎn)相同的過(guò)渡環(huán)境是非常罕見(jiàn)的。由于服務(wù)網(wǎng)格涉及關(guān)鍵基礎(chǔ)架構(gòu)，因此與規(guī)模和邊緣相關(guān)的影響可能會(huì)帶來(lái)部署方面的意外。

服務(wù)網(wǎng)格仍在大力發(fā)展和改進(jìn)。對(duì)于部署頻率較高的團(tuán)隊(duì)來(lái)說(shuō)，這實(shí)際上可能是有吸引力的，這些團(tuán)隊(duì)已經(jīng)掌握了保持最新版本并可以密切關(guān)注云原生工具的開(kāi)發(fā)周期。

但是，對(duì)于其他人而言，服務(wù)網(wǎng)格演進(jìn)的速度可能更是一個(gè)陷阱。設(shè)置服務(wù)網(wǎng)格將很容易，但如果隨后沒(méi)有及時(shí)維護(hù)它。安全補(bǔ)丁可能無(wú)法應(yīng)用，或者即使被記住，也可能以不推薦使用的功能或經(jīng)過(guò)修改的依賴項(xiàng)集的形式帶來(lái)計(jì)劃外的問(wèn)題。

就在生產(chǎn)中建立服務(wù)網(wǎng)格的人力而言，這也是一筆可觀的成本。任何團(tuán)隊(duì)評(píng)估此信息并了解服務(wù)網(wǎng)格的好處是否會(huì)超過(guò)初始設(shè)置時(shí)間，將是一個(gè)明智的目標(biāo)。無(wú)論“簡(jiǎn)易”演示安裝顯示了什么，服務(wù)網(wǎng)格都是很難的。

簡(jiǎn)而言之，服務(wù)網(wǎng)格可以解決大規(guī)模部署項(xiàng)目中常見(jiàn)的一些問(wèn)題，但可能會(huì)引入其他問(wèn)題，因此要準(zhǔn)備投入時(shí)間和精力。在一個(gè)假設(shè)的基礎(chǔ)結(jié)構(gòu)中，該基礎(chǔ)結(jié)構(gòu)涉及25個(gè)微服務(wù)，并且每秒要處理5個(gè)查詢，我建議至少有一個(gè)人（最好是兩個(gè)人）專門工作至少一個(gè)月，以準(zhǔn)備概念證明并驗(yàn)證關(guān)鍵方面，然后再考慮在生產(chǎn)環(huán)境中運(yùn)行它。設(shè)置完成后，請(qǐng)預(yù)測(cè)是否需要頻繁升級(jí)-它們將影響基礎(chǔ)架構(gòu)的核心組件，即網(wǎng)絡(luò)通信。

Kubernetes服務(wù)網(wǎng)格：可擴(kuò)展應(yīng)用程序架構(gòu)中的（復(fù)雜）演進(jìn)

我們已經(jīng)了解了什么是服務(wù)網(wǎng)格：一套工具，可以應(yīng)對(duì)微服務(wù)架構(gòu)引入的新挑戰(zhàn)。通過(guò)流量管理，可觀察性，服務(wù)發(fā)現(xiàn)和增強(qiáng)的安全性，服務(wù)網(wǎng)格可以揭示對(duì)應(yīng)用程序基礎(chǔ)架構(gòu)的深入了解。

市場(chǎng)上有多個(gè)參與者，有時(shí)是由GAFAM等組織提倡的，在某些情況下，它們是開(kāi)源的或促進(jìn)了他們自己的內(nèi)部工具。盡管有兩種不同的實(shí)現(xiàn)類型，但是服務(wù)網(wǎng)格將始終具有由代理構(gòu)成的控制平面（系統(tǒng)的大腦）和數(shù)據(jù)平面，這些代理將攔截您的應(yīng)用程序的請(qǐng)求。

回顧三個(gè)最大的服務(wù)網(wǎng)格（Linkerd，Consul Connect和Istio），我們看到了他們選擇實(shí)施的不同策略以及它們帶來(lái)的優(yōu)勢(shì)。Linkerd是市場(chǎng)上最古老的服務(wù)網(wǎng)格，得益于其在Twitter上的創(chuàng)建者經(jīng)驗(yàn)。就HashiCorp而言，它提供企業(yè)級(jí)的Consul Connect，并具有高水平的專業(yè)知識(shí)和支持。Istio最初在網(wǎng)絡(luò)上引起了足夠的關(guān)注，但現(xiàn)在已經(jīng)發(fā)展成為一個(gè)成熟的項(xiàng)目，最終提供了功能完善的平臺(tái)。

但是，這些角色遠(yuǎn)非僅有這些角色，而是出現(xiàn)了一些鮮為人知的服務(wù)網(wǎng)格：Kuma，Traefik Mesh和AWS App Mesh等。來(lái)自Kong的Kuma的創(chuàng)建是為了使服務(wù)網(wǎng)格的想法“簡(jiǎn)單”并且可插入任何系統(tǒng)中，而不僅僅是Kubernetes。Traefik Mesh得益于已有的Traefik Proxy的經(jīng)驗(yàn)，并做出了避免使用邊車代理的罕見(jiàn)決定。最后但并非最不重要的一點(diǎn)是，AWS決定開(kāi)發(fā)自己的版本的服務(wù)網(wǎng)格，但是它依賴可靠的Envoy Sidecar代理。

實(shí)際上，服務(wù)網(wǎng)格仍然很難實(shí)現(xiàn)。盡管服務(wù)網(wǎng)格的好處引人注目，但它們的影響卻在兩個(gè)方面都截然不同：服務(wù)網(wǎng)格的失敗可能使您的微服務(wù)無(wú)法相互通信，從而可能破壞整個(gè)堆棧。一個(gè)臭名昭著的例子是：Linkerd版本和Kubernetes版本之間的不兼容性在在線銀行Monzo造成了全面的生產(chǎn)中斷。

盡管如此，整個(gè)行業(yè)都在圍繞Kubernetes和諸如Microsoft帶頭的SMI之類的計(jì)劃進(jìn)行結(jié)構(gòu)調(diào)整，SMI是Kubernetes上服務(wù)網(wǎng)格的標(biāo)準(zhǔn)接口。在眾多其他項(xiàng)目中，Cloud Native Computing Foundation（CNCF）擁有基于Envoy的開(kāi)放服務(wù)網(wǎng)格（OSM）計(jì)劃，該計(jì)劃最初也是由Microsoft引入的。服務(wù)網(wǎng)格生態(tài)系統(tǒng)仍然很熱鬧，我預(yù)測(cè)在未來(lái)幾年會(huì)出現(xiàn)一個(gè)冠軍，就像Kubernetes成為事實(shí)上的容器編排工具一樣。

推薦

---

過(guò)早關(guān)注基礎(chǔ)設(shè)施建設(shè)是萬(wàn)惡之源

Kubernetes入門培訓(xùn)（內(nèi)含PPT）

從Ice到Kubernetes容器技術(shù)，微服務(wù)架構(gòu)經(jīng)歷了什么？

---

隨手關(guān)注或者”在看“，誠(chéng)摯感謝

總結(jié)

以上是生活随笔為你收集整理的Linkerd、Consul、Istio、Kuma、Traefik、AWS App服务网格全方位对比的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。