微服务会话管理

Question

据我所知，微服务架构中的最佳实践是不使用共享数据库/缓存，因此每个微服务都应该有自己的数据库和缓存数据库/机制。但是会议呢？

我发现大多数人都建议使用分布式会话存储，据我了解，分布式会话存储意味着为会话提供共享存储。但这是第一个问题。应该只有 API 网关验证会话还是每个微服务都应该验证会话？换句话说，如果前端发送一些请求，我应该只验证 API 网关中的会话还是 API 网关与之通信的每个微服务中的会话？

此外，我主要在一些会议的 youtube 视频中听说，一些团队使用单独的微服务来管理会议。但我找不到关于这种方法的太多信息。看起来它允许我们不共享会话存储并将其作为微服务架构中的其他存储在一个地方进行管理。但我认为它会减慢应用程序的速度，因为它会增加通信开销。我想听听您对这种方法的看法？

Answer 1

会话

现代应用程序需要是无状态的，以便它们可以扩展。当用户通过身份验证时，他们会获得一个令牌，并且每个请求都会在请求标头中携带该令牌（JWT 令牌）。通常令牌具有与它们关联的到期时间，并且网关可以重定向到任何应用程序实例。令牌携带了他们获得身份验证所需的一切。

验证令牌/会话

您需要在网关上验证会话，这是首选方法。但这真的取决于你的设计。如果您在 api 网关后面有服务并且有任何公共访问权限，那么肯定需要在每个应用程序/服务中验证令牌。如果您的服务是私有的，那么您只能在 Api Gateway 验证令牌并拒绝未经验证的请求。

如果您使用著名的身份提供商（如（auth0、Okta 等）），原生云网关（例如 AWS Api Gatway）无需编写任何额外代码即可验证令牌。如果需要用户声明，那么您可能需要在应用程序中编写逻辑或使用本机库从令牌中获取用户声明。我相信在整个场景中，您不需要任何额外的 Auth 微服务，除非您想编写自己的服务来发布和验证令牌，在我看来这不是一个好主意。