微服务API设计。保持状态状态

Question

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

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

我们还必须确保此步骤的正确顺序。意味着如果没有成功完成前两个步骤，用户将无法直接跳至步骤3。

---

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

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

应该是网关，它将跟踪失败的尝试次数和其他上下文。使得登录服务变为无状态。
也许是登录服务，所以如果体系结构不断发展并且将有另一个网关，则无需在另一个网关中重复相同的代码。

Answer 1

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

网关必须完全不了解其背后的服务的业务逻辑。它的责任只是成为唯一的访问点