Паттерн Хореография: Танцующие Микросервисы

Паттерн Хореография: Танцующие Микросервисы

Когда мы строим систему из микросервисов, возникает вопрос: как координировать взаимодействие между ними?

Есть два распространенных подхода:

  • Оркестрация — централизованный подход, в котором один сервис или компонент системы (дирижер) управляет остальными: вызывает, ждет, решает последовательность вызова и т.д.
  • Хореография — каждый сервис реагирует на события и действует самостоятельно, как в танце, когда нет главного, но все скоординировано.

📌 Что такое паттерн «хореография» в распределённых системах — простыми словами

Паттерн «хореография» (Choreography) — это подход к координации работы распределённых систем (например, микросервисов), где каждый компонент самостоятельно принимает решения на основе событий от других участников. Здесь нет центрального «дирижёра» — сервисы общаются через события (например, сообщения в Kafka/RabbitMQ), и каждый реагирует на них согласно своей логике.

Простая аналогия: представьте танец, где каждый участник знает свои шаги и реагирует на движения партнёров без указаний хореографа.

Пример

Рассмотрим небольшой абстрактный пример - создание, оплата и доставка заказа.

Паттерн Хореография: Танцующие Микросервисы

В этом случае, создание заказа можно описать последовательностью создания и обработки событий:

  1. Order Service публикует событие OrderCreated.
  2. Payment Service слушает это событие и инициирует оплату.
  3. Logistics Service ждёт PaymentCompleted, чтобы начать доставку.

Никто никого не вызывает напрямую — все реагируют на события.

Когда и где появилась хореография?

Концепция возникла в 1970-х в SOA (Service-Oriented Architecture), но популярность обрела с ростом микросервисов и Event-Driven Architecture (EDA) после 2010:

  • С появлением микросервисной архитектуры.
  • При работе с event sourcing, CQRS, serverless.
  • В масштабируемых системах (Netflix, Amazon, Uber).

Когда использовать?

Когда у вас:

  • Много сервисов, которые могут работать независимо.
  • Требуется масштабируемость и отказоустойчивость.
  • Нужна слабосвязанная архитектура.
  • Сценарии, где независимость сервисов важнее контроля (e.g., стриминговые платформы, IoT)

Но стоит быть готовым к:

  • Росту сложности при отладке и мониторинге.
  • Необходимости продуманной схемы событий.

Хореография — это философия децентрализации и доверия между сервисами. Она не заменяет оркестрацию, но даёт альтернативу для гибких, эволюционирующих систем.

В следующих постах расскажу:

  • Хореография + State Machine: как это можно сочетать
  • Где подводные камни.
  • Как она сочетается с Domain-Driven Design.

Подписывайся на мой канал в telegram

2 комментария