Чем отличается оркестрация от хореографии в микросервисной архитектуре?

Оркестрация vs Хореография в микросервисной архитектуре

Оркестрация и хореография — это два фундаментально разных подхода к управлению взаимодействием между микросервисами. Выбор между ними влияет на архитектуру, сложность, отказоустойчивость и масштабируемость системы.

Оркестрация (Orchestration)

Определение

Оркестрация — это centralized approach, где единая система (оркестратор/conductor) управляет и координирует работу всех микросервисов. Оркестратор знает весь workflow и управляет переходами между сервисами.

Оркестрация (Centralized Control):

                    ┌─────────────────────┐
                    │   Orchestrator      │
                    │   (Conductor)       │
                    └──────────┬──────────┘
                        │  │  │  │
          ┌─────────────┘  │  │  └──────────────┐
          │                │  │                 │
     ┌────▼────┐      ┌────▼──┴──┐       ┌─────▼───┐
     │ User    │      │ Order    │       │Payment  │
     │Service  │      │Service   │       │Service  │
     └─────────┘      └─────────┬┘       └────┬────┘
                              │ │
                         ┌────▼─┴────┐
                         │ Inventory │
                         │ Service   │
                         └───────────┘

Как работает оркестрация

Оркестратор:
"Order Service, создай order"
Order Service → ОК, order создан, вот ID

Оркестратор:
"Payment Service, обработай платёж на $100"
Payment Service → ОК, платёж обработан

Оркестратор:
"Inventory Service, забронируй товар"
Inventory Service → ОК, товар забронирован

Оркестратор:
"Notification Service, отправь confirmation email"
Notification Service → ОК, email отправлен

Оркестратор: Order complete!

Поток выполнения (Orchestration)

1. Orchestrator получает Create Order request
2. Orchestrator вызывает Order Service (sync)
3. Orchestrator ждёт ответ (Order ID)
4. Orchestrator вызывает Payment Service (sync)
5. Orchestrator ждёт ответ (Payment confirmed)
6. Orchestrator вызывает Inventory Service (sync)
7. Orchestrator ждёт ответ (Reserved)
8. Orchestrator вызывает Notification Service (sync)
9. Orchestrator ждёт ответ (Email sent)
10. Orchestrator возвращает результат клиенту

Плюсы оркестрации

Ясный контроль — весь workflow видно в одном месте

• Оркестратор знает всё
• Легко отследить, что происходит
• Понятная бизнес-логика

Простая отладка — центральное место для логирования

• Всё в одном месте
• Полная trace workflow
• Легко найти где ошибка

Простая обработка ошибок — компенсирующие операции

try:
    order_id = order_service.create(order)
    payment_result = payment_service.process(order_id, amount)
    if payment_result.failed:
        # Compensation: удалить order
        order_service.cancel(order_id)
        raise PaymentException()
    inventory_service.reserve(order_id, items)
except Exception as e:
    # Rollback всех операций
    order_service.cancel(order_id)
    inventory_service.unreserve(order_id, items)

Контроль dependencies — оркестратор знает что от кого зависит

• Можно управлять retry логикой
• Можно управлять timeout
• Explicit flow

Минусы оркестрации

Tight coupling — оркестратор знает про все сервисы

• Если добавим новый сервис, нужно изменить оркестратор
• Оркестратор becomes bottleneck
• Single point of failure

Single point of failure — если оркестратор упадёт

• Весь workflow останавливается
• Никакие микросервисы не работают
• Нужна high availability для оркестратора

Масштабируемость оркестратора — становится узким местом

• Все requests проходят через оркестратор
• Если 10,000 req/sec, оркестратор должен handle 10,000 req/sec
• Требует масштабирования оркестратора

Complexity растёт — оркестратор становится всё более сложным

• Много условий и branches
• Compensation logic
• Error handling
• Timeout logic
• Retry logic

Примеры оркестрации

AWS Step Functions — AWS serverless orchestration

StateMachine:
  StartAt: CreateOrder
  States:
    CreateOrder:
      Type: Task
      Resource: arn:aws:lambda:order-service
      Next: ProcessPayment
    ProcessPayment:
      Type: Task
      Resource: arn:aws:lambda:payment-service
      Next: ReserveInventory
    ReserveInventory:
      Type: Task
      Resource: arn:aws:lambda:inventory-service
      End: true

Saga Pattern (Orchestration вариант)

class OrderSaga:
    def execute(self, order):
        # Orchestrator управляет workflow
        order = self.order_service.create(order)
        try:
            payment = self.payment_service.process(order)
            inventory = self.inventory_service.reserve(order)
            notification = self.notification_service.send(order)
            return order
        except Exception:
            self.compensate(order)

Хореография (Choreography)

Определение

Хореография — это decentralized approach, где каждый сервис знает только про себя и про события которые его интересуют. Сервисы взаимодействуют через события, а не через центральный оркестратор.

Хореография (Decentralized):

Order Service ──[OrderCreated event]──> Event Bus <──┐
                                          │  │  │     │
                                          │  │  │     │
                                    ┌─────┘  │  └──┐  │
                                    │        │     │  │
                               Payment   Inventory  Notification
                               Service    Service    Service
                               (subscribes to OrderCreated)
                               (publishes PaymentProcessed)
                               (publishes InventoryReserved)
                               (publishes NotificationSent)

Как работает хореография

1. Client отправляет CreateOrder request
2. Order Service создаёт order
3. Order Service публикует "OrderCreated" event
4. Order Service возвращает order ID клиенту
5. 
   Event Bus получает event
   ├─ Payment Service слушает, получает event → обрабатывает платёж
   ├─ Inventory Service слушает, получает event → бронирует товар
   └─ Notification Service слушает, получает event → отправляет email

6. Payment Service обрабатывает → публикует "PaymentProcessed" event
7. Inventory Service бронирует → публикует "InventoryReserved" event
8. Notification Service отправляет → публикует "NotificationSent" event

9. Всё асинхронно, нет одного оркестратора

Event-driven поток (Choreography)

Order Service:
    def create_order(order):
        order = save_to_db(order)
        event_bus.publish('OrderCreated', order)  # Just publish!
        return order

Payment Service (listening):
    @event_bus.subscribe('OrderCreated')
    def on_order_created(event):
        payment = process_payment(event.order)
        event_bus.publish('PaymentProcessed', payment)

Inventory Service (listening):
    @event_bus.subscribe('OrderCreated')
    def on_order_created(event):
        reserved = reserve_inventory(event.order)
        event_bus.publish('InventoryReserved', reserved)

Notification Service (listening):
    @event_bus.subscribe('OrderCreated')
    def on_order_created(event):
        send_email(event.order)
        event_bus.publish('NotificationSent', notification)

Плюсы хореографии

Loose coupling — сервисы не знают друг про друга

• Order Service не знает про Payment, Inventory, Notification
• Можно добавить новый сервис без изменения Order Service
• Service может быть заменён на другой (если event interface тот же)

Scalability — нет central bottleneck

• Каждый сервис масштабируется независимо
• Event Bus масштабируется
• Нет single point of failure в orchestration

Гибкость — легко добавить новые сервисы

# Добавляем Analytics Service
@event_bus.subscribe('OrderCreated')
def on_order_created(event):
    track_analytics(event.order)

# Никакие другие сервисы не знают что это произошло!

Хорошо для asynchronous — естественно fit асинхронной архитектуре

• Events полностью асинхронные
• Нет blocking calls
• Better resilience (Payment можно обработать потом)

Простота отдельного сервиса — каждый сервис простой

• Payment Service не знает про Order, Inventory
• Фокусируется только на payments
• Easy to understand и maintain

Минусы хореографии

Сложность понимания — workflow не видно в одном месте

• Нужно читать код разных сервисов
• Harder to understand what happens
• Implicit dependencies

Сложная отладка — нет одного места где видно flow

• Payment processed, но когда?
• Где error произошла?
• Требуется distributed tracing (Jaeger, Zipkin)

Циклические зависимости — можно создать loops

Order Service
├─ publishes OrderCreated
├─ (Inventory слушает)
└─ publishes InventoryReserved
   └─ (Payment слушает, думает order changed)
      └─ publishes PaymentReprocessed
         └─ (Order слушает?) → LOOP!

Нужно аккуратно design events.

Сложнее с compensations — откатывать changes

Что если Payment failed но Inventory уже забронирован?
- Payment Service должна знать как unbookmark
- Или нужно async compensation
- Becomes complex

Testing сложнее — асинхронные interactions

# Как тестировать что когда Payment failed, Order был updated?
order = Order.create()
# Дождёмся async processing
await_for_event('PaymentFailed')
assert order.status == 'failed'
# Сложнее, требует специального tooling

Примеры хореографии

Apache Kafka — Event streaming platform

order_topic = kafka.topic('orders')
payment_topic = kafka.topic('payments')
inventory_topic = kafka.topic('inventory')

# Order Service publishes
def create_order(order):
    order = save(order)
    order_topic.publish(order)  # Event
    return order

# Payment Service subscribes
def payment_worker():
    for order in order_topic.subscribe():
        payment = process(order)
        payment_topic.publish(payment)  # Event

# Inventory Service subscribes
def inventory_worker():
    for order in order_topic.subscribe():
        reserve = reserve_inventory(order)
        inventory_topic.publish(reserve)  # Event

RabbitMQ — Message broker

# Order Service
order_exchange = channel.exchange_declare('orders')
order_exchange.publish('order.created', order)

# Payment Service (listening)
def payment_service():
    queue = channel.queue_declare('payment_queue')
    queue.bind('orders', 'order.*')  # Subscribe to all order events
    for message in queue.consume():
        process_payment(message.body)

# Inventory Service (listening)
def inventory_service():
    queue = channel.queue_declare('inventory_queue')
    queue.bind('orders', 'order.created')
    for message in queue.consume():
        reserve_inventory(message.body)

Orchestration vs Choreography таблица

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

✓ Complex workflows — много зависимостей ✓ Strict order — A must happen before B ✓ ACID важна — need strong consistency ✓ Conditional logic — if A then B, else C ✓ Synchronous operations — нужны results immediately ✓ Well-defined flow — workflow чётко определён ✓ Compensation важна — need rollback logic ✓ Small team — одна team может manage orchestrator

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

✓ Loose coupling — сервисы независимы ✓ Scalability нужна — нет central bottleneck ✓ Event-driven — естественно асинхронные ✓ Adding services часто — new services easily subscribe ✓ Eventual consistency OK — not strict ACID ✓ Asynchronous operations — можем ждать ✓ High volume events — throughput важна ✓ Microservices архитектура — decentralized nature

Гибридный подход

Orchestration + Choreography — лучшее из обоих

Complex Orders Workflow:

OrderService ─── [OrderCreated event] ──→ EventBus ──→ PaymentService
                                             │         
                                       Orchestrator (управляет workflow)
                                         ├─ Проверяет constraints
                                         ├─ Handles compensations
                                         └─ Публикует OrderComplete event

Эвенты координируют, но есть orchestrator для complex logic

Conclusion

Orchestration: Control-centric, подходит для complex workflows с чёткой логикой.

Choreography: Event-centric, подходит для scalable, loosely-coupled систем.

Hybrid: Mix обоих для баланса между контролем и гибкостью.

Системный аналитик должен выбрать подход на основе complexity, scalability requirements и team структуры.