Microservices API设计。保持有状态的上下文

Question

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

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

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

---

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

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

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

Answer 1

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

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