Stateful и Stateless приложения

Начало

Моя попытка описать состояние.

Все написанное ниже является мнением автора, что не является истинной в последней инстанции, примите это к сведенью.

Когда мы делаем запрос на сервер например из браузера, он (запрос) может поменять что-то на сервере или получить что-то с сервера.

Любой объект в веб сервисе в определенный момент времени может находиться в определенном состоянии.

Здесь мы подходим к понятию состояние - state.

Например, отправляем запрос на сервер для вычисления суммы, такой https://test.com/plus?r=3+3. В результате вернем результат 6. Сколько бы мы не выполняли данный запрос, мы всегда будем получать 6, то есть мы не зависим от предыдущих запросов нами или другими пользователями.

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

Это называется Stateless архитектура.

Stateless

Stateless — архитектура приложения, когда каждый запрос рассматриваться как изолированное действие, то есть каждый запрос является автономным не зависящим от предыдущих запросов.

Преимущества stateless

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

Недостатки stateless

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

Примеры

• RESTful сервис
• HTTP протокол

В противовес stateless есть и stateful подход, когда приложение как раз запоминает данные и хранит состояние.

Stateful

Stateful - архитектура таких приложение подразумевает сохранение информации о предыдущих состояниях между запросами.

Преимущества stateful

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

Недостатки stateful

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

Примеры

• Классический веб сайт, который хранит сессию пользователя на сервере.
• TCP протокол

Взаимодействие с сервисом

Если абстрагироваться от реализации сервиса, можно выделить несколько типов запросов:

• Запрос, которому вообще не нужно состояние для получения ответа, например https://test.com/plus?r=3+3, сервис просто посчитает и вернет результат 6.
• Запрос, которому нужно состояние для получения ответа, но он на него не влияет, например погода в Москве https://test.com/weather?town=Moscow, сами на погоду мы повлиять не можем, а можем получить только результат.
• Запрос, который влияет на состояние системы, например https://test.com/set?r=10, установили значение параметра r, можем выполнять этот запрос сколько угодно раз, результат будет всегда одинаковый - это последний выполненный запрос.
• Запрос, который влияет на состояние системы и влияет на другие части системы, например регистрация пользователя https://test.com/register?name=Vasya и последующий заказ товара от зарегистрированного пользователя https://test.com/order?user=Vasya&id=123. Здесь без регистрации мы не сможем сделать заказ.
• Другие

В запросах выше нет плохих вариантов, а есть разные подходы.

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

Когда мы заходим на сайт, мы генерируем состояние, оно в свою очередь генерирует сессию которая храниться на сервере, это Stateful система.

Но если состояние мы полностью передаем клиентом, то это уже Stateless, например можем для этого использовать cookie или jwt. Тогда мы всегда вместе с запросом отправляем информацию для его выполнения, при этом на сервере ничего не сохраняя. Stateless система зависит только от тех данных которые мы ее передали.

Что и когда выбирать

Нет однозначного хорошего решения.

Можно сказать, что для разработки отказоустойчивых приложений можно смотреть в сторону Stateless архитектуры.

Для создания полноценных больших проектов с сохранением состояния объектов, выбирайте Stateful.

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

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