🚦 Всё про брокеры: как работают и зачем нужны 🚥

Брокеры — это посредники в передаче сообщений между системами или сервисами.

Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.


👉 Принцип работы:

1. Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).

2. Сервис 2 в это время может быть перегружен или занят.

3. Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.

4. Брокер сохраняет сообщение и ставит его в очередь к обработке.

5. Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.

По сути брокеры - это временные Базы Данных,

которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы.
НО! Это всё же не БД, хранить в них сообщения до бесконечности не надо.


👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре (хореография),
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.


👉 Брокеры сообщений предлагают два основных шаблона обмена данными:

1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.

2. Публикация-подписка (Publish/Subscribe)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.


Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.

Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.

#АрхитектураGA

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

В микросервисной архитектуре (МСА) есть два основных подхода к управлению процессами между сервисами:
💃 хореография,
🎻 оркестрация.

Суть — несколько микросервисов должны отработать один сквозной сценарий, в правильном порядке и без “потерянных” шагов.



Пример из #AdFlowGA

Разрешение на публикацию объявления — это не просто “всё, публикуемся”.

Это триггер для цепочки действий:
1️⃣ запросить токен ERID для маркировки рекламы,
2️⃣ после этого отправить объявление на публикацию (ВК Реклама / Яндекс.Директ и др.)
3️⃣ запустить учёт бюджета рекламной кампании




С точки зрения архитектуры, этот процесс может быть реализован по-разному:


📌 Хореография
Каждый сервис сам реагирует на события и выполняет свою часть процесса.

Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.

Как это выглядит в AdFlowGA (примеры событий):

+ Срабатывает событие → publication.allowed

+ publication.allowed → МС Маркировки запрашивает ERID и публикует событие → erid.received

+ erid.received → МС Коннектор публикует объявление на площадке → ad.published

+ ad.published → МС Рекламные кампании запускает учёт бюджета

👉 Главное здесь — думать не “кто кого вызывает”, а какие события должны появляться в системе и что должен сделать каждый сервис, когда событие произошло.



📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.

Пример оркестратора “из коробки”: Camunda.

Оркестратор вызывает нужные микросервисы по порядку:
▫️ получить ERID →
▫️ опубликовать на площадку →
▫️ начать отсчет бюджета кампании
и отслеживает их выполнение.

Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.



👉 Что выбрать?

Оба подхода имеют свои преимущества и применяются в зависимости от целей:

💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;

🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.

Сводится к простому: где важна строгая последовательность, а где процесс можно построить как связку независимых шагов, выполняемых асинхронно.


#АрхитектураGA #AdFlowGA

🎻 Оркестрация микросервисов: полный практический гайд + материалы 📚


Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).

👉 Оркестратор:
1. знает какие сервисы вызвать по API (обычно REST / gRPC)
2. в каком порядке
3. работает с условиями, сложными алгоритмами
4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны

Так сложный процесс превращается в цепочку задач. А Оркестратор следит за их выполнением.


👉 Как работает оркестратор
на примере Интернет-магазина:

1. Покупатель оформляет заказ через Web-приложение

2. Web-приложение отправляет запрос в API Gateway
POST .../orders
3. API Gateway маршрутизирует запрос на Оркестратор

4. Оркестратор присваивает id новой операции и вызывает API сервиса заказов

5. Сервис Заказов создает новый заказ в БД.
Результат - в Оркестратор

6. Оркестратор вызывает сервис Склада, чтобы зарезервировать товар

7. Склад подтверждает резерв или сообщает об отсутствии товара.
Результат - в Оркестратор

8. Оркестратор вызывает сервис Доставка для оформления отправления

9. Сервис доставки рассчитывает маршрут и время доставки, оформляет доставку.
Результат - в Оркестратор

10. Оркестратор вызывает сервис Уведомлений для отправки email/SMS о подтверждении заказа и доставке

11. Сервис Уведомлений выполняет отправку.
Результат - в Оркестратор

12. Оркестратор отправляет итоговый ответ в API Gateway, откуда он возвращается в Web-приложение


🔹Оркестратор вызывает API сервисов и ждёт ответ.
🔹Он может сохранять состояние процесса, чтобы возобновить его при сбое.
🔹 Если что-то идёт не так, оркестратор выполнит компенсации - откатит выполненные шаги.


📦 Готовые решения для оркестрации:
▫️ Camunda – BPM-движок с поддержкой диаграмм процессов (BPMN)
▫️ OpenBPM - аналог Camunda в России


📚 Подборка материалов:
🎧 Camunda и BPMN в микросервисах для процессов техподдержки
📝 Оркестрация и API Gateway – разбор реального примера
🎧 Внедряем Camunda: обзор и моделирование BPMN


#АрхитектураGA

А так…. все ссылки собрала для вас тут 🙃


Разрешено в РФ
✅ VK
✅ Мессенджер Max
✅ RuTube
✅ Сайт GetAnalyst.ru


В нестабильной зоне - Telegram:
⚠️ GetAnalyst Навыки - продвинутый уровень
⚠️ Для начинающих в СА и БА
⚠️ Чат сообщества
⚠️ Подкаст (здесь ссылки на все аудио-площадки)


Доступно под VPN:
🔺 Instagram
🔺 LinkedIn
🔺 YouTube


👉 Подписывайтесь сейчас, чтобы не терять доступ к базе знаний GetAnalyst и продолжать ежедневное обучение 🚀


С добром и заботой,
Екатерина Ананьева,
и команда GetAnalyst 🤍

Мы умеем быть разными: мягкими, сильными, умными, красивыми — и гораздо глубже, чем просто внешность.

Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.

С 8 марта, дорогие девушки!

Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️

Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙

📌 7 вопросов с подвохом по Архитектуре: хореография микросервисов + понимание брокеров в EDA 📌


1️⃣ Когда хореография микросервисов хуже оркестрации?

✔️ Сложные линейные бизнес-процессы с кучей условий (сложный онбординг, платежные цепочки, обращения тех поддержки и др)

✔️ Надо явно видеть шаги процесса и управлять им

✔️ Когда важны SLA и время на выполнение шагов

В таких случаях удобнее, когда:
+ есть компонент, который явно хранит состояние процесса
+ видно “шаги” и переходы по ним
С этим помогает оркестрация.



2️⃣ Сервис записал данные в свою БД, но упал до публикации события. Что произойдёт в хореографии и как это чинить?

Многие говорят «ретраи к брокеру» (повторные запросы) и всё. Но это лишь часть ответа.

Ситуация:
Обработка данных на микросервисе прошла, но событие в брокер не опубликовано → остальные сервисы никогда не узнают об изменении.

Решение:
Transactional Outbox / Outbox pattern:
В одной транзакции к БД с бизнес-данными пишем запись в специальную outbox-таблицу.

Отдельный воркер (фоновый процесс) читает из outbox и публикует событие в брокер, с ретраями.

Также иногда используют Change Data Capture (CDC) по БД - отслеживание изменений.



3️⃣ Как в хореографии реализовать шаг, который зависит сразу от двух событий из разных сервисов?

Например: бонус начисляем только если есть "пользователь зарегистрирован" и "оплачен первый заказ"?

Нужен агрегатор/process manager (отдельный сервис/Kafka Streams и др), который:
+ хранит состояние двух параметров: userId - , orderId
+ пришло первое событие — пометили “жду второе”
+ пришло второе — выполняем действие (начисляем бонус)

Это уже кусочек оркестрации, спрятанный внутри одного сервиса.

Также нужно учесть что делать, если второе событие не пришло.



4️⃣ Как в хореографии реализовать таймаут шага?
Например, оплата должна пройти за 15 минут, иначе заказ отменяем.

Используется process manager / timeout-сервис / scheduler:

1. При старте процесса публикуется событие "оплата началась"

2. Параллельно где-то создаётся “таймер” на 15 минут (например, Cron)

3. Если за 15 минут не пришло событие "Платеж успешен" / "Ошибка оплаты":
+ таймер генерирует событие "Ошибка таймаута по платежу",
+ другие сервисы реагируют: отменяют заказ, снимают резерв и т.п.

Важно понять: управление интервалами времени в работе процесса не решается «само по себе» брокером — нужен компонент, который хранит состояние ожидания.


5️⃣ Биллинг слушает событие "Заказ оплачен" и должен списать деньги ровно один раз. Любое сообщение может прийти дважды. Как вы гарантируете отсутствие двойного списания?

Ошибочный ответ:
«брокер гарантирует доставку ровно один раз»

Реализуем проверки на уровне потребителя события:
+ идемпотентность операций: бизнес-ключ (orderId + paymentId)
+ уникальность в БД на этот ключ
+ таблица processed_messages с messageId и состоянием.


6️⃣ Можно ли построить систему только на хореографии, без оркестрации?

В теории — можно, но:
+ всё равно появятся сервисы-агрегаторы / процесс-менеджеры / scheduler’ы, которые управляют процессами
+ как только один сервис начинает хранить состояние процесса и ждать другие события, он выполняет роль локального оркестратора.

Более правильный ответ: в реальных системах почти всегда смесь подходов хореографии и оркестрации.


7️⃣ Вы добавляете новый микросервис в существующую хореографию процессов. Как сделать так, чтобы он не поломал остальных, когда начнёт слушать существующие события?

Новый сервис должен быть пассивным наблюдателем:
+ слушает существующие события без изменения процесса их работы
+ никакие его действия не должны влиять на текущие цепочки по процессам

Важно:
+ не добавлять обязательные поля в существующие события (сообщения), которые отправляем в брокер
+ не менять JSON (формат сообщений) уже используемых событий
+ если нужно другое поведение — вводить новые типы событий, а не менять старые.


Какие ещё вопросы по брокерам и хореографии вы встречали на собеседованиях на СА? Делитесь в комментариях ✍️


#АрхитектураGA