27
votes

We have the following setup.

  1. STM (Stingrey Traffic Manager) does load balancing + session stickiness
  2. Weblogic 'cluster'
  3. 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:

  1. A Gateway WAR which routes requests to other microservices
  2. N x Microservices (WAR) for each functional sub-domain
  3. Only the API Gateway receives user requests and other microservices are not accessible from outside

So my question is

  1. Should API Gateway be state-full while other microsevices are stateless?
  2. 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.

2
Are you using a distributed cache? This is how I currently manage a similar scenario. Authentication tokens into cache - of course you need unique IDs for cache entries that any microservice that needs to go to cache knows about.jacks
Thanks @Nio. I'm not using a distributed cache, but can consider. How do you generate auth tokens? Do you need an OAuth server in place? Also what is the distributed cache you are using? Please share links for my reference if you have any.Fahim Farook
Fahim, I use both memcached and Redis for caching. If you are not sure which, I would go with Redis. There are quite a few ways of managing Auth tokens. OAuth is one of the standardised ways and although it has a bit of a learning curve to get your head around Grant flows it is a worthwhile thing to have on your CV. There are loads of examples of implementing an OAuth server in Java google.co.uk/…jacks

2 Answers

32
votes

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:

  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.

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

7
votes

1)Should API Gateway be state-full while other microservices are stateless?

Yes, As in 12 Factor App guide lines all the services should be stateless.

2)If so, how should the user session data be shared between API Gateway and microservices?

Your API should be stateless therefore do not share the session state to the microservices. The recommended approach is to set up a Redis cache to store session data.

enter image description here