🛠️ Сага: эффективный шаблон микросервисной архитектуры
Паттерн Сага позволяет разбить сложные бизнес-процессы на управляемые этапы. Разберемся, как это работает и почему это важно.
Полную бизнес-транзакцию, как правило, очень сложно описать с помощью одной транзакции в базе данных. Возьмем, к примеру, процесс покупки в онлайн-магазине – с момента нажатия кнопки «Купить» до момента доставки заказа к вашей двери происходит серия шагов:
- Размещение заказа. Пользователь выбирает нужные товары, добавляет их в корзину и начинает процесс оформления заказа. Система сохраняет информацию о видах товаров, их количестве, имени заказчика, адресе и способе доставки.
- Создание счета-фактуры. После размещения заказа создается счет-фактура, который служит основной записью о транзакции и используется для выставления счета и учета.
- Обработка платежа. Инициируется процесс оплаты, пользователь предоставляет данные банковской карты или электронного кошелька. Оплата безопасно обрабатывается, и после успешного завершения заказ подтверждается.
- Отправка товара. После обработки платежа заказ готовится к отправке: создается информация для отслеживания, система уведомляет пользователя об ориентировочной дате доставки.
Каждый из этих шагов включает взаимодействие с различными микросервисами – сервисов заказов, платежным сервисом и сервисом доставки. Для успешного и последовательного выполнения бизнес-транзакции важна безупречная координация всех частей системы. Эта задача кажется очень сложной, но к счастью, есть универсальный и надежный паттерн, который помогает выстроить взаимодействие микросервисов самым оптимальным образом – Сага.
Паттерн Сага
Шаблон Сага разбивает сложную бизнес-транзакцию на серию небольших независимых этапов, обрабатываемых отдельными микросервисами. Есть два основных подхода к реализации этого паттерна – хореографический и оркестровый.
Хореографическая сага
В хореографической модели каждый сервис, участвующий в Саге, общается напрямую с другими сервисами, публикуя события. Вместо того, чтобы полагаться на центральный координатор для управления шагами, сервисы сами несут ответственность за принятие решений и реакцию на события:
- Публикация событий. Когда сервис выполняет действие или обнаруживает значимое условие в своей области, он публикует событие, уведомляющее другие сервисы. Это событие содержит соответствующую информацию об действии или условии, позволяя другим сервисам реагировать соответственно.
- Обработка событий. Когда сервис получает событие, он оценивает его на основе своих бизнес-правил и определяет соответствующий план действий.
Рассмотрим хореографию на примере обработки заказа:
- Создание заказа. Сервис заказов получает новый запрос на заказ и создает заказ. Он публикует событие «Заказ создан».
- Проверка наличия товара. Сервис инвентаризации слышит событие «Заказ создан» и проверяет наличие заказанных товаров. Если товары доступны, он резервирует их и публикует событие «Товары зарезервированы». Если товары отсутствуют, он публикует событие «Товары недоступны».
- Обработка платежа. Сервис платежей слышит событие «Товары зарезервированы» и инициирует обработку платежа. Если платеж успешен, он публикует событие «Платеж успешен». Если платеж неудачен, он публикует событие «Платеж неудачен».
- Организация доставки. Сервис доставки слышит событие «Платеж успешен» и организует доставку заказа, публикуя событие «Доставка организована».
- Компенсация ошибок. Если любой из сервисов встречает ошибку или получает компенсирующее событие (например, «Платеж неудачен» или «Товары недоступны»), он выполняет необходимые компенсирующие действия. Например, если сервис платежей получает событие «Платеж неудачен», он отменяет заказ и публикует событие «Заказ отменен».
Хореографическая Сага особенно хорошо подходит для двух сценариев:
- Динамические рабочие процессы. Хореографический подход позволяет легко адаптироваться к изменениям бизнес-процессов, так как не требует изменять центральную логику координации.
- Слабая связанность. Каждый сервис можно развивать и масштабировать независимо, в нужном темпе – это значительно упрощает поддержку и совершенствование сложной системы.
Паттерн Сага – мощный инструмент для управления сложными бизнес-процессами в микросервисной архитектуре. Но это лишь верхушка айсберга в мире архитектурных шаблонов.
Если вы хотите:
- Понять, как различные архитектурные паттерны могут улучшить ваши проекты
- Освоить лучшие практики проектирования сложных систем
- Узнать, как применять шаблоны для повышения гибкости и надежности
Курсы Futurio по архитектуре и шаблонам проектирования помогут вам освоить эти навыки.
Оркестровая Сага
В оркестровой модели Саги есть центральный координатор – оркестратор, «дирижер», который явно определяет последовательность шагов и зависимость между ними. Такой централизованный подход упрощает визуализацию и анализ общего процесса – вся логика заключена в оркестраторе. Рассмотрим пример системы обработки заказов:
- Сначала оркестратор инициирует размещение заказа.
- После размещения заказа происходит проверка деталей заказа и наличия товаров. Если проверка успешна, оркестратор запускает этап обработки платежа.
- После успешной обработки платежа оркестратор обновляет запасы, отражая проданные товары.
- Наконец, оркестратор инициирует процесс отправки заказа клиенту.
- В случае сбоя на любом этапе оркестратор обрабатывает ошибку и инициирует компенсирующие действия для отката предыдущих шагов и поддержания согласованности данных.
Оркестровая модель Саги особенно эффективна в следующих ситуациях:
- При работе со сложными бизнес-процессами, включающими множество этапов и точек принятия решений.
- Когда рабочий процесс четко определен и всегда следует заранее известной последовательности шагов.
- Когда между этапами существуют строгие зависимости.
Нормализация vs денормализация: как хранить данные в базе
Нормализация и денормализация — два разных подхода к структурированию данных: выбор между ними является одним из ключевых решений при разработке модели БД. Разберем подробно их преимущества и недостатки.
Нормализация — это метод организации данных в нескольких связанных таблицах для уменьшения избыточности и обеспечения целостности и непротиворечивости данных. В нормализованной модели данных каждая таблица представляет собой отдельную сущность или концепцию, а связи между сущностями устанавливаются через внешние ключи:
Основные характеристики нормализации:
- Несколько связанных таблиц. Нормализация разделяет данные на несколько таблиц на основе их логических связей. Каждая таблица фокусируется на конкретной сущности и содержит только атрибуты, непосредственно связанные с этой сущностью.
- Уменьшение избыточности. Организуя данные в отдельные таблицы, нормализация минимизирует избыточность – вместо повторения данных в нескольких таблицах она хранит данные только один раз в соответствующей таблице и использует внешние ключи для установления связей. Например, использует ID клиента для установления связи между заказом и клиентом.
- Целостность и непротиворечивость. Нормализация обеспечивает целостность и непротиворечивость данных, гарантируя их хранение в структурированном и стандартизованном виде. Это предотвращает аномалии и несоответствия, которые могут возникнуть из-за дублирования данных.
Однако потенциальным недостатком нормализации может быть то, что сложные запросы с использованием нескольких таблиц и объединений могут негативно повлиять на производительность. Извлечение данных из нормализованных таблиц требует ресурсоемких операций объединения, что может замедлять выполнение запросов. Например, создание отчета о заказах клиентов может потребовать объединения почти всех таблиц, если нужно получить все возможные детали – имя клиента, категории продуктов, детали заказа и так далее.
Денормализация — это подход, при котором данные из нескольких таблиц объединяются в одну для оптимизации производительности чтения. Она намеренно дублирует данные, чтобы упростить запросы и повысить их эффективность:
Ключевые характеристики денормализации включают:
- Объединение таблиц. Денормализация объединяет данные из нескольких связанных таблиц в одну, чтобы не использовать сложные объединения при выполнении запросов.
- Упрощение запросов. Благодаря объединению данных в одной таблице, денормализация упрощает запросы, уменьшая необходимость объединений и обеспечивая более быстрый доступ к данным.
- Улучшение производительности чтения. Денормализация обеспечивает быстрый доступ к часто запрашиваемым данным, исключая издержки на объединение множества таблиц и ускоряя выполнение запросов.
Однако у денормализации есть свои недостатки:
- Избыточность данных – денормализованные таблицы требуют больше места для хранения.
- Потенциальные проблемы с согласованностью, если обновления не распространяются последовательно на все дублированные данные.
При выборе между нормализацией и денормализацией следует учитывать несколько факторов:
- Согласованность и целостность данных. Если поддержание согласованности и целостности данных является главным приоритетом, то предпочтительным подходом будет нормализация. Нормализованные модели данных обеспечивают точное и последовательное хранение данных, снижая риск аномалий и несоответствий.
- Нагрузки с преобладанием чтения. Если нагрузка преимущественно состоит из операций чтения и важна производительность, то денормализация станет наилучшим выбором. Денормализованные модели данных оптимизированы для быстрого получения данных, что делает их подходящими для ситуаций, когда быстрый доступ к данным имеет решающее значение.
- Гибридный подход. В некоторых случаях оптимальным решением может быть гибридное решение, сочетающее нормализацию и денормализацию: критические данные, требующие строгой согласованности и целостности, можно нормализовать, а часто используемые данные, которые выигрывают от быстрой обработки, можно денормализовать.
Какие сложности вы сталкиваетесь при координации микросервисов, и как вы их решаете?