微服务中的会话管理

Question

我们有以下设置。

1. STM（Stingrey Traffic Manager）负载平衡+会话粘性
2. Weblogic'cluster'
3. 由第三方工具处理的身份验证

因此，我不必担心有关水平扩展/运行应用程序的多个实例的会话。 STM / Weblogic集群确保后续请求来到同一个受管服务器。

我们目前拥有的是单片应用程序，我们正在努力转向微服务。此外，我们不想离开当前的基础设施（即STM / Weblogic集群/ Auth工具）。我们计划的是：

1. 将请求路由到其他微服务的网关WAR
2. 每个功能子域的N x微服务（WAR）
3. 只有API网关接收用户请求，并且无法从外部访问其他微服务

所以我的问题是

1. API Gateway应该是状态满的，而其他微服务是无状态的吗？
2. 如果是这样，应该如何在API网关和微服务之间共享用户会话数据？

请建议任何更好的替代方案和资源/链接。感谢。

Answer 1

让我分享一下我的观点。

首先，如果您可以保持您的应用程序无状态，请务必这样做:) 在性能和可扩展性方面，它将是最佳解决方案。

现在，如果它不可能，那么你应该维护一些分布式会话管理层。

负责身份验证的网关可以生成一些唯一的会话标识符，以后可以将其用作密钥。 此密钥可以传播到所有微服务，并成为API的一部分。

为了访问会话，微服务可以通过密钥“获取”值并使用它。

在实施方面：我会看看NoSQL解决方案。其中一些可以满足您需求的是：

1. Redis。看看''hset''那里
2. Hazelcast。它更像是一个内存网格，但如果解决方案只是java，你也可以实现所需的功能
3. Memcache.d。它将为您提供一张旧的好地图，只需分发：）

我相信还有其他解决方案。

现在，性能至关重要，否则整个解决方案将会太慢。所以在我的理解中，使用RDBMS在这里并不好，而且可能更难以扩展它。

希望这有帮助

Answer 2

1）API网关应该是全状态的，而其他微服务是无状态的吗？

是的，与12 Factor App guide lines中一样，所有服务都应该是无状态的。您可以通过维护服务之间的共享会话存储（例如Redis，具有时间到期）来使网关变为有状态。

2）如果是，如何在API网关和微服务之间共享用户会话数据？

会话仍然是端到端微服务架构中维护安全性的最佳方法。您可以拥有共享的会话存储空间，并且可以通过cookie通过网关来访问会话。反向代理服务器（例如Nginx）可用于将Cookie传递到子域。