Какая разница между statefull и stateless приложениями?

Всем привет! Пятница - отличный повод почитать что-то полезное)

С семантикой мы разобрались, давайте поговорим еще об одной интересной теме - Stateful / Stateless признаках в приложениях.

В чем же интерес для нас? А вот у Stateless систем есть важное качество - их легко масштабировать горизонтально в отличее и от stateful систем, а это качество очень цениться в высоконагруженных системах.

Stateful приложение хранит данные при работе внутри себя. Что это значит? Например это хранение данных по сессии пользователя внутри рантайма. Ответ на запрос пользователя зависит от состояния сессии, что хранится в конкретном инстансе приложения.

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

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

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

Вот неплохие практики по этому:

1. Каждый запрос должен быть самодостаточным: все что нужно, должно быть в теле запроса и заголовках. Никаких "сервер помнит кто ты".

2. Минимизация in-memory состояния:

2.1 Не хранить пользовательские данные в оперативке между запросами.

2.2 Использовать сериализованные объекты, кэш и БД.

3. При посмтроении АПИ предпочитать идемпотентные операции (повторный вызов того же запроса не должен менять состояние).

4. Не использовать side-affect-free архитектуру. Не связывай запрос с другим логически. Как пример плохого подхода: "Сначала сделай start, потом process, потом end".

5. Храни состояние в клиентах или в токенах. Использовать JWT, в котором зашита необходимая информация о пользователе.

Если есть опыт и можно рассказать свое видение - пишите в комментариях!

Но, все же если уже так произошло и система является stateful, то из можно выделить следующие пункты, которые помогут сделать из Stateful приложение в Stateless:

1. Перенести состояние на клиента. На примере данных пользователя - не хранить сессию, а использовать JWT токен.

2. Использовать внешние хранилища. Хранить все состояния во внешнем источнике (Redis для быстрого доступа и БД для долговременного хранения).

3. Очистка и изоляция - данные, созданные в ходе одного запроса, не должны влиять на другой.

Интересно послушать также ваше мнение в комментариях, жду на обсуждение!

#stateful #stateless