微服务 API 设计。维护有状态的上下文

Question

想象一下密码恢复过程，包括三个步骤：

1. 发送短信。用户进入电话。发送带有确认码的短信。我们 必须限制用户在一段时间内可以进行多少次 请求。
2. 输入短信代码。用户输入确认码。我们必须 限制尝试次数。
3. 设置新密码。

我们还必须确保这些步骤的正确顺序。这意味着用户不能在前两步未成功的情况下直接跳到第 3 步。

---

假设我们有简单的架构：
网关和登录服务，它实现了三个 API 方法，每个方法对应于每个密码恢复步骤过程。

问题是： 哪个服务必须实施这种有状态的限制？网关还是登录服务？

应该是网关，它将跟踪失败尝试的次数和其他上下文。这使得登录服务无状态。
或者可能是登录服务，所以如果架构发展并且会有另一个网关，则无需在另一个网关中复制相同的代码。

Answer 1

在我看来，状态不应该存储在登录或网关中，这两个服务都必须是无状态的，以便可以横向扩展。此信息必须位于登录服务必须查询的数据存储中。 因为这是一个登录过程，所以与登录相关的所有操作必须由登录服务负责，它需要通过存储（例如，login_status 变量）来跟踪每个用户在整个登录过程中的位置。 通过这种方式，您可以知道特定用户是否正在等待接收 SMS，或将代码输入系统或该用户已尝试的次数。

网关必须完全不知道其背后服务的业务逻辑。它的责任只是成为一个独特的访问点