🧡 [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