Весенняя сессия ленивой десериализации

Question

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

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

проблема сейчас заключается в том, что когда сервис записывает объект класса, который другие сервисы не делаютв их classpath выдается исключение десериализации.

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

Знаете ли вы, возможно ли это вообще с весенней сессией, или, может быть, можете предложить другое решение, которое позволило бы мне решить начальную проблему?

вот пример проекта для воспроизведения моей проблемы: https://github.com/deathcoder/hazelcast-shared-session

Answer 1

Во-первых, я бы старался избегать сессий на уровне API.Они плохо масштабируются.А синхронизация сеансов еще менее масштабируема.

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

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

Answer 2

Мне кажется, я понял, что происходит: Spring-Session-Hazelcast по умолчанию хранит сессию локально до тех пор, пока запрос не будет завершен, а когда запрос завершен, перед возвратом ответа отправьте все в кластер, используя EntryProcessor.EntryProcessor требует, чтобы классы объектов были доступны для члена, который хранит эту запись сеанса, и, поскольку данные распределены, возможно, что другой член хранит сеанс, созданный в другом экземпляре.Согласно тому, что вы говорите, не все узлы идентичны, не содержат все классы, и это вызывает исключение сериализации.

Что вы можете сделать, вы можете использовать функцию User Code Deployment для развертывания этих отсутствующих классов вдругие члены: https://docs.hazelcast.org/docs/3.11/manual/html-single/index.html#member-user-code-deployment-beta

Если вы меняете объект, сохраняемый в сеансе, вы можете установить class-cache-mode на OFF, чтобы не кэшировать их, а отправлять с каждой операцией.

Пожалуйста, попробуйте и дайте мне знать, если это решит вашу проблему.