Statefullness и безгражданство обычно не о постоянстве БД. Кроме того, существуют различные уровни состояния (полное) (меньшее), я постараюсь перечислить несколько примеров:
Можно сказать, что микросервис не имеет состояния, если он не хранит информацию во внутренней памяти, которая является критическойдля обслуживания клиентов, вместо этого он хранит данные во внешних хранилищах (которые могут быть с состоянием). Хороший мысленный эксперимент состоит в том, чтобы представить, что ваш сервис перезапускается на другом узле между каждым запросом. Если сервис может выполнить свое назначение таким образом, его обычно можно считать не имеющим статуса. Другой пример - балансировщики нагрузки могут произвольно балансировать запросы, не используя липкие сеансы для сервисов без сохранения состояния. Это означает, что если ваша служба сохраняет данные в локальном хранилище (файловой системе и т. Д.), Затем перезапускается на другом узле, и эти данные были критически важны для нормальной работы, то они не остаются без сохранения состояния. Таким образом, сохранение состояния без ограничений строго не ограничивается хранением данных в памяти.
Служба с сохранением состояния может быть чем угодно, что хранит состояние между клиентскими доступами, и, учитывая, что это состояние уничтожено, некоторые запросы не будут выполнены.
Все усложняется с приложениями, которые имеют внутреннее состояние, но внешне имеют API без состояния. Например, систему, основанную на акторе, можно назвать состоящей из состояний (службы знают друг о друге), но автоматическое переключение при сбое (субъекты из мертвых узлов переносятся в действующие узлы) могут гарантировать надежность, если в сочетании с постоянным хранилищем состояния актера. Как вы видите, общий сервис с состоянием, но взаимодействия без учета состояния через API.
Что важнее этих умных слов, так это то, как ваше приложение ведет себя в некоторых граничных условиях:
- Обработка существующих процессов / сеансов / запросов во время масштабирования (добавление узлов)
- Обработка неожиданного перезапуска или завершения службы или узла
- Обработка запросов во время сетевых разделов
- и болеевот так ...
Если ваша служба может оставаться стабильной и эффективной в этих условиях, у вас все хорошо.