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

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

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

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

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

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

@Configuration
@EnableRedisHttpSession
public class SessionConfig extends 
AbstractHttpSessionApplicationInitializer {

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

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


person eray    schedule 17.01.2019    source источник


Ответы (1)


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

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

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

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

person Oswin Noetzelmann    schedule 17.01.2019
comment
Спасибо за подробный ответ. Короче говоря, я пытаюсь сохранить сеанс HTTP в Redis, который по умолчанию хранится на сервере. Часть, которую я теряю в своем примере проекта, заключается в том, что я не вижу смысла в совместном использовании сеанса пользователя и токена OAuth, поскольку все они служат одной и той же цели, когда речь идет о получении информации о пользователе. Пожалуйста, поправьте меня, если я ошибаюсь. Или, может быть, мне следует хранить токены и пользовательские данные в Redis вместо того, чтобы пытаться внедрить Http Session непосредственно в него. - person eray; 18.01.2019
comment
Да, вы уже на правильном пути. Токены JWT должны заменять сеансы на стороне сервера в большинстве случаев использования. Особенно, если вы мудро выбрали содержащиеся данные. Возможно, вам придется сделать несколько вещей иначе, чем с сеансами. Например, добавьте некоторые данные в ваше пользовательское постоянство, например дату последнего сброса PW, чтобы иметь возможность аннулировать ранее действительные токены и т. д. - person Oswin Noetzelmann; 18.01.2019
comment
Это проясняет ситуацию. Я определю и укажу вещи, которые необходимо кэшировать/хранить в токене, и создам надлежащий дизайн системы. Большое спасибо за ваш ответ и полезные рекомендации. - person eray; 18.01.2019
comment
Также проверьте следующее, чтобы подумать об ограничениях и т. д.: токен полностью заменяет сеанс"> stackoverflow.com/questions/34280049/ - person Oswin Noetzelmann; 18.01.2019