Паттерн Event-driven architecture

Когда заканчивается кофе Event-driven Разработчики генерируют событие CoffeeLowException и ждут...

Контекст
ПРоблемная Маша:
Мы применили паттерн Database per service. Теперь у каждого сервиса своя БД. Как обеспечить согласованность данных между сервисами?
Выручающий Саша:
А в чем проблема?
ПРоблемная Маша:
Есть бизнес процессы, которые включают несколько микров, обычные транзакции не подходит
Выручающий Саша:
Попробуйте событийно-ориентированный подход. У вас не будет согласованности в моменте, но будет согласованность в конечном итоге.
Проблема
Как обеспечить согласованность данных для бизнес процессов, охватывающих несколько сервисов, у которых свои БД?
Решение
Каждый сервис публикует событие при каждом обновлении своих данных, другие сервисы подписываются на эти события и обновляют свои данные.

  1. Order service создает ордер и публикует Order Ceated event.
  2. Product service получает событие, резервирует товар и публикует Product Reserved Event.
  3. Payment service получает событие, проводит платеж и публикует Payment Processed Event.
  4. Shipment service получает событие, создает тикет на отгрузку товара, и публикует Shipment Ticket Created Event.
  5. Order service считывает и успешно закрывает ордер. (И публикует событие и сервис нотификации отправляет сообщение клиенту)
Преимущества
  • Не надо использовать распределенные транзакции
    EDA это способ уйти от сложных 2PC и 3PC, которые приводят к связанности сервисов и мы ограничены в использовании технологий, так они должны поддерживать распределенные транзакции.
  • Слабые связи благодаря асинхронному взаимодействию
    Как следствие слабых связей - гибкость, масштабируемость, отказоустойчивость
  • Упрощение интеграции
    EDA упрощает интеграцию с различными системами через стандартный механизм событий
Недостатки
  • Нет согласованности данных в моменте
    Что приводит к тому, что надо применять компенсирующие транзакции и такие паттерны как SAGA
  • Сложность отладки и тестирования
    В EDA время от возникновения события до его конечного воздействия может быть значительным, проходя через множество сервисов. Это делает сложным отслеживание и устранение проблем, требуя использования продвинутых инструментов, таких как распределенные трейсеры и логирование.
  • Нужно заботиться о порядке событий
    В распределенных системах события могут приходить не в том порядке, в котором они были сгенерированы. Это может приводить к логическим ошибкам, особенно в сценариях, где важна последовательность операций (например, в финансовых транзакциях). Для решения этой проблемы требуется использование ключей партиционирования и идемпотентных обработчиков
  • Необходимость в дополнительной инфраструктуре
    EDA требует наличия брокера сообщений, балансировщиков, средств мониторинга и других компонентов, что увеличивает затраты на инфраструктуру по сравнению с более простыми архитектурами.
JavaGuru.by
Онлайн-школа профессионального программирования на java для коммерческих разработчиков и соискателей.
2 главные задачи, которые мы решаем:
  1. Трудоустройство и успешное прохождение испыталки.
  2. Переход на современный стек middle+
Наше главное достояние:
Менторская поддержка 24/7 и обучение в формате живого общения
Получить консультацию по обучению