Session Management in microservices
We have the following setup.
- STM (Stingrey Traffic Manager) does load balancing + session stickiness
- Weblogic 'cluster'
- Auth handled by a third party tool
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.
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:
- A Gateway WAR which routes requests to other microservices
- N x Microservices (WAR) for each functional sub-domain
- Only the API Gateway receives user requests and other microservices are not accessible from outside
So my question is
- Should API Gateway be state-full while other microsevices are stateless?
- If so, how should the user session data be shared between API Gateway and microservices?
Please suggest any better alternatives and resources/links as well. Thanks.
Answer
Let me share my opinion.
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.
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.
In terms of implementation: I would take a look on NoSQL solutions. Some of them that can suit your need are:
- Redis. Take a look on ''hset'' there
- Hazelcast. Its more a in-memory grid but if the solution is java only, you can also implement the required functionality
- Memcache.d. It will give you an old good map, just distributed :)
There are also other solutions I believe.
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.
Hope this helps