Please enable JavaScript.
Coggle requires JavaScript to display documents.
Глава 4. Управление транзакциями с помощью повествований - Coggle Diagram
Глава 4. Управление транзакциями с помощью повествований
Управление транзакциями
в микросервисной архитектуре
Микросервисная архитектура и необходимость в распределенных транзакциях
Проблемы с распределенными транзакциями
Использование шаблона «Повествование» для сохранения согласованности данных
Повествования применяют компенсирующие транзакции
для отката изменений
Пример повествования: создание заказа
Координация повествований
Повествования, основанные на хореографии
Реализация повествования Create Order с помощью хореографии
Надежное взаимодействие на основе событий
Хореография — распределение принятия решений и упорядочения действий между участниками повествования, которые в основном общаются, обмениваясь событиями.
Слабая связанность. Участники подписываются на события, не владея непосред ственной информацией друг о друге. :heavy_plus_sign:
Простота. Сервисы публикуют события при создании, обновлении и удалении бизнес-объектов. :heavy_plus_sign:
Они сложнее для понимания. В отличие от оркестрации хореография не описыва ет повествование на каком-то одном участке кода — его реализация разбросана между сервисами. :heavy_minus_sign:
Возникают циклические зависимости между сервисами. Участники повество вания подписываются на события друг друга, что часто создает циклические зависимости. :heavy_minus_sign:
Существует риск жесткого связывания. Каждый участник повествования дол жен подписаться на все события, которые на него влияют. :heavy_minus_sign:
Повествования на основе оркестрации
Моделирование оркестраторов повествований в виде конечных автоматов
Оркестрация повествований
и транзакционный обмен сообщениями
Оркестрация — централизация координирующей логики повествования в виде класса-оркестратора. Оркестратор отправляет участникам повествования ко мандные сообщения с инструкциями, какие операции нужно выполнить.
Упрощенные зависимости. Одной из положительных сторон оркестрации явля ется то, что она не создает циклических зависимостей. Оркестратор вызывает участников повествования, но участники не вызывают оркестратор. В резуль тате оркестратор зависит от участников, но не наоборот, поэтому циклических зависимостей нет. :heavy_plus_sign:
Меньше связывания. Каждый сервис реализует API, который вызывается ор кестратором, поэтому ему не нужно знать о событиях, публикуемых другими участниками повествования :heavy_plus_sign:
Улучшенное разделение ответственности и упрощенная бизнес-логика. Вся коор динирующая логика повествования находится в оркестраторе. Благодаря этому доменные объекты становятся проще и им не нужно знать о повествованиях, в которых они участвуют. :heavy_plus_sign:
Риск избыточной централизации бизнес-логики в оркестраторе. В результате получается архитектура, в которой ум ный оркестратор командует глупыми сервисами. :heavy_minus_sign:
Что делать с недостаточной изолированностью
Обзор аномалий
Потеря обновлений — одно повествование перезаписывает изменения, внесенные другим, не читая их при этом.
«Грязное» чтение — транзакция или повествование читают незавершенные об новления другого повествования.
Нечеткое/неповторяемое чтение — два разных этапа повествования читают одни и те же данные, но получают разные результаты, потому что другое повествова ние внесло изменения.
Контрмеры на случай нехватки изолированности
Семантическая блокировка — блокировка на уровне приложения.
Коммутативные обновления — проектирование операций обновления таким образом, чтобы их можно было выполнить в любом порядке.
Пессимистическое представление — перестановка этапов повествования для минимизации бизнес-рисков.
Повторное чтение значения — предотвращение «грязного» чтения путем повтор ного считывания данных. Это позволяет убедиться в их неизменности перед тем, как их перезаписывать.
Файл версий — ведение записей об обновлениях, чтобы их можно было менять местами.
По значению — использование бизнес-рисков каждого запроса для динамического выбора механизма конкурентности.
Структура повестования
Транзакции, доступные для компенсации, — транзакции, которые потенциально можно откатить с помощью компенсирующих транзакций.
Поворотная транзакция — решающий момент в повествовании. Если поворот ная транзакция фиксируется, повествование отработает до конца. Поворотная транзакция может оказаться недоступной ни для компенсации, ни для повторе ния. Э го также может быть последняя компенсируемая или первая повторяемая транзакция.
Транзакции, доступные для повторения, — транзакции, идущие за поворотной. Всегда завершаются успешно.
Архитектура сервиса Order и повествования Create Order
Класс OrderService
Класс OrderCommandHandlers
Класс OrderServiceConfiguration