0 前言
part1討論了整合過程中遇到的挑戰以及冪等事件處理的作用。解決整合問題之後，我們需要反思事件檢索的問題。我們的經驗教訓表明，將事件檢索與事件處理解耦至關重要。
1 事件處理與請求/響應 API 緊耦合
part1討論了將請求/響應 API 整合到事件驅動微服務中時，由於基於請求/響應的通訊，導致緊耦合。單個事件的處理速度取決於請求/響應 API 及其響應時間，因為事件處理會阻塞直到收到響應。
像我們在part1中使用的簡單事件迴圈實現或 AWS SQS Java Messaging Library 中的工作示例，會順序處理事件。
不推薦這種方法，因為整體處理時間是所有單個處理時間的總和。
2 併發處理事件
幸運的是，像 Spring Cloud AWS 這種庫提供支援併發處理事件的更高效實現。屬性 ALWAYS_POLL_MAX_MESSAGES 的行為在下圖概述：併發事件處理
檢索到一批事件後，每個事件在一個單獨的執行緒中併發處理。當所有執行緒完成處理後，將檢索下一批事件。由於基於請求/響應的通訊導致的緊耦合，可能使事件處理速度不同。較快的執行緒會在較慢的執行緒處理事件時處於等待狀態。因此，一批事件的處理時間對應於處理最慢的事件的時間。
當事件順序不重要時，併發處理可以是一個合理的預設設定。但根據經驗，某些情況下，事件處理可進一步最佳化。當單個事件的處理時間差異較大時，執行緒可能長時間處於等待狀態。
如整合了一個效能波動較大的請求/響應 API。平均而言，該 API 在 0.5s 後響應。但第 95 百分位和第 99 百分位值經常分別為 1.5s 和超過 10s。在這種併發事件處理方式中，由於響應緩慢的 API，執行緒經常會等待幾s，然後才能處理新事件。
3 將事件檢索與事件處理解耦
即可進一步最佳化事件處理。這樣，處理時間較長的單個事件不會減慢其他事件的處理速度。Spring Cloud AWS 提供了 FIXED_HIGH_THROUGHPUT 屬性，展示了這種解耦可能的實現方式。
具體描述如下。詳細資訊可在文件中找到。
解耦的事件處理策略：
為此，定義一個額外屬性，用於在兩次事件檢索之間的最大等待時間。當所有事件已處理完畢或等待時間已過期時，將檢索新事件。若在等待時間過期後，如一個事件仍未處理完畢，則會提前接收九個新事件，並可以開始處理。這意味著這九個執行緒不會等到最後一個事件處理完畢後才開始工作。
根據經驗，如果等待時間和其他引數配置得當，解耦可提高單個執行緒的利用率。一個可能缺點，由於事件往往以更頻繁但較小批次的方式被檢索，因此可能增加成本。因此，瞭解 API 效能特徵，對於在併發和解耦事件處理之間做出選擇至關重要。
4 結論
當你將事件驅動微服務與請求/響應 API 整合時，會引入緊耦合。請求/響應 API 的效能特徵很重要，因為它們有助於你在併發和解耦事件處理之間做出選擇。
本文重點討論了請求/響應 API 的請求時間效能及其如何影響事件驅動微服務的效能。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
- 大資料開發挖掘經驗
- 推薦系統專案
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！