微服務 API 設計。 維護有狀態的上下文

Question

想象一下密碼恢復過程，它包括三個步驟：

1. 發簡訊。 用戶輸入電話。 發送帶有確認碼的短信。 我們必須限制用戶在一段時間內可以發出此請求的次數。
2. 輸入短信代碼。 用戶輸入確認碼。 我們必須限制嘗試的次數。
3. 設置新密碼。

此外，我們必須確保這些步驟的正確順序。 這意味着用戶不能在前兩步不成功的情況下直接跳到第 3 步。

---

假設我們有簡單的架構：
網關和登錄服務實現了三個 API 方法，每個方法對應於每個密碼恢復步驟過程。

問題是：哪個服務必須實現這種有狀態的限制？ 網關或登錄服務？

應該是網關來跟蹤失敗的嘗試次數和其他上下文。 這使得登錄服務無狀態。
或者可能是登錄服務，所以如果架構發展並且會有另一個網關，則無需在另一個網關中復制相同的代碼。

Answer 1

在我看來，狀態不應該存儲在登錄名和網關中，這兩個服務都必須是無狀態的，以便它們可以擴展。 此信息必須位於登錄服務必須查詢的數據存儲中。 因為這是一個登錄過程，負責與登錄相關的所有操作的必須是登錄服務，它需要通過存儲例如 login_status 變量來跟蹤每個用戶在整個登錄過程中的位置。 通過這種方式，您可以知道特定用戶是否正在等待接收 SMS，或正在等待將代碼輸入系統或該用戶已進行的嘗試次數。

相反，網關必須完全不知道其背后服務的業務邏輯。 它的責任只是成為一個獨特的訪問點