Где управлять сессией в архитектуре микросервисов с помощью Spring Boot

Question

Я довольно новый в архитектуре микросервисов.Я пытался создать стек микросервисов с использованием библиотек Spring Boot, Spring Cloud и Netflix OSS.Я хочу знать, как правильно и где хранить сеанс.

Вот обзор инфраструктуры, которую я создал:

1. Сервер авторизации / аутентификации с поддержкой OAuth2
2. Служба пользовательского интерфейса (Spring Boot, Front end service)
3. Backend Service-1
4. Backend Service-2
5. Redis Server для хранения сеанса и других кэшируемых данных
6. Discovery Server (eureka)

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

Вот мой конфигурационный файл сеанса в службе пользовательского интерфейса (интерфейсная служба)

@Configuration
@EnableRedisHttpSession
public class SessionConfig extends 
AbstractHttpSessionApplicationInitializer {

    public SessionConfig() {
        super(RedisConfig.class);
    }
}

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

Answer 1

Вы можете управлять им, используя HttpSession, когда вы используете конечные точки REST, вы можете перейти по этой ссылке для получения дополнительной информации: https://docs.spring.io/spring-session/docs/current/reference/html5/guides/java-rest.html

Answer 2

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

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

А что касается вопроса об использовании Redis или нет - В архитектуре микросервисов выбор системы хранения будет зависеть от сервисного архитектора. Может быть, одна служба хранит свои данные в реляционной базе данных, а другая использует хранилище значений ключей, а другая может использовать систему очередей событий или базу данных временных рядов.

Итак, в итоге вы должны спросить себя, для чего на самом деле используется ваша сессия, и возложить на соответствующие службы ответственность за сохранение этой информации специфичным для домена способом. (Если вы дадите более подробную информацию в своем вопросе об этом, я могу высказать вам свое мнение).