Паттерн: Сага
Интересный архитектурный шаблон, особенно актуальный в условиях распределённых систем, когда некое бизнес-осмысленное действие будет успешным, только если будет успешным каждый небольшой шаг, а функционал реализован в разных сервисах; если любой шажок закончится неудачей, то надо откатить все предыдущие (успешные) шаги.
— Pattern: Saga
Пример — создание заказа на одном из текущих проектов. Задача: создать сущность заказа в OMS в статусе «Создан», затем зарезервировать остатки под заказ в системе оперативных остатков товаров, потом сменить статус заказа на «Оформлен» и в конце отправить уведомления клиенту и менеджеру (ещё нужно будет бонусы списывать в программе лояльности, но это на следующих этапах проекта).
Формально сагу рекомендуют делать на событиях, которые либо оркестрируются либо обрабатываются хореографически. Мы сделали упрощённый оркестратор, который хранит состояние саги в реляционной СУБД. В случае неудачи оркестратор пытается выполнить шаг с таймаутом с нелинейным возрастанием задержки. Если попытки исчерпаны — вся сага отменяется с компенсирующими действиями.
Наша сага имеет следующие шаги:
APPLY_STOCK — создать временный резерв остатков
APPLY_LOYALTY — списать бонусы в системе лояльности
CONFIRM — подтвердить заказ, отправить уведомления
Финальные шаги:
FINISHED — сага успешно завершена
FAILED — сага завершилась с ошибками
Шаг отката:
ROLLBACK_STOCK — убрать временный резерв остатков в случае ошибок
Я решил не усложнять архитектуру асинхронными очередями, потому что: (1) тестировать сагу стало бы в разы сложнее; (2) проектная нагрузка на систему далека от „High load“; (3) узнать в моменте состояние саги стало бы сложнее.
Подобная реализация уже была сделана нашим тимлидом на другом проекте и по моим наблюдениям вполне неплохо себя зарекомендовала. Проблемы, которые там были, появились из-за некачественного логгирования шагов и плохо настроенных таймаутов (финальные таймауты достигали дней между повторами). Я с самого начала спроектировал логгирование правильно, ну а для таймаутов, для разнообразия взял ряд Фибоначчи с ценой деления 1 минута.
А есть ли у вас в практике интересные шаблоны проектирования, которые вы использовали осознанно? (ну или случайно, главное чтобы вам понравилось :) )
Интересный архитектурный шаблон, особенно актуальный в условиях распределённых систем, когда некое бизнес-осмысленное действие будет успешным, только если будет успешным каждый небольшой шаг, а функционал реализован в разных сервисах; если любой шажок закончится неудачей, то надо откатить все предыдущие (успешные) шаги.
Сага — это последовательность локальных транзакций. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие, чтобы запустить следующую локальную транзакцию в саге. Если локальная транзакция завершается неудачей из-за нарушения бизнес-правила, сага выполняет серию компенсирующих транзакций, которые отменяют изменения, внесённые предыдущими локальными транзакциями.
— Pattern: Saga
Пример — создание заказа на одном из текущих проектов. Задача: создать сущность заказа в OMS в статусе «Создан», затем зарезервировать остатки под заказ в системе оперативных остатков товаров, потом сменить статус заказа на «Оформлен» и в конце отправить уведомления клиенту и менеджеру (ещё нужно будет бонусы списывать в программе лояльности, но это на следующих этапах проекта).
Формально сагу рекомендуют делать на событиях, которые либо оркестрируются либо обрабатываются хореографически. Мы сделали упрощённый оркестратор, который хранит состояние саги в реляционной СУБД. В случае неудачи оркестратор пытается выполнить шаг с таймаутом с нелинейным возрастанием задержки. Если попытки исчерпаны — вся сага отменяется с компенсирующими действиями.
Наша сага имеет следующие шаги:
APPLY_STOCK — создать временный резерв остатков
APPLY_LOYALTY — списать бонусы в системе лояльности
CONFIRM — подтвердить заказ, отправить уведомления
Финальные шаги:
FINISHED — сага успешно завершена
FAILED — сага завершилась с ошибками
Шаг отката:
ROLLBACK_STOCK — убрать временный резерв остатков в случае ошибок
Я решил не усложнять архитектуру асинхронными очередями, потому что: (1) тестировать сагу стало бы в разы сложнее; (2) проектная нагрузка на систему далека от „High load“; (3) узнать в моменте состояние саги стало бы сложнее.
Подобная реализация уже была сделана нашим тимлидом на другом проекте и по моим наблюдениям вполне неплохо себя зарекомендовала. Проблемы, которые там были, появились из-за некачественного логгирования шагов и плохо настроенных таймаутов (финальные таймауты достигали дней между повторами). Я с самого начала спроектировал логгирование правильно, ну а для таймаутов, для разнообразия взял ряд Фибоначчи с ценой деления 1 минута.
А есть ли у вас в практике интересные шаблоны проектирования, которые вы использовали осознанно? (ну или случайно, главное чтобы вам понравилось :) )