微服務架構——如何從API網關獲取用戶信息到微服務

Question

我計划使用 API 網關設置一組微服務，我是微服務架構的新手，但我計划添加更多服務並保持此應用程序的高度可擴展性。 API 網關應管理用戶及其權限，並將傳入請求委托給底層微服務。 但我的問題是，如何在網關處的用戶與微服務中的實體之間建立關系。

就像上圖一樣，我需要弄清楚在底層服務中處理用戶關系的最佳實踐是什么。 我想用 laravel 實現所有服務，網關應該使用 laravel\passport。

我的想法是 API 網關負責對用戶進行身份驗證並將請求轉發到網關后面的服務。 如果用戶通過了身份驗證，他就可以通過網關訪問服務。 但是我如何向服務提供有關用戶的信息，例如，如果用戶在服務 A 中編輯了一個項目，我如何存儲哪個用戶編輯了該項目。 建立這種關系的方法是什么？

Answer 1

選擇方法時需要考慮很多方面，因此基本上回答您的問題主要是為您提供可以深入研究的指導。

以下是您應該查看的一些方法，它們在很大程度上取決於您的服務：

• 整個平台的身份驗證/授權方法
• 每個單獨的服務如何相互通信（同步 REST 呼叫、消息、GraphQL、GRPC，...）
• 個人服務是如何安全的（每個服務都是公共的並且進行身份驗證，每個服務都在一個安全的網絡后面，只有網關是公共的，服務網格負責身份驗證，......）

基於 REST 的微服務中最常見的身份驗證方法是OAuth ，具有 JWT 個令牌。 我建議你深入研究一下。

（現在離題一點，以證明這取決於用例和架構的變化有多大）

采取 OAuth 並查看您的問題，您將根據用例使用 OAuth 中的不同流程。 例如，為用戶生成令牌將不同於為服務生成令牌。

然后您仍然需要決定在每個服務中使用哪個令牌：網關后面的服務是接受用戶令牌，還是只接受服務到服務令牌？ 這對您需要評估的架構有影響。 使用用戶令牌時，您可以在令牌中對用戶 ID 進行編碼，然后從那里提取它。 但是，如果您在任何地方都使用用戶令牌，那么它會假定服務僅作為用戶流的一部分相互通信，並且您將通過使用用戶令牌來強制執行此操作。 如果您 go 使用服務到服務令牌（我認為是一種更常見的方法），則需要以其他方式傳遞用戶 ID（同樣，這取決於您選擇的體系結構）。 想到REST，可以使用Headers，Request Params，Request Path，Request Body。 您需要根據每個服務的業務領域評估每個服務的權衡，這會影響 API 設計。

如果您根本不使用令牌，因為您的所有服務都在一個安全網絡中，那么您仍然必須使用協議的某些方面來傳遞用戶 ID（標頭、參數等...）