你的組織是否使用微服務(wù)風(fēng)格的體系結(jié)構(gòu)來實(shí)現(xiàn)其業(yè)務(wù)功能？你使用什么方法來實(shí)現(xiàn)微服務(wù)的通信和編排？在過去的幾年中，微服務(wù)一直是一個(gè)相當(dāng)占主導(dǎo)地位的應(yīng)用程序架構(gòu)，通常與云平臺(tái)（例如，容器、K8s、FaaS（功能即服務(wù)）、臨時(shí)云服務(wù)）結(jié)合在一起使用。這些服務(wù)類型之間的通信模式差別很大。

微服務(wù)體系結(jié)構(gòu)強(qiáng)調(diào)獨(dú)立性和頻繁更改的能力，但這些服務(wù)通常需要共享數(shù)據(jù)，并在它們之間發(fā)起復(fù)雜的交互，以完成它們的功能。在本文中，我們將研究微服務(wù)通信的模式和策略。

一、網(wǎng)絡(luò)中的問題

通過網(wǎng)絡(luò)進(jìn)行通信會(huì)帶來可靠性問題。數(shù)據(jù)包可能被丟棄、延遲或重復(fù)，所有這些都可能導(dǎo)致服務(wù)到服務(wù)通信的異常和不可靠。在最基本的情況下-服務(wù)A打開到服務(wù)B的連接-我們非常信任應(yīng)用程序庫和網(wǎng)絡(luò)本身，以打開連接并向目標(biāo)服務(wù)（在本例中是服務(wù)B）發(fā)送請(qǐng)求。

圖1：服務(wù)A調(diào)用服務(wù)B的簡(jiǎn)單示例

但如果連接需要很長(zhǎng)時(shí)間才能打開，會(huì)發(fā)生什么呢？如果連接超時(shí)無法打開該怎么辦？如果連接成功，但隨后在處理請(qǐng)求之后、響應(yīng)之前關(guān)閉該連接怎么辦？

我們需要一種快速檢測(cè)連接或請(qǐng)求問題并決定如何處理的方法。如果服務(wù)A無法與服務(wù)B通信，可能會(huì)有一些合理的返回（如，返回錯(cuò)誤消息、響應(yīng)固定內(nèi)容、使用緩存值進(jìn)行響應(yīng)）。

圖2：調(diào)用多個(gè)服務(wù)的更復(fù)雜的示例

在稍微復(fù)雜一些的情況下，服務(wù)A可能需要調(diào)用服務(wù)B，從服務(wù)B的響應(yīng)中檢索一些值，然后使用它調(diào)用服務(wù)C。如果對(duì)服務(wù)B的調(diào)用成功，但對(duì)服務(wù)C的調(diào)用失敗，那么返回選項(xiàng)可能會(huì)稍微復(fù)雜一些。

也許我們可以回退到一個(gè)預(yù)定義的響應(yīng)，重試請(qǐng)求，根據(jù)服務(wù)B響應(yīng)的一些數(shù)據(jù)從緩存中提取數(shù)據(jù)，或者調(diào)用一個(gè)不同的服務(wù)？

網(wǎng)絡(luò)中導(dǎo)致連接或請(qǐng)求失敗的問題可能會(huì)間歇性地發(fā)生，應(yīng)用程序必須處理這些問題。

隨著從給定服務(wù)編排的服務(wù)調(diào)用越多，這些問題就越有可能發(fā)生，也越復(fù)雜，如圖3所示。

圖3：嘗試編排跨讀/寫API的多個(gè)服務(wù)調(diào)用示例

當(dāng)這些服務(wù)間的調(diào)用不僅僅是“讀”調(diào)用時(shí)，這些問題將變得更加麻煩。

例如，如果服務(wù)A調(diào)用服務(wù)B，服務(wù)B執(zhí)行某種必須與下一次對(duì)服務(wù)C的調(diào)用需使用的數(shù)據(jù)變更(例如，服務(wù)A告訴服務(wù)B客戶Joe的地址已更新，但還必須告訴服務(wù)C由于地址更改而更改運(yùn)輸)，那么這些失敗的調(diào)用是重要的。

這可能會(huì)導(dǎo)致不同服務(wù)之間的數(shù)據(jù)不一致和狀態(tài)不一致。

這樣的網(wǎng)絡(luò)錯(cuò)誤會(huì)影響微服務(wù)的彈性、數(shù)據(jù)一致性以及可能的服務(wù)級(jí)別目標(biāo)(SLOs)和服務(wù)級(jí)別協(xié)議(SLAs)。

我們需要一種方法來處理這些網(wǎng)絡(luò)問題，同時(shí)考慮在嘗試解釋故障時(shí)突然出現(xiàn)的其他問題。

二、有用的網(wǎng)絡(luò)彈性模式

構(gòu)建API和服務(wù)來抵御網(wǎng)絡(luò)的不可靠性并不總是那么容易。服務(wù)(包括用于構(gòu)建服務(wù)的框架和庫)可能會(huì)因?yàn)榫W(wǎng)絡(luò)而失敗，有時(shí)會(huì)以不可預(yù)測(cè)的方式發(fā)生。這里介紹了一些有助于構(gòu)建彈性服務(wù)通信的模式，但肯定不是唯一的模式。

這三種模式可以根據(jù)需要使用，也可以結(jié)合使用來提高通信的可靠性（但每種模式都有自己的缺點(diǎn)）：

重試/回退重試-如果調(diào)用失敗，重新發(fā)送請(qǐng)求，可能會(huì)等待一段時(shí)間再嘗試。

冪等請(qǐng)求處理-對(duì)一個(gè)請(qǐng)求進(jìn)行多次處理并得到相同結(jié)果的能力（可能涉及對(duì)寫操作的重復(fù)刪除處理）。

異步請(qǐng)求處理-消除兩個(gè)服務(wù)之間的時(shí)間耦合，以確保請(qǐng)求傳遞成功。

讓我們來仔細(xì)看看這些模式。

三、具有回退處理的重試

網(wǎng)絡(luò)的不可靠性隨時(shí)可能發(fā)生，如果請(qǐng)求失敗或無法建立連接，最簡(jiǎn)單的方法之一就是重試。通常，我們需要某種有限的重試次數(shù)（例如，“重試兩次”VS“無限重試”），并且可能需要一種回退重試的方法。

有了回退機(jī)制，我們可以錯(cuò)開調(diào)用失敗和重試所花費(fèi)的時(shí)間。

關(guān)于重試的一個(gè)簡(jiǎn)短說明：我們不能永遠(yuǎn)重試，也不能將每個(gè)服務(wù)配置為重試相同次數(shù)。重試可能會(huì)對(duì)“重試風(fēng)暴”事件產(chǎn)生負(fù)面影響，在這些事件中，服務(wù)降級(jí)，調(diào)用服務(wù)多次重試，從而對(duì)降級(jí)的服務(wù)施加壓力，并最終關(guān)閉（或在嘗試恢復(fù)時(shí)將其關(guān)閉）。一開始可以在調(diào)用鏈的較高位置使用少量固定的重試次數(shù)（例如，兩次），并且不要在調(diào)用鏈的較深處重試。

四、冪等請(qǐng)求處理

對(duì)于基于傳入請(qǐng)求對(duì)數(shù)據(jù)進(jìn)行更改的服務(wù)，服務(wù)提供者實(shí)現(xiàn)冪等請(qǐng)求處理。一個(gè)簡(jiǎn)單的例子是計(jì)數(shù)器服務(wù)，它保持運(yùn)行的總計(jì)數(shù)，并根據(jù)傳入的請(qǐng)求增加計(jì)數(shù)。

例如，可能傳入一個(gè)值為“5”的請(qǐng)求，計(jì)數(shù)器服務(wù)將使當(dāng)前計(jì)數(shù)增加5。但是，如果服務(wù)處理請(qǐng)求(以5為增量)，但不知何故返回給客戶機(jī)的響應(yīng)丟失了（網(wǎng)絡(luò)丟包、連接失敗等），該怎么辦？

客戶端可能會(huì)重試請(qǐng)求，但這將使計(jì)數(shù)再次增加5，而這可能不是所希望的狀態(tài)。我們希望服務(wù)知道它已經(jīng)看到了一個(gè)特定的請(qǐng)求，然后要么忽略它，要么應(yīng)用一個(gè)“no-op”。如果服務(wù)被構(gòu)建為冪等處理請(qǐng)求，那么客戶機(jī)可以放心地重試失敗的請(qǐng)求，因?yàn)榉?wù)能夠過濾掉那些重復(fù)的請(qǐng)求。

五、異步請(qǐng)求處理

對(duì)于前面示例中的服務(wù)交互，我們已經(jīng)假設(shè)了某種類型的請(qǐng)求/響應(yīng)交互，但是我們可以通過依賴某種隊(duì)列或日志機(jī)制來在傳遞中持久化消息并將其交付給使用者，從而減輕網(wǎng)絡(luò)的一些麻煩。在這個(gè)模型中，我們?nèi)サ袅苏?qǐng)求的發(fā)送方和接收方在同一時(shí)間同時(shí)可用的可能性。

我們可以信任消息日志或隊(duì)列在未來的某個(gè)時(shí)刻保存和傳遞消息。重試和冪等請(qǐng)求處理也適用于異步場(chǎng)景。如果消息使用者能夠正確地應(yīng)用可能在“至少一次交付”保證中發(fā)生的更改，那么我們就不需要更復(fù)雜的事務(wù)協(xié)調(diào)。

六、服務(wù)到服務(wù)通信的基本工具和考慮事項(xiàng)

為了將彈性構(gòu)建到服務(wù)到服務(wù)的通信中，團(tuán)隊(duì)可能依賴于額外的平臺(tái)基礎(chǔ)設(shè)施，例如，像Kafka這樣的異步消息日志或像Istio服務(wù)網(wǎng)格這樣的微服務(wù)彈性框架。可以對(duì)具有服務(wù)網(wǎng)格的應(yīng)用程序透明地配置和執(zhí)行諸如重試、斷路和超時(shí)等任務(wù)。因?yàn)槟憧梢詮耐獠靠刂坪团渲眯袨?#xff0c;所以這些行為可以應(yīng)用于任何/所有應(yīng)用程序—無論它們是用什么編程語言編寫的。此外，可以對(duì)這些彈性策略進(jìn)行快速更改，而無需強(qiáng)制代碼更改。

在微服務(wù)體系結(jié)構(gòu)中，幫助進(jìn)行服務(wù)編排的另一個(gè)工具是GraphQL引擎。GraphQL引擎允許團(tuán)隊(duì)跨多個(gè)服務(wù)展開和編排服務(wù)調(diào)用，同時(shí)負(fù)責(zé)身份驗(yàn)證、授權(quán)、緩存和其他訪問機(jī)制。GraphQL還允許團(tuán)隊(duì)更多地關(guān)注特定客戶端或服務(wù)調(diào)用的數(shù)據(jù)元素。GraphQL最初主要用于表示層客戶端(Web、移動(dòng)端等)，但現(xiàn)在也越來越多地用于服務(wù)到服務(wù)的API調(diào)用。

圖4：使用GraphQL引擎編排跨多個(gè)服務(wù)的服務(wù)調(diào)用

如上所述，GraphQL還可以與API 網(wǎng)關(guān)技術(shù)甚至服務(wù)網(wǎng)格技術(shù)相結(jié)合。不管服務(wù)之間使用什么協(xié)議進(jìn)行通信（REST、gRPC、GraphQL等），這些都可以提供一個(gè)通用且一致的彈性策略層。

七、結(jié)論

大多數(shù)團(tuán)隊(duì)都希望通過云基礎(chǔ)設(shè)施和微服務(wù)架構(gòu)來實(shí)現(xiàn)圍繞服務(wù)交付和規(guī)模的重大承諾。我們可以建立CI/CD、容器平臺(tái)和一個(gè)強(qiáng)大的服務(wù)架構(gòu)，但如果我們不考慮運(yùn)行時(shí)微服務(wù)編排和隨之而來的彈性挑戰(zhàn)，那么微服務(wù)實(shí)際上只是一個(gè)過于復(fù)雜的部署架構(gòu)，具有所有的缺點(diǎn)，沒有任何好處。如果你正在使用微服務(wù)的路上（或者已經(jīng)在這條路上走得很好了），請(qǐng)確保服務(wù)通信、編排、安全性和可觀察性被放在首位，并在你的服務(wù)中一致地實(shí)現(xiàn)。

總結(jié)

以上是生活随笔為你收集整理的详解微服务编排的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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