Сеансы в архитектуре Microservice для системы электронной коммерции

Я планирую разработать микросервисную систему электронной коммерции в качестве доказательства концепции. Архитектура состоит из трех компонентов:

одностраничное приложение на основе javascript, которое отправляет запросы AJAX на
сервер (шлюз API) с REST API, который передает данные JSON, полученные путем вызова других служб
3 услуги: CatalogProvider, CustomersProvider, CheckoutProvider

Пока все сервисы являются конечными точками API Magento Shopsystem.

Когда я пытаюсь войти в систему в систему Magento, отправив запрос в REST Api, очевидно, сервер не запоминает сеанс при отправке следующего запроса.

Также я обрабатываю корзину покупок на стороне сервера Magento и добавляю/обновляю/удаляю элементы вызовами REST Api. Здесь также теряются добавленные элементы при отправке следующего запроса по мере потери сеанса.

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

Каковы возможные подходы к решению проблем, связанных с обработкой сеанса в архитектуре микросервиса?

Ответ 1

Я предлагаю вам взглянуть на аутентификацию на токенах.

Кроме того, JSON Web-токены также могут вас заинтересовать.

Ответ 2

Вы можете поддерживать пользовательские состояния в таблице.

При входе пользователей создайте один уникальный идентификатор и сохраните его в таблице с текущей меткой времени и IP-адресом клиента. На стороне клиента создайте пару значений ключа и сохраните ее в файлы cookie. Используйте его как сеанс.

У вас есть много вещей, чтобы проверить существование пользователя.

Ответ 3

если u использует jvoid, который является проектом schgoni (владелец magento), он создает идентификатор сеанса и сохраняет его внутри mysql, и он уже встроил spring модуль безопасности

Для проверки подлинности с помощью микросервиса я бы подумал, что архитектура безопасности на основе oauth2 будет лучше. Думаю, что oauth tokens при отдыхе вызовут проблему с auth

Ответ 4

Как насчет создания еще одного микросервиса - SessionProvider? Служба будет отвечать за создание и сохранение состояний и переменных сеанса, каждый сеанс будет идентифицироваться с помощью уникального идентификатора сеанса, другие службы могут взаимодействовать с SessionProvider через этот идентификатор.