在本文中，我們將看到如何使用Spring WebFlux構建響應式REST API。 在進入反應式API之前，讓我們看看系統是如何發展的，傳統REST實現遇到的問題以及現代API的需求。

如果您查看從舊版系統到下文所述的現代系統的期望，

現代系統的期望是，應用程序應該是分布式的，云原生的，擁抱高可用性和可伸縮性。 因此，有效利用系統資源至關重要。 進入為什么要使用響應式編程來構建REST API？ 讓我們看看傳統的REST API請求處理是如何工作的。

以下是傳統REST API遇到的問題，

• 阻止和同步→請求正在阻止和同步。 請求線程將等待任何阻塞的I / O，并且直到I / O等待結束后，線程才可以釋放以將響應返回給調用方。
• 每個請求的線程 → Web容器使用每個請求模型的線程。 這限制了要處理的并發請求的數量。 除了某些請求之外，容器還會對請求進行排隊，這些請求最終會影響API的性能。
• 處理高并發用戶的限制 →由于Web容器按請求模型使用線程，因此我們無法處理高并發請求。
• 無法更好地利用系統資源 →線程將因I / O而阻塞并處于空閑狀態。 但是，Web容器不能接受更多請求。 在這種情況下，我們將無法有效地利用系統資源。
• 沒有反壓支持→我們無法從客戶端或服務器施加反壓。 如果請求突然激增，則可能導致服務器或客戶端中斷。 之后，用戶將無法訪問該應用程序。 如果我們有背壓支持，則應用程序應在重負載期間持續運行，而不是無法使用。

讓我們看看如何使用反應式編程解決上述問題。 以下是我們使用反應式API所獲得的優勢。

• 異步和非阻塞→反應式編程為編寫異步和非阻塞應用程序提供了靈活性。
• 驅動事件/消息 →系統將為任何活動生成事件或消息。 例如，來自數據庫的數據被視為事件流。
• 支持背壓 →我們可以通過施加背壓來優雅地處理從一個系統到另一個系統的壓力，從而避免拒絕服務。
• 可預測的應用程序響應時間→由于線程是異步且非阻塞的，因此在負載下應用程序響應時間是可預測的。
• 更好地利用系統資源 →由于線程是異步且非阻塞的，因此不會為I / O 占用線程。 使用更少的線程，我們可以支持更多的用戶請求。
• 根據負載縮放
• 遠離每個請求的線程 →借助反應式API，我們正在遠離每個請求的線程模型，因為線程是異步且非阻塞的。 發出請求后，它將與服務器一起創建事件，并且請求線程將被釋放以處理其他請求。

現在讓我們看看反應式編程是如何工作的。 在下面的示例中，一旦應用程序調用了從數據源獲取數據的操作，線程將立即返回，并且來自數據源的數據將作為數據/事件流出現。 在這里，應用程序是訂閱者，數據源是發布者。 數據流完成后，將觸發onComplete事件。

下面是另一種情況，如果發生任何異常，發布者將觸發onError事件。

在某些情況下，可能沒有任何要從發布者交付的項目。 例如，從數據庫中刪除一個項目。 在這種情況下，發布者將立即觸發onComplete / onError事件，而無需調用onNext事件，因為沒有數據可返回。

現在，讓我們看看什么是背壓？ 以及我們如何對反應流施加背壓？ 例如，我們有一個客戶端應用程序正在從另一個服務請求數據。 該服務能夠以1000TPS的速率發布事件，但是客戶端應用程序能夠以200TPS的速率處理事件。 在這種情況下，客戶端應用程序應緩沖其余數據以進行處理。 在隨后的調用中，客戶端應用程序可能會緩沖更多數據，并最終耗盡內存。 這會對依賴于客戶端應用程序的其他應用程序造成級聯效應。 為了避免這種情況，客戶端應用程序可以要求服務在事件末尾緩沖事件，并以客戶端應用程序的速率推送事件。 這稱為背壓。 下圖描述了相同的內容。

在接下來的文章中，我們將看到反應式流規范及其實現Project Reactor之一，其中包含一些示例應用程序。 到那時， 快樂學習！！

翻譯自: https://www.javacodegeeks.com/2020/05/build-reactive-rest-apis-with-spring-webflux-part1.html

總結

以上是生活随笔為你收集整理的使用Spring WebFlux构建反应性REST API –第1部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。