Поиск по сайту:

Приложения с отслеживанием состояния и приложения без сохранения состояния: как они влияют на DevOps


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

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

Что такое государство?

«Состояние» службы — это постоянная информация, которая записывается во время одной транзакции или события, а затем вызывается во время другой. Одним из простейших примеров состояния является сервер базы данных: он управляет хранимыми данными, которые необходимо надежно сохранять. Запись, сохраненная в одном сеансе, должна быть доступна для следующего сеанса.

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

Что такое приложения без сохранения состояния?

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

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

Является ли мое приложение с сохранением состояния или без него?

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

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

Вы можете определить, нужна ли приложению модель развертывания с отслеживанием или без отслеживания состояния, посмотрев, как оно хранит данные. Состояние отсутствует, если нет постоянства или данные хранятся только на устройстве пользователя или в несвязанном поставщике хранилища, таком как Amazon S3. Приложение будет сохранять состояние, если оно напрямую изменяет свою среду посредством записи в файловую систему и других изменений, а затем требует, чтобы эти изменения сохранялись в течение неопределенного времени.

Состояние с контейнерами и облаком

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

Однако контейнеры можно использовать для инкапсуляции систем с отслеживанием состояния. Постоянные тома предоставляют средства для подключения надежного хранилища, которое переживает отдельные экземпляры контейнеров. По сравнению с традиционными виртуальными машинами и развертыванием на «голом железе» разница сводится к присущей управлению состоянием контейнера преднамеренности.

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

Как состояние влияет на DevOps

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

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

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

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

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

Краткое содержание

Различие между приложениями с отслеживанием состояния и приложениями без сохранения состояния важно для успеха DevOps. С точки зрения DevOps приложение с отслеживанием состояния будет более сложным в развертывании и обслуживании, поскольку вам необходимо предоставить каждому экземпляру доступ к постоянному хранилищу данных.

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