Я планирую разработать микросервисную систему электронной коммерции в качестве доказательства концепции. Архитектура состоит из 3 компонентов:
одностраничное приложение на основе JavaScript, которое отправляет AJAX-запросы
сервер (API Gateway) с REST API, который передает данные JSON, полученные при вызове других служб
3 услуги: КаталогПоставщик, ЗаказчикиПровайдер, Оформление заказаПровайдер
На данный момент все сервисы являются конечными точками API Magento Shopsystem.
Когда я пытаюсь войти в систему в системе Magento, отправив запрос в REST Api, сервер, очевидно, не запоминает сеанс при отправке следующего запроса.
Также я обрабатываю корзину на стороне сервера с помощью Magento и добавляю / обновляю / удаляю товары по вызовам REST Api. Здесь также добавленные элементы теряются при отправке следующего запроса, поскольку сеанс теряется.
Итак, мой вопрос:
Каковы возможные подходы к решению проблем, связанных с обработкой сеансов в микросервисной архитектуре?
Я предлагаю вам взглянуть на аутентификацию на основе токенов.
Кроме того, токены JSON Web также могут вас заинтересовать.
Вы можете поддерживать пользовательские состояния в таблице.
Когда пользователи входят в систему, создают один уникальный идентификатор и сохраняют его в таблице с текущей отметкой времени и IP-адресом клиента. На стороне клиента создайте пару ключ-значение и сохраните ее в файлах cookie. Используйте это как сессию.
У вас есть много вещей, чтобы проверить существование пользователя.
если вы используете jvoid, который является проектом schgoni (владельца magento), он создает идентификатор сеанса и сохраняет его в mysql, и он уже имеет встроенный модуль безопасности Spring
Думаю, для микросервисной аутентификации лучше будет использовать архитектуру безопасности на основе oauth2. Использование маркеров oauth при вызовах в состоянии покоя решит проблему с аутентификацией
А как насчет создания еще одного микросервиса — SessionProvider?
Служба будет отвечать за создание и сохранение состояний и переменных сеанса, каждый сеанс будет идентифицироваться уникальным идентификатором сеанса, другие службы могут взаимодействовать с SessionProvider через этот идентификатор.