譯者 | 涂承燁

審校 | 孫淑娟

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

微服務體系結構強調獨立性和頻繁更改的能力，但這些服務通常需要共享數據，并在它們之間發起復雜的交互，以完成它們的功能。在本文中，我們將研究微服務通信的模式和策略。

一、網絡中的問題

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

圖1：服務A調用服務B的簡單示例

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

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

圖2：調用多個服務的更復雜的示例

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

也許我們可以回退到一個預定義的響應，重試請求，根據服務B響應的一些數據從緩存中提取數據，或者調用一個不同的服務？

網絡中導致連接或請求失敗的問題可能會間歇性地發生，應用程序必須處理這些問題。

隨著從給定服務編排的服務調用越多，這些問題就越有可能發生，也越復雜，如圖3所示。

圖3：嘗試編排跨讀/寫API的多個服務調用示例

當這些服務間的調用不僅僅是“讀”調用時，這些問題將變得更加麻煩。

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

這可能會導致不同服務之間的數據不一致和狀態不一致。

這樣的網絡錯誤會影響微服務的彈性、數據一致性以及可能的服務級別目標(SLOs)和服務級別協議(SLAs)。

我們需要一種方法來處理這些網絡問題，同時考慮在嘗試解釋故障時突然出現的其他問題。

二、有用的網絡彈性模式

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

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

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

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

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

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

三、具有回退處理的重試

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

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

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

四、冪等請求處理

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

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

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

五、異步請求處理

對于前面示例中的服務交互，我們已經假設了某種類型的請求/響應交互，但是我們可以通過依賴某種隊列或日志機制來在傳遞中持久化消息并將其交付給使用者，從而減輕網絡的一些麻煩。在這個模型中，我們去掉了請求的發送方和接收方在同一時間同時可用的可能性。

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

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

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

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

圖4：使用GraphQL引擎編排跨多個服務的服務調用

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

七、結論

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

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

譯者介紹：

涂承燁，51CTO社區編輯，信息系統項目管理師、信息系統監理師、PMP，某省綜合性評標專家，擁有15年的開發經驗。目前就職于壹體技術有限公司，從事較大型項目管理工作。