微服務(wù)作為現(xiàn)代組織事實(shí)上的軟件架構(gòu)風(fēng)格的興起以及云原生應(yīng)用程序模型的快速采用為應(yīng)用程序基礎(chǔ)架構(gòu)和應(yīng)用程序管理帶來了各種變化。

雖然我們?cè)贒evOps Cloud-Native Tool Landscape中簡(jiǎn)要談到了這個(gè)主題，但本文將深入探討細(xì)節(jié)。要了解服務(wù)器網(wǎng)格背后的原因，我們首先需要了解云原生模型。云原生應(yīng)用程序通常包含數(shù)百個(gè)微服務(wù)，并且根據(jù)服務(wù)的大小，每個(gè)服務(wù)可能會(huì)進(jìn)一步泄露到數(shù)千個(gè)實(shí)例中。

當(dāng)您將啟用編排的調(diào)度添加到組合中時(shí)，生成的微服務(wù)結(jié)構(gòu)非常復(fù)雜，這使得服務(wù)間通信成為一個(gè)非常困難的過程。這就是服務(wù)網(wǎng)格的用武之地。

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

簡(jiǎn)而言之，服務(wù)網(wǎng)格是一個(gè)專用的基礎(chǔ)設(shè)施層，添加它是為了確保構(gòu)成應(yīng)用程序的微服務(wù)之間的通信流程簡(jiǎn)化。作為低延遲運(yùn)行的可配置基礎(chǔ)設(shè)施層，服務(wù)網(wǎng)格旨在處理應(yīng)用程序基礎(chǔ)設(shè)施服務(wù)之間發(fā)生的越來越多的進(jìn)程間通信。

隨著云原生應(yīng)用模型的興起，開發(fā)者面臨著越來越多的微服務(wù)的前景。這導(dǎo)致越來越需要使服務(wù)間通信盡可能快速和安全。在實(shí)際世界中，服務(wù)網(wǎng)格的實(shí)現(xiàn)是通過部署大量與應(yīng)用程序代碼一起工作的網(wǎng)絡(luò)代理（標(biāo)記為“邊車”）來完成的。每個(gè)服務(wù)器實(shí)例都部署了一個(gè) sidecar。

應(yīng)用程序是否知道此類代理的部署？原則上，應(yīng)用程序不需要。但是，根據(jù)部署情況，開發(fā)人員可能決定讓應(yīng)用程序了解此類網(wǎng)絡(luò)代理。最近，組織越來越多地將服務(wù)網(wǎng)格作為云原生應(yīng)用程序模型的重要組成部分。采用服務(wù)網(wǎng)格的知名組織包括 PayPal、Ticketmaster 和 Credit Karma。甚至云原生計(jì)算基金會(huì)也接受了 Linkerd——流行的開源服務(wù)網(wǎng)格——作為一個(gè)官方項(xiàng)目。這證明了服務(wù)網(wǎng)格在現(xiàn)代應(yīng)用程序環(huán)境中越來越受歡迎。

服務(wù)網(wǎng)格作為一種網(wǎng)絡(luò)模型

關(guān)于服務(wù)網(wǎng)格是否是一種網(wǎng)絡(luò)模型，人們提出了各種問題。雖然服務(wù)網(wǎng)格絕對(duì)是一種網(wǎng)絡(luò)模型，但它在 TCP/IP 之上的抽象層中運(yùn)行。此網(wǎng)絡(luò)模型與預(yù)定義的假設(shè)一起工作，即底層 L3/L4 網(wǎng)絡(luò)可運(yùn)行并在各種服務(wù)間點(diǎn)之間傳送字節(jié)。這種服務(wù)網(wǎng)格網(wǎng)絡(luò)模型的另一個(gè)假設(shè)是當(dāng)前網(wǎng)絡(luò)仍然不可靠，這意味著網(wǎng)格應(yīng)該具備網(wǎng)絡(luò)故障能力。

與 TCP/IP 的相似之處

如上所述，服務(wù)網(wǎng)格位于 TCP/IP 層之上的抽象層，但它與通信協(xié)議共享各種特性。以下是一些相似之處：

1. TCP 堆棧的任務(wù)是抽象出在網(wǎng)絡(luò)端點(diǎn)之間可靠地傳送字節(jié)的機(jī)制。同樣，服務(wù)網(wǎng)格還負(fù)責(zé)抽象技術(shù)細(xì)節(jié)，以配置每個(gè)請(qǐng)求到相關(guān)服務(wù)的安全交付。
2. 服務(wù)網(wǎng)格與定義的有效負(fù)載及其加密技術(shù)無關(guān)。這是 3。就像 TCP/IP 協(xié)議具有內(nèi)置的故障排除能力一樣，服務(wù)網(wǎng)格也旨在實(shí)現(xiàn)其指定的目標(biāo)（例如，“將 X 從服務(wù) 1 發(fā)送到服務(wù) 2”），而不管網(wǎng)絡(luò)上的任何故障方法。

但是，這兩種網(wǎng)絡(luò)模型之間存在顯著差異，允許服務(wù)模型在 TCP/IP 協(xié)議之上運(yùn)行一層。雖然后一種模型旨在完成分配的任務(wù)，但服務(wù)網(wǎng)格在更廣泛的范圍內(nèi)運(yùn)行。

除了完成分配的目標(biāo)外，服務(wù)網(wǎng)格還負(fù)責(zé)讓開發(fā)人員增強(qiáng)對(duì)應(yīng)用程序運(yùn)行時(shí)的可見性和控制。雖然服務(wù)通信更像是一項(xiàng)獨(dú)立運(yùn)行的后端任務(wù)，但服務(wù)網(wǎng)格的集成可以更有效地對(duì)其進(jìn)行監(jiān)控和管理。

服務(wù)網(wǎng)格實(shí)際上是如何工作的？

對(duì)高級(jí)通信協(xié)議的需求源于現(xiàn)代應(yīng)用程序的復(fù)雜性。服務(wù)網(wǎng)格的集成不僅簡(jiǎn)化了整個(gè)流程，還使整個(gè)團(tuán)隊(duì)的工作效率更高。與每個(gè)服務(wù)器實(shí)例相連的網(wǎng)絡(luò)代理（邊車）負(fù)責(zé)各種功能，否則這些功能將由每個(gè)微服務(wù)自行完成。這些功能包括服務(wù)間通信和監(jiān)控任何與安全相關(guān)的活動(dòng)。

這允許明確區(qū)??分應(yīng)用程序的管理方式，因?yàn)殚_發(fā)人員現(xiàn)在可以只關(guān)注應(yīng)用程序代碼管理，這涉及開發(fā)、支持和維護(hù)。另一方面，運(yùn)維團(tuán)隊(duì)可以有效管理服務(wù)網(wǎng)格和應(yīng)用運(yùn)行服務(wù)?，F(xiàn)代服務(wù)網(wǎng)格，例如開源Linkerd，通過利用各種先進(jìn)技術(shù)來處理這些問題。

其中一些技術(shù)包括：

• 熔斷
• 負(fù)載平衡（考慮延遲要求）
• 始終可用的服務(wù)發(fā)現(xiàn)
• 截止日期和重試

服務(wù)網(wǎng)格的任務(wù)是利用這些特性，并確保它們與它們運(yùn)行的??復(fù)雜環(huán)境協(xié)同工作。

有關(guān)服務(wù)網(wǎng)格如何工作的分步指南

為了詳細(xì)說明服務(wù)網(wǎng)格的運(yùn)行方式，我們將使用一個(gè)示例場(chǎng)景。對(duì)于此實(shí)例，我們將介紹服務(wù)網(wǎng)格 (Linkerd) 收到請(qǐng)求后發(fā)生的事件：

步驟 1

收到請(qǐng)求后，服務(wù)網(wǎng)格的任務(wù)是確定服務(wù)應(yīng)指向何處。有各種各樣的問題需要回答：

• 所需服務(wù)是在生產(chǎn)階段還是在登臺(tái)階段？
• 服務(wù)位于本地?cái)?shù)據(jù)中心還是云端？
• 請(qǐng)求是指仍在測(cè)試中的微服務(wù)版本還是已經(jīng)測(cè)試并部署到生產(chǎn)環(huán)境中的版本？

這種分層決策能力允許服務(wù)網(wǎng)格定位到正確的目的地。此外，所有這些路由協(xié)議都是可配置的，并且可以應(yīng)用于兩種類型的流量——全局流量和任意流量。

步驟 2

一旦找到所需微服務(wù)的確切目的地，服務(wù)網(wǎng)格必須檢索與來自發(fā)現(xiàn)端點(diǎn)的請(qǐng)求中概述的詳細(xì)信息相對(duì)應(yīng)的服務(wù)器實(shí)例。如果檢索到的數(shù)據(jù)與服務(wù)網(wǎng)格在實(shí)踐中通常監(jiān)控的數(shù)據(jù)相反，它將立即決定信任哪個(gè)信息源。

步驟 3

最終實(shí)例是根據(jù)他們的反應(yīng)速度來選擇的。服務(wù)網(wǎng)格如何衡量這一點(diǎn)？它監(jiān)控觀察到的最近請(qǐng)求的延遲，然后選擇花費(fèi)最少時(shí)間的實(shí)例。然后，服務(wù)網(wǎng)格將請(qǐng)求發(fā)送到實(shí)例，如果成功執(zhí)行，則記錄結(jié)果結(jié)果的延遲和響應(yīng)類型。

步驟 4

有時(shí)，服務(wù)器實(shí)例可能會(huì)出現(xiàn)故障，從而阻礙請(qǐng)求的成功執(zhí)行。這可能是由于某個(gè)實(shí)例發(fā)生故障、變得無響應(yīng)或因維護(hù)而停機(jī)。在這種情況下，服務(wù)網(wǎng)格會(huì)在另一個(gè)實(shí)例上重試請(qǐng)求。然而，這種做法的唯一問題是，如果請(qǐng)求是冪等的，服務(wù)網(wǎng)格只會(huì)用另一個(gè)實(shí)例重試。冪等請(qǐng)求導(dǎo)致相同的結(jié)果，無論它們?cè)谀膫€(gè)服務(wù)實(shí)例中執(zhí)行。

步驟 5

一旦請(qǐng)求成功執(zhí)行，現(xiàn)代服務(wù)網(wǎng)格允許記錄和觀察關(guān)鍵指標(biāo)。他們分析這種行為的每一個(gè)細(xì)節(jié)，并以度量和分布式跟蹤的形式記錄下來——然后傳輸?shù)揭粋€(gè)集中的度量系統(tǒng)。

那不是全部

還記得我告訴過你服務(wù)網(wǎng)格具有高級(jí)故障排除能力嗎？如果一個(gè)服務(wù)器實(shí)例不斷返回錯(cuò)誤，那么服務(wù)網(wǎng)格不會(huì)簡(jiǎn)單地忽略該實(shí)例。服務(wù)網(wǎng)格將這樣的服務(wù)器實(shí)例從整個(gè)負(fù)載均衡池中移除。這允許轉(zhuǎn)換資源并提高效率。

這是另一個(gè)展示現(xiàn)代服務(wù)網(wǎng)格功效的示例。當(dāng)一個(gè)請(qǐng)求由于截止日期而過去時(shí)，服務(wù)網(wǎng)格會(huì)識(shí)別此類請(qǐng)求并自動(dòng)使請(qǐng)求失敗。服務(wù)網(wǎng)格不會(huì)繼續(xù)重試失敗的請(qǐng)求并增加網(wǎng)絡(luò)負(fù)載，而是確保資源的有效分配。除了其他功能外，服務(wù)網(wǎng)格還可以執(zhí)行協(xié)議升級(jí)、動(dòng)態(tài)切換流量以及在其他服務(wù)中啟動(dòng)和終止 TLS。

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

使用服務(wù)網(wǎng)格作為抽象層有多種好處。這里是其中的一些：

提高標(biāo)準(zhǔn)化

隨著現(xiàn)代應(yīng)用程序繼續(xù)分布在一個(gè)龐大的基礎(chǔ)上，它們的功能行為也變得極其不穩(wěn)定——這取決于底層支持網(wǎng)絡(luò)。由于跨不同網(wǎng)絡(luò)的這種不同行為，確保應(yīng)用程序的全天候可用性可能成為一項(xiàng)嚴(yán)峻的挑戰(zhàn)。使用服務(wù)網(wǎng)格，網(wǎng)格可以處理應(yīng)用程序的旋轉(zhuǎn)、折疊和分割。它使數(shù)據(jù)中心更加標(biāo)準(zhǔn)化和組織化。

增強(qiáng)可見性

高級(jí)服務(wù)網(wǎng)格分析請(qǐng)求行為以確定請(qǐng)求最多的組件，以便可以定位它們以便于訪問。再加上它的問題排查能力，它對(duì)整個(gè)系統(tǒng)有一個(gè)全面的概覽。如前所述，服務(wù)網(wǎng)格可以存儲(chǔ)此數(shù)據(jù)以供進(jìn)一步使用。開發(fā)人員可以使用這些數(shù)據(jù)來識(shí)別趨勢(shì)和威脅，從而改進(jìn)整個(gè)開發(fā)和構(gòu)建過程。

高級(jí)安全

與單體軟件架構(gòu)相反，微服務(wù)軟件由不同種類的服務(wù)組成。有些可能有很長(zhǎng)的壽命，而另一些的生命周期很短。這使得唯一身份的分配和工作政策的執(zhí)行變得越來越復(fù)雜。

相反，開發(fā)人員可以使用服務(wù)網(wǎng)格在所有實(shí)時(shí)實(shí)例和所有可操作的微服務(wù)上實(shí)施相關(guān)策略。由于它能夠識(shí)別正在運(yùn)行的微服務(wù)及其運(yùn)行位置，因此它可以根據(jù)微服務(wù)的類型和行為應(yīng)用策略。這不僅消除了為每個(gè)服務(wù)或?qū)嵗峙湮ㄒ?ID 的需要，而且還允許開發(fā)人員無誤地執(zhí)行策略。

主要服務(wù)網(wǎng)格工具

有多種服務(wù)網(wǎng)格工具可供開發(fā)人員使用。然而，與云原生應(yīng)用程序的其他方面不同，該領(lǐng)域可用的工具大多是開源項(xiàng)目。在服務(wù)網(wǎng)格方面，沒有現(xiàn)成的商業(yè)工具。

以下是最受歡迎的列表：

Linkerd

發(fā)音為“l(fā)inker-dee”，這是所有服務(wù)網(wǎng)格中最古老的，于 2016 年發(fā)布。它基本上是從 Twitter 開發(fā)的庫(kù)設(shè)計(jì)的衍生項(xiàng)目開始的。還有另一個(gè)服務(wù)網(wǎng)格，Conduit，它獲得了廣泛的普及。然而，它在 2017 年被整合到 Linkerd 程序中，并在 Linked 2.0 的創(chuàng)建中發(fā)揮了重要作用。

Envoy

Envoy 是另一個(gè)服務(wù)網(wǎng)格，它的起源可以追溯到一個(gè)著名的組織。在這種情況下，它是 Lyft。特使針對(duì)服務(wù)網(wǎng)格的“數(shù)據(jù)計(jì)劃”部分。為了提供完整的功能，它需要與“控制平面”服務(wù)網(wǎng)格結(jié)合使用。

Istio

為了讓像 Envoy 這樣的“數(shù)據(jù)平面”服務(wù)網(wǎng)格平臺(tái)正常工作，組織需要一個(gè)“控制平面”服務(wù)網(wǎng)格。這就是 Istio 應(yīng)運(yùn)而生的原因。作為 IBM、谷歌和 Lyft 之間的協(xié)作成果——Istio 和 Envoy 成對(duì)運(yùn)行，在兩個(gè)服務(wù)網(wǎng)格組件之間提供完整的平臺(tái)內(nèi)可行性。

HashiCorp顧問

HashiCorp 本質(zhì)上作為一個(gè)用于服務(wù)發(fā)現(xiàn)和配置的分布式系統(tǒng)運(yùn)行。然而，隨著 Consul 1.2 的發(fā)布，他們引入了一個(gè)名為 Connect 的功能，該功能允許服務(wù)加密和基于身份的授權(quán)。這將它變成了一個(gè)完整的服務(wù)網(wǎng)格產(chǎn)品。

結(jié)論

隨著開發(fā)人員繼續(xù)應(yīng)對(duì)管理微服務(wù)帶來的復(fù)雜性，服務(wù)網(wǎng)格將繼續(xù)在云原生應(yīng)用程序生態(tài)系統(tǒng)中得到更多采用。隨著利用服務(wù)網(wǎng)格的用戶和開發(fā)人員社區(qū)蓬勃發(fā)展，全球各地的組織已經(jīng)開始將服務(wù)網(wǎng)格集成到他們的軟件架構(gòu)設(shè)計(jì)中。隨著計(jì)算的不斷發(fā)展，服務(wù)網(wǎng)格在應(yīng)用程序環(huán)境中的范圍也將發(fā)生變化。