Управление сеансом в микросервисах

У нас есть следующая настройка.

STM (Stingrey Traffic Manager) загружает балансировку + липкость сеанса
Weblogic 'cluster'
Auth, обработанный сторонним инструментом

Поэтому мне не нужно беспокоиться о сеансе относительно горизонтального масштабирования/запуска нескольких экземпляров приложения. Кластер STM/Weblogic гарантирует, что последующий запрос поступит на тот же управляемый сервер.

В настоящее время мы имеем монолитное приложение, и мы пытаемся перейти к микросервисам. Также мы не хотим выходить из существующей инфраструктуры (т.е. STM/Weblogic cluster/Auth tool). Мы запланировали следующее:

Gateway WAR, которая направляет запросы другим микросервисам
N x Микросервисы (WAR) для каждого функционального поддомена
Только шлюз API получает запросы пользователей, а другие микросервисы недоступны извне

Итак, мой вопрос:

Должен ли API-шлюз быть полностью заполнен, а другие микросети без апатрида?
Если да, то каким образом данные сеанса пользователя должны быть совместно использованы между шлюзом API и микросервисами?

Просьба предложить любые лучшие альтернативы и ресурсы/ссылки. Спасибо.

Ответ 1

Позвольте мне поделиться своим мнением.

Прежде всего, если вы можете сохранить свое приложение без сохранения состояния, сделайте это во что бы то ни стало :) Это будет лучшим решением с точки зрения как производительности, так и масштабируемости.

Теперь, если это невозможно, вам следует поддерживать некоторый распределенный уровень управления сеансами.

Шлюз, отвечающий за аутентификацию, может генерировать некоторый уникальный идентификатор сеанса, который впоследствии можно будет использовать в качестве ключа. Этот ключ может распространяться на все микросервисы и быть частью API или чего-то еще.

Чтобы получить доступ к сеансу, микросервис мог "получить" значение по ключу и работать с ним.

С точки зрения реализации: я бы взглянул на решения NoSQL. Вот некоторые из них, которые могут удовлетворить ваши потребности:

Redis. Посмотрите на '' Hset '' там
Hazelcast. Это скорее сетка в памяти, но если решение только на Java, вы также можете реализовать необходимые функции
Memcache.d. Это даст вам старую хорошую карту, только что распространенную :)

Есть и другие решения, которым я верю.

Теперь производительность имеет решающее значение, иначе все решение будет слишком медленным. Таким образом, в моем понимании, использование СУБД здесь было бы нехорошо, более того, потенциально было бы сложнее его масштабировать.

Надеюсь это поможет

Ответ 2

1) Должен ли API-шлюз быть заполненным, а другие микросервисы - без состояния?

Да, как и в руководствах 12 Factor App, все службы должны быть без гражданства.

2) Если это так, каким образом следует передавать данные сеанса пользователя между API-шлюзом и микросервисами?

Ваш API должен быть без сохранения состояния, поэтому не делитесь сеансом с микросервисами. Что вы можете сделать, так это иметь другую службу, поддерживаемую базами данных NoSQL для хранения пользовательского сеанса.