🕺Хореография микросервисов - детальный разбор с примером 💃

👉 Хореография — это архитектурный шаблон взаимодействия микросервисов, в котором бизнес-процессы реализуются как цепочка независимых реакций на события.


Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.


👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.


👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды


🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:

1. Приложение отправляет запрос на API Gateway

2. API Gateway проверяет авторизацию и маршрутизирует заказ в Сервис Заказов

3. Сервис Заказов:
+ обновляет статус заказа в БД на "Ожидает оплаты"
+ публикует событие в Брокер Kafka - "Заказ подтверждён"
❗️ Деньги с пользователя не списаны

4. Сервис Заказов возвращает ответ на API Gateway.

5. API Gateway возвращает ответ с инфо о заказе на web-приложение, где показываем пользователю сообщение "Заказ принят"❌


🟡 Асинхронная работа - хореография:
Запускается параллельный поток событий. Frontend и пользователь могут идти по своим делам.

1. Сервис Платежи (далее - С) читает событие "Ожидает оплаты" из Kafka и запускает логику списания денег с карты пользователя.

2. Платежи публикует событие "Платеж упешен" в Kafka.


Параллельно:
----
3А. С Уведомлений читает событие "Платеж упешен" из Kafka и отправляет push+sms пользователю❌

3C. С Заказов читает событие "Платеж упешен" из Kafka и меняет его статус в своей БД на "Оплачен"❌

3B. Рестораны читает событие "Платеж упешен" и проверяет:
+ кухня не перегружена?
+ доступность блюд?
+ время работы и т.п.

4. Если ок, то С Рестораны публикует событие "Заказ подтверждён".
----

Параллельно:
4А. С Уведомлений читает "Заказ подтверждён"..❌
4C. С Заказы читает "Заказ подтверждён"..❌
4B. С Курьеры читает "Заказ подтверждён"..


Далее на картинке к посту 🖼

❌ - конец процесса

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

Последние месяцы я минимум по 10 часов в неделю учусь - лучший технический университет США прокачивает меня в Generative AI. На прошлой неделе, например, разбиралась с библиотеками в Python для обучения LLM-моделей и работы с NLP.

А параллельно с этим я работаю над AI-Акселератором для аналитиков.

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


Программа по AI для аналитиков — это не база про ChatGPT.
Я собираю весь тот опыт, который получила за последние 3 года учёбы и работы:
+ принципы работы нейросетей,
+ что надо знать, прежде чем их использовать,
+ как безопасно встроить AI в свою работу,
+ инструменты,
+ развертывание локальных LLM,
+ интеграции по API,
+ автоматизация процессов через low code,
+ где AI реально экономит время, а где только создаёт иллюзию продуктивности.

Мой перфекционист в восторге от содержания 🫠


Для меня это особенно вдохновляющий период в GetAnalyst:

🔹 Мне удалось привлечь экспертов из США, которые делают ревью материалов по отдельным урокам и помогают докрутить контент

🔹 В курсе будут занятия, записанные специально для GetAnalyst экспертом по AI из Стэнфорда

🔹 Много практики, разбор ошибок и лайфхаки


Этот год я сознательно посвятила обучению, чтобы сместить фокус на AI-проекты и работать с новыми клиентами на разработку.
И сейчас искренне рада, что могу делиться своим опытом с вами.

И чем глубже во всё это погружаюсь, тем сильнее вижу - направление всё ещё очень не развито. Здесь ещё можно успеть занять своё место, пока рынок только формируется, и стать передовиком в транформации и улучшении своей профессии.


Так что да, я сейчас тону в презентациях, схемах, записях…

Но именно это зажигает искру и даёт ощущение сильной мотивации и радости 💙

📩 Kafka vs RabbitMQ: что выбрать? Детальное сравнение 📩

В распределённых системах Kafka и RabbitMQ очень часто ставят в один ряд.

В результате Kafka пытаются использовать как обычную очередь, а RabbitMQ — как платформу стриминга.

❗️ Хотя на самом деле они решают принципиально разные задачи.


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

📌 Какую задачу решает каждый инструмент

✅ Apache Kafka — платформа стриминга событий

Kafka — это распределённый лог событий, а не “очередь сообщений”.

Её сильные стороны:
+ приём большого потока событий
+ real-time аналитика
+ хранение всей истории изменений, а не только текущего состояния (event sourcing)
+ хранение событий как “системы записи”
+ горизонтальное масштабирование

Проще думать о Kafka так:
“бесконечный лог, где события можно читать дважды", а не “очередь, из которой забрали и забыли".


✅ RabbitMQ — брокер сообщений для распределения работы

RabbitMQ — это классический message broker, который отлично подходит для:

+ надёжной доставки сообщений
+ сложной маршрутизации
+ распределения нагрузки между воркерами
+ request/response и RPC-паттернов
+ транзакционного обмена сообщениями.

Образно: умный почтальон, который доставит нужное сообщение нужному потребителю и точно проследит, было ли оно обработано.



📌 Архитектура и модель сообщений

Модель хранения:
✅ Kafka — персистентный лог, сообщения не “исчезают” после чтения, можно переиспользовать.
✅ RabbitMQ — классическая очередь: сообщение забрали → его в очереди больше нет (если не использовать DLQ, плагины и т.п.).

Повторная обработка сообщений:
✅ Kafka — поддержано “из коробки”
✅ RabbitMQ — неестественно, приходится докручивать с помощью плагинов (DLQ, повторные публикации и т.д.).

Порядок сообщений:
✅ Kafka → порядок гарантирован внутри партиции (этого достаточно для большинства event-driven кейсов)
✅ RabbitMQ → порядок гарантирован в рамках одной очереди, но если несколько конкурирующих потребителей – порядок быстро ломается

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



📌 Типичные ошибки

❌ 1. Использовать Kafka как обычную очередь
Kafka плохо подходит для:
+ коротких задач “выполнил и забыл”;
+ простых приложений.
Результат: переусложнённая инфраструктура, дорогая поддержка и кластеры “на всякий случай”.

❌ 2. Пытаться сделать из RabbitMQ “стриминг-платформу”
RabbitMQ начинает "задыхаться", если:
+ события нужно хранить долго
+ важна возможность повторного чтения сообщений
+ несколько независимых потребителей должны прочитать одни и те же данные
+ поток вырастает до миллионов событий.

❌ 3. Игнорировать требования к порядку сообщений
В Kafka порядок сохраняется внутри партиции.
В RabbitMQ порядок только внутри очереди, и то, пока один потребитель.
Как только в систему добавляют несколько потребителей, “красивый” порядок перестаёт совпадать с реальностью.

❌ 4. Использовать Kafka, не понимая consumer groups
Consumer group в Kafka:
+ даёт параллелизм обработки
+ гарантирует, что одну партицию читает только один consumer группы
+ напрямую влияет на сохранение порядка.
Неправильно настроил группы → сам себя лишил гарантий по порядку.

❌ 5. Недооценивать сложность эксплуатации Kafka
Kafka требует:
+ настройки и поддержки кластера
+ планирования партиций
+ стратегии хранения и ретенции данных
RabbitMQ в этом смысле простее в разы.
Использовать Kafka "на всякий случай" в маленьком проекте — дорогое удовольствие.



📌 Когда и что выбирать

👉 Kafka:
+ Стриминг, логи и аналитика в реальном времени
+ Event-driven микросервисы
+ Высокая нагрузка и масштабирование (ожидаете миллионы событий в секунду)
+ Event Sourcing / CQRS
+ Повторная обработка сообщений

👉 RabbitMQ:
+ Фоновая обработка задач/джобов
+ Командный формат сообщений (“сделай X”)
+ Нижкая задержка в обработке задач
+ Request–response поверх очередей
+ Сложная маршрутизация
+ Транзакционный обмен сообщениями (платёжные сценарии, финансовые процессы, процесс обработки заказа в e-commerce)
+ Простая эксплуатация


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