微服务中的会话管理 [英] Session Management in microservices

问题描述

我们有以下设置.

1. STM(Stingrey Traffic Manager)可以实现负载平衡+会话粘性
2. Weblogic的集群"
3. 由第三方工具处理的身份验证

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

Therefore I do not have to worry about session with regards to horizontal scaling/ running multiple instances of the application. STM/ Weblogic cluster makes sure that the subsequent request come to same managed server.

我们目前拥有的是一个整体应用程序，我们正在尝试转向微服务.另外，我们也不会退出当前的基础架构(即STM/Weblogic集群/Auth工具).我们计划的是:

What we currently have is a monolithic application and we are trying to move to microservices. Also we do not wan't to move out of current infrastructure (i.e. STM/ Weblogic cluster/ Auth tool). What we have planned is:

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

所以我的问题是

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

请提出任何更好的替代方案以及资源/链接.谢谢.

Please suggest any better alternatives and resources/links as well. Thanks.

推荐答案

让我分享我的看法.

首先，如果您可以使应用程序保持无状态，请务必:) 就性能和可伸缩性而言，它将是最佳的解决方案.

First of all, if you can keep your application stateless, by all means do so :) It will be the best solution in terms of both performance and scalability.

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

Now, if its impossible, then you should maintain some distributed session management layer.

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

The gateway responsible for authentication could generate some unique session identifier which could later be used as a key. This key could be propagated to all the microservices and be a part of the API or something.

为了访问会话，微服务可以通过键获取"值并使用它.

In order to access the session, the microservice could 'get' value by key and work with it.

在实现方面:我将介绍NoSQL解决方案.其中一些可以满足您的需求:

In terms of implementation: I would take a look on NoSQL solutions. Some of them that can suit your need are:

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

1. Redis. Take a look on ''hset'' there
2. Hazelcast. Its more a in-memory grid but if the solution is java only, you can also implement the required functionality
3. Memcache.d. It will give you an old good map, just distributed :)

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

There are also other solutions I believe.

现在，性能在这里至关重要，否则整个解决方案将太慢.因此，以我的理解，在这里使用RDBMS并不是一件好事，而且可能很难扩展.

Now, the performance is crucial here, otherwise the whole solution will be just too slow. So In my understanding, using an RDBMS would be not be good here, moreover potentially it would be harder to scale it out.

希望这会有所帮助

这篇关于微服务中的会话管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！