service - 系统架构建议

Question

我有一些关于系统架构的问题。我正在建立一个票务系统。基本上，它是在创建支持票。

我想弄清楚我是否以正确的方式使用了这些组件。

关于第一种情况:

客户端请求创建一个新票，网关将请求转发给票务服务，票务服务想要检查 token 是否有效，所以通过带有 token 的 nats 抛出一个发布，如果 token 有效，则身份验证服务注册 token 和信息将键值对连接到 Redis 一段时间让我们说 30 分钟。并将结果发布给 nats。 Nats 将结果重定向到票务服务。如果一切正常，票务服务会在数据库中创建一条记录。

第二种情况senorio是:

用户再次执行上述所有步骤，但是，身份验证端不是请求身份验证服务，而是从 Redis 获取信息(如果存在)并再次执行相同的步骤。

这是我的问题，

您认为 Redis 的用途是否正确？还是我应该删除它并在请求进行身份验证时一遍又一遍地询问？

您认为我应该在 Gateway 上进行所有身份验证吗？

所以看起来这与上述问题有关。

关于初始登录和请求。 (第一种情况)

登录后，(第二种情况)

非常感谢您的建议、批评和意见。

提前致谢。

Answer 1

更合适的方法是从 API 网关进行身份验证，即。 API 网关使用身份验证服务进行身份验证，如您在建议的两个解决方案的第二个选项中所述。

API 网关应证明是您所有请求的“网关”，并过滤任何未经身份验证或未授权访问您的服务的请求。在这种情况下，身份验证和授权可以是它们自己的服务，API 网关将使用它们来确定请求是否可以访问任何其他下游服务。除此之外，它还通过删除 NATS 消除了复杂性。少一个需要操作和管理的组件总是成功的。

我要做的一个细微修改是，在第二步，我会让身份验证服务检查 Redis，而不是 API 网关直接连接到 Redis。也就是说，鉴权服务会先到Redis，再到数据库。这样，就会有更多的解耦。

API 网关不需要知道身份验证服务如何在 Redis 中存储 token 的 key 。因此，如果您决定更改 key 在身份验证服务中的方式，则无需针对 API 网关中从 Redis 读取 key 的方式有效地部署新更改。