stateless и stateful сервисы
Stateful системы
Такие системы хранят внутри себя состояние, которое влияет на запросы от пользователя. Примером могут быть сессии пользователей, которые хранятся на сервера. Ответ на запрос пользователя зависит от состояния сессии.
Одна из основных проблем таких систем — горизонтальное масштабирование. Чтобы развернуть несколько экземпляров сервиса нужно как переносить состояния но новые машины и синхронизировать их. Но проблема относительно легко решается за счет внешнего хранилища в котором можно хранить сессии. Система все равно является stateful, но сами веб сервисы стали stateless и теперь можно спокойно их масштабировать.
Stateless системы
Как альтернативу сессиям можно использовать cookie файлы или JWT токены. В таком случае вместе с запросом мы всегда отправляем всю необходимую информацию для его выполнения и аутентификации. В таком случае серверу не нужно хранить информацию о пользователе, достаточно проверить на валидность куки или токен в запросе. Так что stateless система зависит только от данных которые ей были переданы, а не от внутреннего состояния.
Еще один пример системы, которая хранит состояние: у нас есть интернет магазин. Пока корзина пользователя храниться в памяти сервера — это stateful. В таком случае мы опять упираемся в проблему с масштабированием. Но мы можем вынести состояние корзины в базу данных, тогда сервис станет stateless и можно легко его раскатывать на несколько машин.
Stateful vs. Stateless: выбираем архитектуру осознанно
Stateful и stateless относятся к способу управления состоянием в архитектуре ПО.
Stateful (с сохранением состояния) архитектура подразумевает, что система сохраняет информацию о предыдущих состояниях или взаимодействиях с клиентами. То есть, она сохраняет состояние между запросами или сеансами. Примером stateful архитектуры может быть классическое веб-приложение, которое хранит информацию о сеансе пользователя и состоянии его сессии на сервере.
Преимущества Stateful:
1. Сохранение состояния между запросами, что может быть полезно для сложных приложений с длительными сеансами.
2. Упрощение программной логики, так как состояние может быть сохранено и использовано в разных частях системы.
3. Более простая обработка и восстановление после ошибок или сбоев.
Недостатки Stateful:
1. Требуется сохранение состояния на сервере, что может приводить к высокой нагрузке на ресурсы и ограничивать масштабируемость системы.
2. Изменение состояния может быть сложным и приводить к ошибкам.
3. Ограниченная отказоустойчивость, так как сбой в состоянии может повлиять на работу системы.
Stateless (без сохранения состояния) архитектура не сохраняет информацию о предыдущих состояниях или сеансах. Каждый запрос рассматривается как отдельное, изолированное взаимодействие. RESTful веб-сервисы являются примером stateless архитектуры.
Преимущества Stateless:
1. Лучшая масштабируемость, поскольку каждый запрос обрабатывается независимо и не требуется хранить состояние.
2. Упрощенная разработка и тестирование, так как каждый запрос самодостаточен и не зависит от предыдущих.
3. Более высокая отказоустойчивость, так как отказ в одном компоненте не повлияет на остальные.
Недостатки Stateless:
1. Отсутствие сохранения состояния может усложнить реализацию некоторых функций, особенно при работе с сеансами или сложными взаимодействиями.
2. Дополнительная нагрузка может возникнуть при повторяющихся запросах, так как каждый запрос требует передачи полной информации.
Если вы планируете распределенное и отказоустойчивое приложение — смотрите в сторону stateless-архитектуры. Если же вы создаете MVP, ваше приложение не является критичным с точки зрения простоя, и горизонтальное масштабирование не предполагается — выбирайте stateful-архитектуру. Что касается меня, то мой выбор — stateless по-умолчанию. И только в случае обоснованной необходимости, принимая все потенциальные риски, я выбираю stateful.
Подписывайтесь на мой телеграм-канал Go HypeLoad, чтобы не пропустить полезную и актуальную информацию. И до скорых встреч, друзья!
Что такое Stateless и Statefull?
И я запутался. Например, в основном рекомендуется делать приложения Stateless. Но как в этой концепции обработать ту же корзину товаров? Потому что хранить её в куках не очень разумно, а если её не хранить в сессии (потому что сессии в stateless исключаются), то что остаётся — хранение в БД?
Я понимаю, что для REST stateless подходит идеально, потому что там единичные запросы и проще не создавать сессию, чем создавать. Ну а как быть с приложениями с UI? Где мне хранить корзину товаров? Может быть понятия stateless и statefull в принципе применимы только к REST API?
Таким образом вопрос у меня в том, что такое stateless и statefull, очень желательно с примерами, что будет считаться stateless, а что нет.
Отслеживать
задан 11 фев 2021 в 20:15
2,096 2 2 золотых знака 14 14 серебряных знаков 46 46 бронзовых знаков
Для решения вашей задачи можно воспользоваться хранением корзины в localStorage для неавторизованного пользователя и в базе данных для авторизованного пользователя. Если вы хотите обеспечить сохранность корзины клиента, вам конечно же стоит писать в базу данных связь с пользователем и выбранным товаром и выводить/изменять/удалять корзину. Хранить в сессии корзину нет смысла, когда есть такие замечательные два варианта.
11 фев 2021 в 21:34
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Мне кажется, у Вас в общем правильные представления и о том, что такое стейтлесс, и о том, что такое стейтфул, и том, где и что хранится.
Могу немного расшифровать, почему стейтлесс является модным.
Дело — в горизонтальном масштабировании.
Когад у вас миллион клиентов, и все они бесперывно что то покупают — то один веб — сервер не справляется. Ставят целуб «батарею» веб серверов, а перед ними — так называемый «распределитель нагрузки», который будет «кидать» пользовательский коннект на тот или иной сервер. Или раунд-робином (грубо говоря, по очереди), или на наименее загруженный в данный момент сервер.
Но вот беда. При этом один и тот же пользователь при кадом запросе «чего нибудь» с сервера может попадать на разные сервера. И ему пришлось бы или как «таскать за собой» сессию или. или хранить всё у себя, и каждый раз передавать на сервер.
Вторая причина стетлесса — простота тестирования. Понимаете, состояние — это такая штука, которую сложно воспроизвести во время автоматизированных тестов. А если всё «состояние» — это заранее оперделенная структура (например, json с определенными полями, о значении котрых ВСЕ известно) — то задача становится гораздо проще.
Теперь — у вас есть аргументы в пользу стетлесса.
И нам осталось одно: помирить эти два прекрасных мира.
Сделать это нетрудно.
Во первых, во многих серверных фремворках (и я говорю «фремворки», включая сюда как чистый PHP, так и что то понавороченее), есть возможность storage session to redis — ну, короче, в базе данных, только в очень простой, очень быстрой и, скорее всего, лежащей прямо в памяти.
Тогда можно не «гонять» туда-сюда весь стейт — можно гонять только идентификатор сессии. Тогда та нода, на которую «упал» клиентский запрос, быстренько «поднимет» сессию из редиса, и потом как ни в чем не бывало ответит Вам. А потом пойдет отвечать другому клиенту, сохранив Вашу сессию в базе.
Ну и наконец, хранить «корзину» на клиенте при современном развитии JS и вообще всего-всего — это фигня-вопрос. Фактически, Вам достаточно посылать тот же самый json-чик каждый раз, когда Вы что то делаете на сайте. И в это json-чике описано все-все-все. Добавили товар — изменился json. Удалили — опять изменился. Попросили скидку — этот факт отражен в Json’е. То есть, есть взаимно — однозанчное соответствие «что вижу на экране — то описано в состоянии».
Ну, а отсюда Вам прямая дорога в реакт. Реакт — это штука, которая предназначена для работы с состоянием.
На этом я заканчиваю свой краткий ответ, и надеюсь, что чем то смог Вам помочь
Stateless и Statefull страницы в Wicket 1.4
Для начала немного уточним о чем идет речь. Wicket хранит последнюю просмотренную страницу в сессии, но в случае если страница очень большая, иногда это может стать проблемой. Для того что бы избежать этих проблем, можно попытаться сделать страницу Stateless(т.е. не имеющую состояния).
Итак, Stateless page — это страница не имеющая состояния, Statefull page — это страница с состоянием.
- В первую очередь страница должна быть bookmarkable.
- Страница должна использовать только stateless компоненты.
Рассмотрим подробнее эти два условия:
Bookmarkable страница означает, что этой странице можно самостоятельно назначить URL, и этот URL не содержит ни какой информации связанной с сессией(к примеру версии страницы), и
её можно открыть непосредственно набрав адрес в браузере, даже если сессия ещё не начата.
Для того, что бы страница была Bookmarkable, она должна иметь конструктор не принимающий параметров или конструктор принимающий единственный параметр класса PageParameter .
В случае если страница создаётся с помощью конструктора не удовлетворяющего этим условиям, страница не будет Bookmarkable.
Если страница не является Bookmarkable, то к ней можно получить доступ только создав её из другой страницы.
Является компонент stateless или statefull определяется с помощью метода getStatelessHint(), который возвращает true если компонент stateless и false если нет.
К stateless относятся следующие компоненты:
- Label, MultiLineLabel, EnumLabel
- Panel, Border, BoxBorder, Include, TabbedPanel, FeedbackPanel
- BookmarkablePageLink, ExternalLink, ImageMap, StatelessLink
- StatelessForm
- Button, SubmitLink
- TextField, PasswordTextField, TextArea, HiddenField, RequiredTextField, DateTextField
- CheckBoxMultipleChoice, CheckGroupSelector
- ListMultipleChoice
- Select, SelectOption, SelectOptions
- Palette
- DataGridView, DataTable, Tree, TreeTable,
- ListItem, ListView, Loop, PageableListView, PropertyListView
- PagingNavigation, PagingNavigator
- BaseTree, LabelTree, LinkTree
- Link, ResourceLink
- Form
- CheckBox, CheckGroup, Check
- DropDownChoice, ListChoice
- Radio, RadioChoice, RadioGroup
- ImageButton
- PagingNavigationIncrementLink, PagingNavigationLink
- AJAX компоненты (существует библиотека, с некоторыми stateless AJAX компонентами github.com/jolira/wicket-stateless)
Важно: Link и Form являются statefull. Для использования этих компонентов в stateless страницах предназначены StatelessLink и StatelessForm.