Шаблон проектирования Saga — это способ управления согласованностью данных между микрослужбами в сценариях распределенных транзакций. Saga — это последовательность транзакций, которая обновляет каждую службу и публикует сообщение или событие для активации следующего шага транзакции. Если шаг завершается ошибкой, Saga выполняет компенсирующие транзакции, которые отменяют предыдущие транзакции.
Контекст и проблема
Транзакция — это единая единица логики или работы, которая иногда состоит из нескольких операций. В рамках транзакции событие — это изменение состояния, которое происходит с сущностью, а команда инкапсулирует всю информацию, необходимую для выполнения действия или запуска последующего события.
Транзакции должны быть атомарными, постоянными, изолированными и устойчивыми (ACID). Транзакции в одной службе являются ACID, но согласованность данных между службами требует стратегии управления транзакциями между службами.
В архитектурах с многослужбами:
- Атомарность — это неделимый и ирредуЦибле набор операций, которые должны выполняться или отсутствовать.
- Согласованность означает, что транзакция переносит данные только из одного допустимого состояния в другое допустимое состояние.
- Изоляция гарантирует, что параллельные транзакции создают то же состояние данных, что и последовательные выполненные транзакции.
- Устойчивость гарантирует, что зафиксированные транзакции остаются зафиксированными даже в случае сбоя системы или отключения питания.
Модель « база данных на микрослужбах » предоставляет множество преимуществ для архитектур микрослужб. Инкапсуляция данных домена позволяет каждой службе использовать оптимальный тип хранилища данных и схему, масштабировать свое хранилище данных по мере необходимости и изолировать от сбоев других служб. Тем не менее, обеспечение согласованности данных в базах данных, относящихся к конкретной службе, создает проблемы.
Для выполнения распределенных транзакций, таких как протокол двухфазной фиксации (2PC) , необходимо, чтобы все участники транзакции зафиксировали или выполнили откат до того, как транзакция будет продолжена. Однако некоторые реализации участников, такие как базы данных NoSQL и брокер сообщений, не поддерживают эту модель.
Еще одно ограничение распределенных транзакций — синхронности и доступность межпроцессного взаимодействия . IPC, предоставляемая операционной системой, позволяет отдельным процессам совместно использовать данные. Для фиксации распределенных транзакций все участвующие службы должны быть доступны, что может привести к снижению общей доступности системы. Архитектурные реализации с ограничениями IPC или транзакций являются кандидатами для шаблона Saga.
Решение
Шаблон Saga обеспечивает управление транзакциями с помощью последовательности локальных транзакций. Локальная транзакция — это атомарная рабочая деятельность, выполняемая участником Saga. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие, чтобы активировать следующую локальную транзакцию в Saga. В случае сбоя локальной транзакции Saga выполняет ряд компенсирующих транзакций , которые отменяют изменения, внесенные предыдущими локальными транзакциями.
В шаблонах Saga:
- Транзакции подлежащих компенсации — это транзакции, которые потенциально могут быть реверсированы путем обработки другой транзакции с противоположным результатом.
- Сводная транзакция — это точка «вперед» и «не Go» в Saga. Если операция Pivot фиксируется, Saga выполняется до завершения. В качестве транзакции сведения может использоваться транзакция, которая не является ни подлежащих компенсации, ни повторяемой, либо может быть последней подлежащих компенсации транзакцией или первой повторяемой транзакцией в Saga.
- Повторяемые транзакции — это транзакции, которые следуют за транзакцией PIVOT и гарантированно выполняются.
Существует два распространенных подхода к реализации Saga, чореографи и оркестрации. Каждый подход имеет собственный набор проблем и технологий для координации рабочего процесса.
Хореография
Чореографи — это способ координации саг, в котором участники обмениваются событиями без централизованной точки управления. При использовании чореографи каждая локальная транзакция публикует события домена, которые активируют локальные транзакции в других службах.
Преимущества
- Хорошо подходит для простых рабочих процессов, требующих нескольких участников, и не требует логики координации.
- Не требует дополнительной реализации и обслуживания службы.
- Не вводит единую точку отказа, так как обязанности распределяются по участникам Saga.
Недостатки
- Рабочий процесс может стать запутанным при добавлении новых шагов, так как трудно отслеживать, какие участники Saga прослушивают команды.
- Существует риск циклической зависимости между участниками Saga, поскольку они должны использовать команды друг друга.
- Тестирование интеграции усложняется, так как для имитации транзакции должны выполняться все службы.
Оркестрация
Оркестрации — это способ координации саг, когда централизованный контроллер сообщает участникам Saga, какие локальные транзакции следует выполнить. Saga Orchestrator обрабатывает все транзакции и сообщает участникам, какая операция должна выполняться на основе событий. Orchestrator выполняет запросы Saga, сохраняет и интерпретирует состояния каждой задачи, а также выполняет восстановление после сбоя с помощью компенсирующих транзакций.
Преимущества
- Хорошо подходит для сложных рабочих процессов, в которых участвуют многие участники или новые участники, добавленные с течением времени.
- Подходит, если существует контроль над каждым участником процесса и управление потоком действий.
- Не вводит циклические зависимости, так как одностороннем Orchestrator зависит от участников Saga.
- Участникам Saga не нужно знать о командах для других участников. Четкое разделение проблем упрощает бизнес-логику.
Недостатки
- Дополнительная сложность проектирования требует реализации логики координации.
- Есть дополнительная точка отказа, так как Orchestrator управляет полным рабочим процессом.
Проблемы и рекомендации
При реализации шаблона Saga учитывайте следующие моменты:
- Шаблон Saga может быть сложным, так как он требует нового способа подумать о том, как координировать транзакцию и поддерживать согласованность данных для бизнес-процесса, охватывающего несколько микрослужб.
- Шаблон Saga особенно трудно отлаживать, и сложность растет по мере роста участников.
- Откат данных невозможен, так как участники Saga зафиксируют изменения в своих локальных базах данных.
- Реализация должна уметь обрабатывать набор потенциальных временных сбоев и предоставлять Идемпотентность для уменьшения побочных эффектов и обеспечения согласованности данных. Идемпотентность означает, что одна и та же операция может повторяться несколько раз, не изменяя первоначальный результат.
- Лучше реализовать наблюдаемость для отслеживания и отслеживания рабочего процесса Saga.
- Отсутствие изоляции данных участника накладывает проблемы с устойчивостью. Реализация Saga должна включать контрмеры для сокращения аномалий.
Следующие аномалии могут возникать без соответствующих мер:
- Потерянные обновления, когда один Saga записывается без чтения изменений, внесенных другим Saga.
- «Грязные» операции чтения, когда транзакция или Saga считывает обновления, сделанные Saga, которые еще не выполнили эти обновления.
- Нечеткие и неповторяемые операции чтения, когда различные шаги Saga считывают различные данные, так как происходит обновление данных между операциями чтения.
Предлагаемые контрмеры для сокращения или предотвращения аномалий включают:
- Семантическая блокировка, блокировка на уровне приложения, в которой транзакция подлежащих компенсации Saga использует семафор для указания на то, что обновление выполняется.
- Коммутативной обновления , которые могут выполняться в любом порядке и дают тот же результат.
- Пессимистическое представление: Один Saga может считывать «грязные» данные, в то время как другой Saga выполняет подлежащих компенсации транзакцию для отката операции. Пессимистическое представление переупорядочивает Saga, чтобы базовые данные были обновлены в повторяемой транзакции, что исключает возможность некорректного чтения.
- Значение для повторного считывания проверяет, что данные не изменяются, а затем обновляет запись. Если запись была изменена, действия прерываются, и Saga может перезапуститься.
- Файл версии записывает операции над записью по мере их поступления, а затем выполняет их в правильном порядке.
- По значению использует бизнес-риск каждого запроса для динамического выбора механизма параллелизма. Запросы с низким риском предпочитать саг, а запросы с высоким риском применяют распределенные транзакции.
Когда следует использовать этот шаблон
Используйте шаблон Saga, если вам нужно:
- Обеспечение согласованности данных в распределенной системе без тесной связи.
- Откат или компенсация при сбое одной из операций в последовательности.
Шаблон Saga менее подходит для:
- Тесно связанные транзакции.
- Компенсирующие транзакции, происходящие в предыдущих участниках.
- Циклические зависимости.
Пример
Saga на основе оркестрации в бессерверной среде — это справочник по реализации Saga, использующий подход оркестрации, имитирующий сценарий перевода денег с успешными и неудачными рабочими процессами.
Связанные шаблоны
Следующие шаблоны также могут быть полезными при реализации этого шаблона:
- Чореографи содержит каждый компонент системы, участвующий в процессе принятия решений о рабочем процессе бизнес-транзакции, вместо того чтобы полагаться на центральную точку управления.
- Компенсирующие транзакции отменяют работу, выполненную последовательностью действий, и в конечном итоге определяют последовательную операцию в случае сбоя одного или нескольких шагов. Облачные приложения, которые реализуют сложные бизнес-процессы и рабочие процессы, часто используют эту Модель согласованности.
- Повтор позволяет приложению управлять временными сбоями при попытке подключиться к службе или сетевому ресурсу путем прозрачного повторного выполнения операции, завершившейся сбоем. Повторная попытка может повысить стабильность приложения.
- При подключении к удаленной службе или ресурсу автоматическое выключение обрабатывает ошибки , которые принимают переменное количество времени. Автоматическое выключение может повысить стабильность и устойчивость приложения.
- Мониторинг конечных точек работоспособности реализует в приложении функциональные проверки, которые внешние средства могут получать доступ через общедоступные конечные точки через регулярные промежутки времени. Мониторинг конечных точек работоспособности может помочь проверить правильность выполнения приложений и служб.