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

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


👉 Принцип работы:
1. Клиент отправляет запрос оркестратору
2. Оркестратор вызывает Сервис 1, ждёт ответа
3. Оркестратор передаёт результат работы Сервиса 1 в Сервис 2, ждёт ответа
4. Оркестратор передаёт результат работы Сервиса 2 в Сервис 3, ждёт ответа
5. Оркестратор собирает итоговый ответ и возвращает клиенту (на картинке к посту - это API Gateway).

Сервисы не знают друг о друге.
Они знают только Оркестратора.

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



👉 Когда применяется:
• Когда важен строгий порядок вызова сервисов
• Когда нужна централизованная обработка ошибок и компенсирующие транзакции
• Когда бизнес-процесс сложный и его надо видеть целиком — оркестратор позволяет централизированно следить за логикой выполнения сложного алгоритма



👉 Паттерны проектирования микросервисов, где есть оркестратор:

✅ Saga (оркестрация)
Длинная транзакция разбивается на шаги.
Каждый шаг выполняет отдельный микросервис.
Оркестратор вызывает каждый сервис по очереди.
Если шаг падает — оркестратор запускает компенсирующие транзакции в обратном порядке.

Пример для Интернет-магазина:

Заказ оформлен → списать деньги → зарезервировать товар → передать в доставку.

❌ Если доставка недоступна — вернуть резерв → вернуть деньги

✅ Process Manager
Расширенный вариант Saga.
Оркестратор хранит состояние процесса и может обрабатывать более сложные ветвления — не только линейную цепочку, но и условия, параллельные ветки, таймауты.



👉 Инструменты:
▫️ Camunda — BPM-движок, оркестрация на основе BPMN-схем, есть визуальный редактор
▫️ Apache Camel — интеграционный фреймворк, классика для оркестрации в enterprise
▫️ Temporal — современный инструмент для оркестрации распределённых workflow,
▫️ AWS Step Functions — облачная оркестрация от Amazon, описание через состояния
▫️ и другие.


👉 Плюсы и минусы:
✅ Логика процесса видна в одном месте — легко отлаживать и менять
✅ Централизованная обработка ошибок
✅ Проще трассировать и мониторить
🚩 Оркестратор становится точкой отказа
🚩 Все сервисы завязаны на оркестратора — если он меняется, затрагиваются все
🚩 При большом количестве процессов оркестратор превращается в «умный монолит»


Полезные материалы:
🔗 Camunda и BPMN в микросервисах: успешный кейс для оркестрации процессов техподдержки


По сути оркестрация — это про централизованный контроль и предсказуемость

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


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

📱 Tg | 💙 ВК | 💬 Max

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

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

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


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

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

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

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

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

▫️ Как только Сервис 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

📱 Tg | 💙 ВК | 💬 Max

🧡 [6–9 июня] Хореография и оркестрация микросервисов: открытый практикум для аналитиков 🧡

В простых задачах всё понятно:
Frontend → Backend → БД.

Но в распределённой архитектуре один процесс может затрагивать сразу несколько сервисов, брокер сообщений и внешние системы.

И аналитику нужно решить:
▫️ кто запускает процесс
▫️ какой сервис отвечает за каждый шаг
▫️ где использовать прямой API-вызов
▫️ где передавать события через Kafka или RabbitMQ
▫️ когда нужна оркестрация, а когда — хореография
▫️ как всё это показать на архитектурной схеме

👉 Этому и посвящён новый практикум по хореографии и оркестрации микросервисов.


На занятии вы разберёте:
✔️ как устроены процессы в микросервисной архитектуре;
✔️ как проектировать оркестрацию и хореографию;
✔️ какую роль играют RabbitMQ и Kafka;
✔️ как отображать взаимодействия сервисов на схемах.

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



🧡 Хореография и оркестрация микросервисов: практика проектирования процессов

📅 Доступ 6 - 9 июня
🕘 Время на обучение: ~4 часа
🎯 Формат: урок в записи, можно пройти в удобное время

🔗 Зарегистрироваться



Это полноформатный вводный урок к практической программе «Проектирование архитектуры» для системных аналитиков, которая стартует 9 июня.

Если к активному осеннему найму хотите увереннее работать с архитектурой, проектировать сложные процессы и претендовать на более сильные позиции — присоединяйтесь 🙌


Вопросы? Пишите @getanalyst или на info@getanalyst.ru.

⭐️ Kafka — что надо знать для работы Системному аналитику ⭐️

Apache Kafka — это распределённая платформа потоковой обработки данных.

Предназначена для публикации, хранения и обработки событий/сообщений в реальном времени.


Основные компоненты:

✔️ Продюсеры (Producers)

1) Генерируют сообщения/события к обработке и отправляют в топики (темы).

2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам.

3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения.

4) Поддерживают режимы отправки:
+ Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения.
+ Асинхронный — отправляет сообщения без ожидания ответа.

5) Могут гарантировать доставку с разными уровнями подтверждения (acks):
+ acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость).
+ acks=1 — подтверждение только от лидера партиции (среднее).
+ acks=all — подтверждение от всех реплик (максимальная надёжность).


✔️ Потребители (Consumers)

1) Подписываются на один или несколько топиков и получают сообщения/события.

2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений.

3) В группе консьюмеров каждый участник обрабатывает свою часть партиций.

4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе.

5) Модели доставки сообщений:
+ at-least-once — как минимум 1 раз, возможны дубликаты.
+ exactly-once — ровно один раз.


✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают


✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций


✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера


✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных


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

📱 Tg | 💙 ВК | 💬 Max

⭐️ Архитектура Kafka: топики, партиции, брокеры, кластеры ⭐️


✔️ Топики (Topics)

1) Логическая категория или тема, куда Продюсеры отправляют сообщения, а Потребители их читают

2) Представляют собой поток сообщений, где каждое имеет: ключ, значение, метаданные

3) Не удаляют сообщения сразу после обработки — данные хранятся в топике в течение заданного времени

4) Могут быть разделены на партиции, что позволяет распределять нагрузку между Продюсерами и Консьюмерами


✔️ Партиции (Partitions)

1) Каждый топик состоит из одной или нескольких партиций (разделов)

2) Сообщения внутри партиции хранятся в строгом порядке (FIFO — "первым пришёл, первым обработался")

3) Разные партиции могут обрабатываться параллельно, что увеличивает производительность Kafka

4) Каждое сообщение в партиции получает уникальный порядковый номер (offset), который используется Потребителями для чтения данных

5) Продюсеры могут отправлять сообщения в партиции автоматически или по определённому ключу (например, все заказы одного клиента попадут в одну партицию)

6) Один потребитель из Группы Консьюмеров читает данные только из своей партиции, что позволяет распределять нагрузку.

7) Повышение надежности обеспечивается через репликацию: выделяют Leader Replica (основная копия данных партиции) и Follower Replica (копирует данные лидера в синхронном или асинхронном режиме)


✔️ Брокеры (Brokers)

1) Хранят топики и их партиции

2) Обрабатывают запросы Продюсеров на запись и Консьюмеров на чтение данных

3) Управляют репликацией партиций для отказоустойчивости

4) Автоматически перераспределяют нагрузку при добавлении новых брокеров в кластер



✔️ Кластер (Cluster)

1) Это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных

2) Использует ZooKeeper или KRaft для координации (назначает лидеров партиций, отслеживает состояние брокеров)

3) Позволяет добавлять новые брокеры без остановки системы

4) Поддерживает автоматическое восстановление при сбоях отдельных узлов


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

📱 Tg | 💙 ВК | 💬 Max

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

Именно это разбираем на практической программе:

💎 Проектирование архитектуры
🗓 Старт — 9 июня

Программа для Middle+ аналитиков, которые хотят выйти на уровень Senior / Solutions Architect.

▫️ Монолит, SOA, микросервисы
▫️ C4 для понятных архитектурных схем
▫️ НФТ для проекта
▫️ REST, GraphQL, gRPC, WebSocket
▫️ Kafka и RabbitMQ для асинхронных интеграций

🎁 Предзапись завершается сегодня:
скидка + мини-курс «Интеграции 4.0» в подарок

➕ Бесплатный вводный практикум "Хореография и оркестрация микросервисов" с 6 по 9 июня

Если думали, решайте сегодня.

👉 Занять место со скидкой

Вопросы: @getanalyst

🔖 База знаний по брокерам для СА: теория + практика + примеры 📚

Делимся с вами подборкой статей, постов и подкастов, которые помогут разобраться с темой:

📌 Брокеры и очереди — общая теория
📚 Очередь сообщений - что это и как работает?
📝 Всё про брокеры: как работают и зачем нужны
📝 Очередь vs Брокер: вопросы с подвохом
📝 Хореография и оркестрация в микросервисной архитектуре
📝 7 вопросов с подвохом по Архитектуре: хореография + понимание брокеров в EDA

📌 Kafka
📙 Официальная документация
📝 8 шагов, чтобы разобраться с Kafka
📝 Kafka - что надо знать для работы СА
📝 Устройство Kafka
📝 Алгоритм работы Kafka
📝 Как встроить Kafka в архитектуру, и главное зачем
📝 Пример использования Kafka - проект #FarmFreshGA
📝 Kafka в деле: подробный разбор примера использования в МСА
🎧 Kafka: что нужно знать Системному аналитику

📌 RabbitMQ
📙 Официальная документация
📝 Брокер RabbitMQ - полный гайд с разбором примера использования в микросервисах
📚 Брокер RabbitMQ - пошаговая практика по развёрыванию и тестированию через CloudAMPQ
🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам

📌 Постановки задач / ТЗ
📝 Пример реального интеграционного Use Case: с микросервисами, cron и kafka - проект BookingGA
📝 Пример технического Use Case с брокером в микросервисной архитектуре - проект GreenChargeGA



📚 Книги
▫️ Apache Kafka. Потоковая обработка и анализ данных. Гвен Шапира
▫️ Kafka в действии. Дилан Скотт
▫️ Проектирование событийно-ориентированных систем. Бэн Стопфорд (есть в открытом доступе)



Сохраняйте — пригодится для изучения темы с нуля, подготовки к собеседованиям и структурирования знаний 🤝


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

📱 Tg | 💙 ВК | 💬 Max

🟠 Открыли бесплатный доступ к 4-часовой практике по архитектуре 🟣

Не мини-урок на 20 минут и не “послушать про микросервисы в целом”.

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

Что важно понять:
▫️ кто управляет процессом
▫️ где нужен прямой API-вызов
▫️ где лучше использовать RabbitMQ или Kafka
▫️ как распределить ответственность между сервисами
▫️ чем хореография отличается от оркестрации на практике
▫️ как показать это на архитектурной схеме


🧡 Хореография и оркестрация микросервисов
📅 Только до 9 июня (вт)
🕘 4 часа практики

👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика

🔗 Забрать бесплатный доступ*

*Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно.


Продуктивной практики! 🧡

⚡ Все говорят про AI-агентов. Но что это значит для аналитика? 🤖

Давайте разберёмся.


👉 Чем агент отличается от общения с AI в чате

Вы пишете промпт в чат и получаете ответ.
Новое сообщение — новый ответ.
Любое новое действие = написать новое сообщение.
Это простое общение с генеративным AI.
Это не AI-агент.

AI-агент — это когда модель сама решает, что делать дальше.

Получила задачу → выбрала инструмент → выполнила шаг → посмотрела на результат → решила, что делать следующим шагом.

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

Пример простого AI-агента:
1. Говорим агенту «проверь все открытые задачи в Jira и сформируй отчёт».
2. AI-агент сам заходит в Jira, сам фильтрует, сам структурирует, сам пишет отчёт.
3. Мы получаем итоговый результат.

🕓 Что ещё круче обычного диалога с AI — AI-агент может запускаться без нашего участия, а по событию или по расписанию.



👉 Из чего состоит агент — минимум, который надо знать:

▫️ LLM — мозг.
принимает решения, генерирует текст

▫️ Tools – инструменты:
поиск в интернете, запросы к API, работа с файлами, выполнение кода

▫️ Memory — память:
краткосрочная (контекст сессии) и долгосрочная (база знаний, векторное хранилище)

▫️ Оркестратор — логика:
в каком порядке запускать шаги, как обрабатывать ошибки



👉 Почему аналитику важно изучать как работают AI-агенты и как их создавать

Потому что агент — это не просто разработческая история, а архитектурная.

Когда бизнес говорит «хотим автоматизировать обработку заявок через ИИ», то аналитик должен уметь ответить на вопросы:

▫️ Какие инструменты нужны агенту? (доступ к каким системам)
▫️ Где граница автономии: что агент решает сам, что эскалирует человеку?
▫️ Как логировать действия агента для аудита?
▫️ Что происходит при ошибке на одном из шагов?
▫️ Кто и как валидирует результат работы AI-агента?

Это требования. И их кто-то должен написать.


👉 Паттерны проектирования AI-агентов:

▫️ ReAct — агент чередует «думаю» и «делаю», объясняя свои шаги

▫️ Plan & Execute — сначала строит план целиком, потом выполняет

▫️ Multi-agent — несколько агентов с разными ролями: один ищет, другой анализирует, третий пишет итог

▫️ Human-in-the-loop — агент останавливается и ждёт подтверждения на критических шагах

Последний паттерн обязателен в любой системе, где агент влияет на реальные данные или деньги. Если этого нет в архитектуре — это не фича, это баг, который ещё не случился.



👉 Где строят агентов

▫️ n8n — визуальный конструктор, схема агента собирается по аналогии с bpmn.

▫️ Claude Cowork — даёшь цель, агент сам работает с твоими файлами и приложениями на компьютере, возвращает готовый результат. Для нетехнических специалистов.

▫️ Claude Code — то же, но для разработчиков и вайбкодеров: работает в терминале, читает весь код проекта, пишет и редактирует файлы, запускает тесты, итерирует — всё через естественный язык.

▫️ LangChain / LangGraph — фреймворки для разработчиков, здесь реализуют ReAct и Multi-agent. Аналитику знать детали необязательно, но понимать структуру — полезно.



AI-агенты — это новый класс систем, которые надо уметь проектировать.

Аналитик, который понимает агентную архитектуру — это уже новый уровень в профессии.


#AI_for_analysts

📱 Tg | 💙 ВК | 💬 Max

🎷 Оркестрация микросервисов: от схемы к требованиям 🎷

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

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

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

🔗 Подробная теория



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

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

2. Web-приложение отправляет API-запрос на Backend, в API Gateway.

POST .../orders

3. API Gateway маршрутизирует запрос на Оркестратор.

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

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

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

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

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

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

10. Оркестратор вызывает сервис Уведомлений, чтобы отправить покупателю уведомление (e-mail или SMS) о подтверждении заказа и деталях доставки.

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

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



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



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


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

📱 Tg | 💙 ВК | 💬 Max