簡體   English   中英

Spring Boot - Zuul - 微服務 - 優化對網關的 API 調用以獲取用戶詳細信息

[英]Spring Boot - Zuul - Microservice - optimise API calls made to gateway to fetch user details

我正在以 Zuul 作為網關在 Spring-Boot 中實現微服務架構。 我有一個具有身份驗證和授權邏輯的 zuul 網關服務。 此外,它還公開了 API,可響應用戶詳細信息,如用戶 ID 用戶名映射、當前登錄用戶等。因此,我的其他服務通過 API 調用網關獲取任何用戶信息。 我已標記 zuul.sensitiveHeaders=Cookie,Set-Cookie 以允許將承載令牌傳遞給非網關微服務。

問題陳述 - 在我的其他服務中,我只是在需要的地方存儲用戶 ID。 然后,在向前端返回數據時,我對網關服務進行 API 調用以獲取用戶 ID 的用戶名。 當我修改單個數據時,這很好用。

但是,當我必須返回批量數據(比如 1000 條記錄)時,我將進行 1000 次 API 調用以根據每條記錄的用戶 ID 獲取用戶名。 這會影響速度。

例子 - 在此處輸入圖片說明

為了在 UI 上顯示以上數據,我對網關進行了 8 次 API 調用,以獲取每個用戶 ID(created_by)的用戶名。

有人可以幫我解決在這種情況下應該使用的架構嗎? 我想到的一些解決方案如下。 但是我不太確定這些是否是最好的

  1. 登錄后獲取 userid-username 映射的 hashmap 並存儲在會話緩存中。 但這會減慢登錄調用
  2. 添加OncePerPrequestFilter 以便在每次API 調用時,將獲取userid-username 映射的hashmap 並將其傳遞給控制器​​。 這是可行的,但在不需要此映射的 API 中,仍然會進行 API 調用,這將導致過載。

歡迎任何其他建議。

不太清楚您要做什么 - 問題標題似乎與描述沒有太大關系。 盡管如此,您似乎對這個問題有兩個不同的方面:

  1. 在您的后端,您需要通過服務中使用的令牌(通過您的網關)傳遞用戶信息。
  2. 在您的前端,您需要該信息的一些(最小?)子集用於顯示目的(我說的是顯示,但通常此信息將用於其他一些過程 - 例如“向該用戶發送電子郵件”)。

此外,您提到:

但是,當我必須返回批量數據(比如 1000 條記錄)時,我將進行 1000 次 API 調用以根據每條記錄的用戶 ID 獲取用戶名。 這會影響速度。

您希望如何處理這種情況取決於您想要做什么以及您希望如何表示您的請求和結果。

簡而言之,您需要在此特定請求背后的實際用例以及系統中將發生的請求的性質背后向我們提供更多詳細信息。 例如,您真的需要每個單獨的用戶嗎? 您是否可能需要系統中所有活動/非活動/用戶的列表? 在后一種情況下,查詢讀取優化模型就足夠了,該模型在創建新用戶時更新。 在這種情況下,響應不僅會很快,而且您可以輕松添加分頁和排序等不錯的功能,因為您可能已經為基於集合的響應提供了此類功能。

您的后端服務仍然可以僅根據令牌信息填充安全上下文:用戶在系統中的角色是什么,提供的范圍等。對於更改系統狀態,您仍然(在過程中的某個時刻)檢查當前系統狀態,例如通過數據庫調用。

如果您只需要顯示當前登錄用戶的一小部分詳細信息(很少更改),並且此數據不是高度機密的,您可以考慮將其添加為不記名令牌中的自定義Claim 例如,如果您使用 JWT 作為不記名令牌,則可以輕松解碼令牌並讀取信息。

所以,這取決於你到底想做什么。 您是否真的需要為 1 個字段同時查詢 >1,000 個個人用戶? 也許我誤解了這個問題,但在我看來,您想要關於系統中大量實體(在這種情況下 - 用戶)的非常具體的信息子集,以及讀取優化模型(甚至是數據庫)具有足夠權限的用戶直接查詢的視圖)將完成這項工作。

Zuul說一句,自Greenwich發布系列以來,Spring Cloud Zuul一直處於維護模式,截至 2019 年 1 月 22 日。您應該考慮升級到Spring Cloud Gateway ,它取代了它並提供(在許多其他改進中)一個非阻塞請求模型(與Zuul阻塞模型相反)。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM