Шаблон проектирования Saga помогает поддерживать согласованность данных в распределенных системах путем координации транзакций между несколькими службами. Сага — это последовательность локальных транзакций, где каждая служба выполняет свою операцию и инициирует следующий шаг через события или сообщения. Если шаг в последовательности завершается сбоем, сага выполняет компенсирующие транзакции для отмены выполненных шагов, сохраняя согласованность данных.
Контекст и проблема
транзакция представляет единицу работы, которая может включать несколько операций. В рамках транзакции событие относится к изменению состояния, влияющего на сущность. Команда инкапсулирует все сведения, необходимые для выполнения действия или запуска последующего события.
Транзакции должны соответствовать принципам атомарности, согласованности, изоляции и устойчивости (ACID).
- атомарности: все операции выполняются успешно или нет.
- согласованности: данные переходы из одного допустимого состояния в другое.
- изоляции: параллельные транзакции дают те же результаты, что и последовательные.
- устойчивость: после фиксации изменения сохраняются даже в сбоях.
В одной службе транзакции следуют принципам ACID, так как они работают в одной базе данных. Однако достижение соответствия ACID в нескольких службах является более сложным.
Проблемы в архитектуре микрослужб
Архитектуры микрослужб обычно назначают выделенную базу данных каждой микрослужбе, что обеспечивает несколько преимуществ:
- Каждая служба инкапсулирует собственные данные.
- Каждая служба может использовать наиболее подходящую технологию базы данных и схему для конкретных потребностей.
- Независимое масштабирование баз данных для каждой службы.
- Сбои в одной службе изолированы от других.
Несмотря на эти преимущества, эта архитектура усложняет согласованность данных между службами. Традиционные гарантии базы данных, такие как ACID, напрямую не применимы к нескольким независимым управляемым хранилищам данных. Из-за этих ограничений архитектуры, основанные на межпроцессном взаимодействии (IPC) или традиционных моделях транзакций, таких как протокол 2PC, часто лучше подходят для шаблона Saga.
Решение
Шаблон Saga управляет транзакциями, разбив их на последовательность локальных транзакций (см. рисунок 1).
Рис. 1. Сага с тремя службами.
Каждая локальная транзакция:
- Выполняет свою работу атомарно в рамках одной службы.
- Обновляет базу данных службы.
- Инициирует следующую транзакцию через событие или сообщение.
- Если локальная транзакция завершается ошибкой, сага выполняет ряд компенсирующих транзакций для отмены изменений, внесенных предыдущими локальными транзакциями.
Основные понятия в шаблоне Saga
компенсируемые транзакции: транзакции, которые другие транзакции могут отменить или компенсировать противоположным эффектом. Если шаг сага завершается ошибкой, компенсирующие транзакции отменяют изменения, внесенные компенсируемыми транзакциями.
транзакции сводной таблицы: транзакция сводной таблицы служит точкой без возврата в сага. После успешной транзакции сводной транзакции компенционные транзакции (которые могут быть отменены) больше не актуальны. Все последующие действия должны выполняться для того, чтобы система достигла согласованного окончательного состояния. Транзакция сводной таблицы может попасть в разные роли в зависимости от потока сага:
необратимые (некомпенсируемые): невозможно отменить или повторно выполнить попытку.
граница между обратимой и зафиксированной: это может быть последняя неуправляемая (компенируемая) транзакция, или это может быть первая повторная операция в сага.
повторные транзакции: эти транзакции соответствуют транзакции сводной. Повторные транзакции являются идемпотентными и гарантируют, что сага может достичь окончательного состояния, даже если временные сбои возникают. Это гарантирует, что сага достигает согласованного состояния в конечном итоге.
Подходы к реализации Saga
Существует два распространенных подхода к реализации сага, хореографии и оркестрации. Каждый подход имеет собственный набор проблем и технологий для координации рабочего процесса.
Хореография
В хореографии службы обмениваются событиями без централизованного контроллера. При использовании хореографии каждая локальная транзакция публикует события домена, которые активируют локальные транзакции в других службах (см. рисунок 2).
Рис. 2. Сага, использующая хореографию.
| Преимущества хореографии | недостатки хореографии |
|---|---|
| Хорошо подходит для простых рабочих процессов с несколькими службами и не нуждается в логике координации. | Рабочий процесс может запутаться при добавлении новых шагов. Трудно отслеживать, какие участники сага прослушивают команды. |
| Для координации не требуется никакой другой службы. | Существует риск циклической зависимости между участниками saga, так как они должны использовать команды друг друга. |
| Не вводит одну точку сбоя, так как обязанности распределяются по участникам сага. | Тестирование интеграции сложно, так как все службы должны выполняться для имитации транзакции. |
Оркестровка
В оркестрации централизованный контроллер (оркестратор) обрабатывает все транзакции и сообщает участникам, какие операции следует выполнять на основе событий. Оркестратор выполняет запросы saga, хранит и интерпретирует состояния каждой задачи и обрабатывает восстановление сбоев с помощью компенсирующих транзакций (см. рисунок 3).
Рис. 3. Сага, использующая оркестрацию.
| Преимущества оркестрации | недостатки оркестрации |
|---|---|
| Лучше подходит для сложных рабочих процессов или при добавлении новых служб. | Для другой сложности проектирования требуется реализация логики координации. |
| Избегает циклических зависимостей, так как оркестратор управляет потоком. | Представляет точку сбоя, так как оркестратор управляет полным рабочим процессом. |
| Четкое разделение обязанностей упрощает логику службы. |
Проблемы и рекомендации
При реализации шаблона Saga следует учитывать следующие моменты:
Shift в проектировании мышления: внедрение шаблона Saga требует другого мышления, акцентируя внимание на координации транзакций и обеспечение согласованности данных в нескольких микрослужбах.
сложность отладки sagas: отладка саг может быть сложной, особенно по мере роста числа участвующих служб.
необратимые изменения локальной базы данных: данные не могут быть откатированы, так как участники saga фиксируют изменения в соответствующих базах данных.
Обработка временных сбоев и идемпотенции: система должна эффективно обрабатывать временные сбои и обеспечить идемпотенс, где повторение той же операции не изменяет результат. Дополнительные сведения см. в обработке сообщений Idempotent.
Необходимость мониторинга и отслеживания саги: мониторинг и отслеживание рабочего процесса сага важны для поддержания оперативного надзора.
ограничения компенсационных транзакций: компенсационные транзакции могут не всегда выполняться успешно, потенциально оставляя систему в несогласованном состоянии.
Потенциальные аномалии данных в сагах
Аномалии данных — это несоответствия, которые могут возникать при выполнении сага в нескольких службах. Так как каждая служба управляет собственными данными (данными участника), встроенная изоляция между службами отсутствует. Эта настройка может привести к несоответствиям данных или проблемам устойчивости, таким как частично примененные обновления или конфликты между службами. Распространенные проблемы:
потерянных обновлений: когда одна сага изменяет данные без учета изменений, внесенных другой сага, это приводит к перезаписи или отсутствующим обновлениям.
Грязные считывает: когда сага или транзакция считывает данные, измененные другой сага, но еще не завершены.
нечеткие (неизменяемые) считывает. Когда различные шаги в саге считывают несогласованные данные, так как обновления происходят между считываниями.
Стратегии устранения аномалий данных
Чтобы уменьшить или предотвратить эти аномалии, рассмотрите следующие контрмеры:
семантическая блокировка. Используйте блокировки уровня приложения, в которых компенционная транзакция saga использует семафор, чтобы указать, что обновление выполняется.
коммутативные обновления: обновление конструктора, чтобы они могли применяться в любом порядке, сохраняя тот же результат, уменьшая конфликты между сагами.
пессимистичное представление: переупорядочение последовательности сага, чтобы обновления данных выполнялись в повторных транзакциях для устранения грязных операций чтения. В противном случае одна сага может считывать грязные данные (незафиксированные изменения), а другая сага одновременно выполняет компилируемую транзакцию для отката обновлений.
перечитание значений: убедитесь, что данные остаются неизменными перед внесением обновлений. Если данные изменяются, прервать текущий шаг и перезапустить сага по мере необходимости.
файлы версий: сохраняйте журнал всех операций записи и убедитесь, что они выполняются в правильной последовательности, чтобы предотвратить конфликты.
параллелизм на основе рисков (по значению): динамически выберите соответствующий механизм параллелизма на основе потенциального бизнес-риска. Например, используйте саги для обновлений с низким уровнем риска и распределенных транзакций для высокориском.
Когда следует использовать этот шаблон
Используйте шаблон Saga, когда необходимо:
- Обеспечение согласованности данных в распределенной системе без жесткой связи.
- Откат или компенсация, если одна из операций в последовательности завершается сбоем.
Шаблон Saga менее подходит для:
- Тесно связанные транзакции.
- Компенсация транзакций, происходящих в предыдущих участниках.
- Циклические зависимости.
Дальнейшие действия
- распределенных данных
- Ричардсон, Крис. 2018: шаблонов микрослужб. Публикации мэннинга.
Связанные ресурсы
При реализации этого шаблона также могут быть полезны следующие шаблоны:
- хореографии имеет каждый компонент системы в процессе принятия решений о рабочем процессе бизнес-транзакции, а не на основе центральной точки управления.
- компенсирующие транзакции отменить работу, выполняемую рядом шагов, и в конечном итоге определите согласованную операцию, если один или несколько шагов завершаются сбоем. Облачные приложения, реализующие сложные бизнес-процессы и рабочие процессы, часто следуют этому конечной модели согласованности.
- повторная попытка позволяет приложению обрабатывать временные сбои при попытке подключиться к службе или сетевому ресурсу, прозрачно повторяя неудачную операцию. Повторные попытки могут повысить стабильность приложения.
- средство разбиения цепи обрабатывает ошибки, которые занимают переменное время восстановления при подключении к удаленной службе или ресурсу. Средство автоматического останова может повысить стабильность и устойчивость приложения.
- мониторинг конечных точек работоспособности реализует функциональные проверки в приложении, к которому внешние средства могут обращаться через предоставляемые конечные точки через регулярные интервалы. Мониторинг конечных точек работоспособности может помочь проверить правильность работы приложений и служб.