譯者 | 涂承燁

審校 | 孫淑娟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

冪等請求處理-對一個請求進行多次處理并得到相同結(jié)果的能力（可能涉及對寫操作的重復刪除處理）。

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

讓我們來仔細看看這些模式。

三、具有回退處理的重試

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

有了回退機制，我們可以錯開調(diào)用失敗和重試所花費的時間。

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

四、冪等請求處理

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

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

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

五、異步請求處理

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

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

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

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

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

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

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

七、結(jié)論

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

原文鏈接：https://dzone.com/articles/microservices-orchestration

譯者介紹：

涂承燁，51CTO社區(qū)編輯，信息系統(tǒng)項目管理師、信息系統(tǒng)監(jiān)理師、PMP，某省綜合性評標專家，擁有15年的開發(fā)經(jīng)驗。目前就職于壹體技術(shù)有限公司，從事較大型項目管理工作。