Зачем нужен оркестратор в микросервисной EDA-архитектуре и как спроектировать такую систему: разбираемся с помощью BPMN-диаграммы процесса обработки заказа в интернет-магазине.
Что такое оркестрация и хореография и почему это так важно для микросервисов
Одним из главных преимуществ и драйверов использования микросервисной архитектуры – это взаимная независимость микросервисов, т.к. каждый из них является автономным приложением, даже со своим хранилищем данных (паттерн Database per Service). Это позволяет быстрее разрабатывать и разворачивать части большой системы силами разных разработчиков или команд. Однако, микросервис реализует конкретную задачу в рамках большой системы, поэтому итоговую ценность для потребителя приносит слаженная работа всех входящих в нее элементов. В этом и кроется наибольшая сложность проектирования и реализации микросервисной архитектуры, поскольку надо обеспечить согласованную работу различных сервисов в рамках единого бизнес-процесса.
Для этого проектировщику систему следует выбрать стиль коммуникации между сервисами: оркестрацию или хореографию. Оркестрация предполагает наличие единого центра управления, который «дирижирует всем оркестром», например, направляя запросы к различным микросервисам в зависимости от обрабатываемой бизнес-логики. Подобный центр управления отсутствует в хореографическом стиле, где нет явно определенного рабочего процесса, а работа сервисов реализуется реактивно: по реакции на определенный набор событий. Это подходит для сценариев с частым обновлением или заменой одних сервисов на другие. Также хореография подходит для serverless-платформ, когда все части большой системы имеют короткий период жизни и управляются событиями. Однако, хореографический паттерн усложняет развитие большой системы, когда количество микросервисов растет. Кроме того, из-за отсутствия единого центра управления бизнес-логика «размазывается» по всем микросервисам, что усложняет рефакторинг и развитие всей системы. Поэтому для моего традиционного примера с интернет-магазином я выбрала оркестрационный стиль коммуникации между сервисами, что и покажу далее.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 января, 2025
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Практический пример EDA-архитектуры
Итак, как обычно в качестве демо-примера возьмем типичный интернет-магазин. Покупатель может просматривать товары и покупать их, делая заказы. Также покупателю доступны функции управления своими заказами. За управление товарами и поставщиками отвечает Менеджер интернет-магазина, которому также доступен просмотр данных и аналитические операции по выполненным заказам. Оператор склада управляет упаковкой товаров в заказы. Стоимость доставки заказа к покупателю зависит от наличия товаров на разных складах и расчетной протяженности пути, включая внутреннюю логистику (сборку всех товаров в единый заказ) и внешнюю логистику (доставку единого заказа покупателю). При этом необходимо взаимодействовать с внешними системами служб доставки. Также система интернет-магазина формирует для Покупателя и Менеджера уведомления об изменении состояния заказа и направляет их для фактической отправки во внешние системы отправки (TG, почтовый сервер и пр.). Если товары не найден или необходимо подтвердить заказ, Покупателю отправляется уведомление, ответ на которое определяет дальнейший ход процесса. Оплата выполняется через обращение к внешней системе банковского шлюза.
Сперва покажем контекстное окружение проектируемой системы на схеме системного ландшафта С4. Данная диаграмма создана в SaaS-продукте icepanel.io, о котором я рассказываю в новой статье.
На уровне контекста (Context Level) система представлена в виде одного крупного блока, показывающего ее взаимодействие с внешними системами и пользователями. Внутреннее устройство системы с архитектурной точки зрения представляется на следующих уровнях (контейнеров и компонентов), что будет рассмотрено в другой раз. А пока, возвращаясь к вопросу выбора стиля коммуникации между микросервисами для рассматриваемого примера, разделим систему на автономные части по бизнес-задачам.
| Бизнес-задача | Сервис |
| Посмотреть данные о заказах, товарах и поставщиках товары | Сервис Витрина |
| Управлять активными заказами | Сервис Заказов |
| Управлять поставщиками | Сервис Склад |
| Управлять товарами | Сервис Склад |
| Управлять упаковкой товаров в заказ | Сервис Склад |
| Определить время и стоимость доставки | Сервис Доставка |
| Оплатить заказ | Сервис Оплаты |
| Отправить уведомление об изменении статуса заказа | Сервис Уведомлений |
Для этого набора сервисов BPMN-схема процесса обработки заказа по вышеизложенной бизнес-логике выглядит так.
Таким образом, оркестратор, представленный сервисными задачами в пуле «Обработка заказ», берет на себя принятие решений о ходе выполнения всего рабочего процесса, формируя соответствующие события-задачи для следующих сервисов, которые совершенно не зависят друг от друга. Поэтому взаимодействие между ними можно реализовать асинхронным образом, используя брокер сообщений, например, Apache Kafka – платформу потоковой передачи событий, которая отлично реализует принципы EDA-архитектуры (Event Driven Architecture), управляемой событиями.
Разумеется, Kafka поддерживает и хореографический стиль коммуникации микросервисов, выступая средством связи между продюсерами и потребителями событий. Например, в рассматриваемом кейсе событие «Заказ создан», опубликованное сервисом Заказов, потребляется сервисом Склада, события Склада потребляются Доставкой, а сервис Уведомлений подписан на все топики для информирования пользователей о статусе заказа.
Однако, без оркестратора усложняется код интегрируемых микросервисов за счет реализации логики распределения сообщений с разными событиями от одного приложения-продюсера по разным разделам для их обработки разными потребителями. Администратору кластера Kafka придется добавлять новые разделы в топик. А разработчик будет реализовывать сложную логику парсинга потребленных сообщений в коде приложения-потребителя. Это часто случается при изменении структуры данных полезной нагрузки в публикуемом сообщении и добавлении новых сервисов. Например, в рассматриваемом кейсе интернет-магазина может появиться новый сервис таможенной проверки для некоторых товаров или возврата купленных товаров.
Таким образом, оркестратор является еще одним микросервисом в проектируемой системе, который также как остальные, реагирует на события, играя роль как потребителя, так и продюсера для Kafka. Обратной стороной централизованного управления является наличие единой точки отказа – если оркестратор даст сбой, весь рабочий процесс встанет, несмотря на доступность отдельных микросервисов. Это плата за улучшенный контроль и понятность коммуникаций между разными частями большой системы. В заключение отмечу, что оркестровка не лучше и не хуже хореографии: стиль коммуникации микросервисов выбирается на основе тщательного анализа требований к проектируемой системе, возможных рисков и перспектив расширения.
В следующей статье я продолжаю разбирать этот пример и показываю, как с помощью SaaS-продукта icepanel.io описать некоторые точки зрения на архитектуру системы с помощью диаграмм C4. А также рассмотрим, как начальный этап проектирования, т.е. аллокация требований по компонентам системы помогает выбрать подходящие паттерны микросервисной архитектуры. В рассматриваемом кейсе это API Gateway, Database per Service, Shared database, CQRS и Saga.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 января, 2025
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Все эти и многие другие темы архитектуры и интеграции информационных систем разбираются на моем курсе в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
