Шаблоны хореографии и оркестрации

Когда микросервисам необходимо совместно выполнить бизнес-процесс, существуют два основных шаблона координации. Orchestration использует центральный координатор (например, Step Functions), который явно отдаёт команды каждому сервису. При Choreography центрального координатора нет: сервисы прослушивают события и реагируют на них независимо. Понимание того, какой подход и когда использовать, а также когда их комбинировать, — важный архитектурный навык, проверяемый на экзамене SAA-C03.

При orchestration центральный сервис (orchestrator) управляет последовательностью операций. Он вызывает сервис A, ждёт ответа, затем вызывает сервис B и так далее. Orchestrator полностью видит состояние процесса, обрабатывает ошибки и повторные попытки и может принимать решения на основе промежуточных результатов. В AWS каноническим orchestrator является Step Functions: он определяет весь рабочий процесс как конечный автомат и управляет каждым этапом.

При choreography сервисы взаимодействуют через события без центрального координатора. Сервис A завершает свою задачу и публикует событие (например, OrderValidated) в шину событий или топик. Сервис B прослушивает события OrderValidated и обрабатывает платёж, после чего публикует PaymentCharged. Сервис C прослушивает PaymentCharged и отправляет заказ. Каждый сервис автономен и слабо связан с другими: он знает только о событиях, которые потребляет и создаёт, но не о других сервисах.

В AWS основным инструментом orchestration является Step Functions. Для choreography основными инструментами служат Amazon EventBridge (для маршрутизации событий между сервисами с фильтрацией по содержимому), Amazon SNS (для простой рассылки) и Amazon SQS (для обмена сообщениями между сервисами по схеме «точка-точка»). Можно сочетать эти шаблоны: использовать EventBridge для хореографии между ограниченными контекстами разных предметных областей, а Step Functions — для оркестрации этапов внутри одной области.

Orchestration обеспечивает централизованную видимость: история выполнения Step Functions точно показывает, на каком этапе находится рабочий процесс, сколько длился каждый этап и что завершилось ошибкой. Отладка проста. При Choreography видимость распределена между несколькими сервисами и шинами событий: для отслеживания одной бизнес-транзакции необходимо сопоставлять журналы и события множества сервисов. Поэтому системы хореографии активно используют идентификаторы корреляции и распределённую трассировку (AWS X-Ray) для сквозной видимости.

Choreography обеспечивает более слабую связанность: добавление нового сервиса, прослушивающего существующие события, не требует изменений в существующих сервисах. Например, добавление сервиса аналитики, прослушивающего события OrderPlaced, никак не влияет на сервис заказов или платежей. Orchestration создаёт более тесную связанность между orchestrator и всеми вызываемыми им сервисами: добавление нового этапа требует изменения определения конечного автомата, хотя отдельные сервисы остаются изолированными.

Orchestration делает обработку ошибок явной: блоки Catch в Step Functions определяют резервные состояния для каждого типа ошибок, а полная история рабочего процесса показывает контекст сбоя. При Choreography обработка ошибок распределена: каждый сервис должен обрабатывать собственные сбои и при необходимости публиковать событие сбоя, на которое могут реагировать другие сервисы. Реализовать саги (компенсирующие транзакции для отмены выполненной работы при сбое этапа) при choreography значительно сложнее, чем при orchestration.

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

Выбирайте choreography, когда: сервисами владеют разные команды, которые не должны быть тесно скоординированы; система должна позволять добавлять новые сервисы без изменения существующих; события представляют факты, а не команды (например, «OrderShipped», а не «ShipOrder»); либо Вам нужна максимальная масштабируемость, поскольку центральное узкое место отсутствует. Примеры: приём данных для аналитики, рассылка уведомлений, ведение журнала аудита — все случаи, когда несколько независимых потребителей реагируют на одно и то же событие.

В большинстве реальных архитектур AWS используются оба паттерна на разных уровнях детализации. Распространённый гибридный подход: использовать хореографию EventBridge для разделения ограниченных контекстов (например, домен Order генерирует события, а домены Inventory, Payment и Shipping независимо реагируют на них), а внутри домена Payment применять оркестрацию Step Functions для координации этапов внутреннего рабочего процесса оплаты (списание средств, проверка на мошенничество, авторизация, проведение платежа). Это обеспечивает слабую связанность между доменами и при этом сохраняет ясность внутренних процессов.

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

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что оркестрация использует центральный координатор (Step Functions) для явного и наблюдаемого управления рабочим процессом, хореография использует события (EventBridge) для слабой связанности и расширяемости, а в большинстве промышленных архитектур оба паттерна сочетаются на разных уровнях детализации. Далее мы рассмотрим формат экзамена SAA-C03 и стратегию распределения усилий с учётом веса доменов.