Rate this post

Если вы постоянно слышите про Apache Kafka, но до конца не понимаете, что это и почему о ней так много говорят — эта статья наконец расставит всё по местам.
Мы разберём Kafka на реальных примерах, используя вымышленное e-commerce приложение StreamStore, и посмотрим, как Kafka решает боль, с которой сталкиваются почти все современные архитектуры.

Проблема: когда микросервисы превращаются в домино

В нашем StreamStore есть микросервисы:

  • заказы

  • платежи

  • склад

  • уведомления

  • аналитика

Когда пользователь оформляет заказ, в системе запускается целая цепочка действий:

  • уменьшается складской остаток

  • клиенту отправляется email

  • создаётся счёт

  • обновляется панель продаж

  • обновляется статистика выручки

Мы — маленький стартап, поэтому в начале делаем всё максимально просто:
микросервисы напрямую вызывают друг друга.

Order → Payment → Inventory → Notification → Analytics

И всё работает… пока не наступает Чёрная Пятница.

Внезапно:

  • приложение начинает тормозить

  • пользователи сидят перед вечными загрузками

  • сервисы падают под нагрузкой

  • продажи теряются каждую минуту

  • архитектура превращается в хаос

Что же произошло?

Почему прямое взаимодействие микросервисов ломается

1. Жёсткая связность

Если сервис платежей падает — весь процесс оформления заказа встаёт.

2. Синхронные вызовы

Каждый шаг ждёт следующий — как длинная цепочка домино.
Один медленный сервис → всё замедляется.

3. Точки отказа

10 минут простоя склада = 2 часа накопившихся заказов.

4. Потерянные данные

Аналитика упала на час → потерян час данных о продажах.

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

Решение: Kafka как “почтовое отделение” системы

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

Kafka = почтовая служба для микросервисов:

  • Отправитель (Order Service) кладёт “пакет” (event)

  • Почта (Kafka) принимает и сохраняет его

  • Получатели (Inventory, Notification, Payments и т.д.) забирают, когда готовы

Никакого ожидания. Никаких прямых вызовов. Никаких зависаний.

Producers и Events: как данные попадают в Kafka

Order Service становится producer-ом.
Он создаёт событие:

“Создан заказ: клиент X, товары Y, детали Z.”

И отправляет его в Kafka.

Событие — это обычный объект с ключом, значением и метаданными.

После отправки сервис не ждёт, получил ли кто-то это сообщение.
Он просто продолжает работу.

Где хранятся события? Kafka Topics

Kafka сортирует события в топики — как отдельные очереди в почте:

  • orders

  • payments

  • inventory

  • notifications

Ничего не складывается в одну огромную “кашу”.
Топики создаёте вы — как схемы в базе данных.

Consumers: сервисы, которые реагируют на события

Когда в orders появляется событие “создан заказ”, подписчики получают его:

  • Notification Service → отправляет письмо

  • Inventory Service → уменьшает остаток

  • Payment Service → создаёт счёт

  • Analytics Service → обновляет статистику

Каждый работает в своём темпе, независимо от других.

Kafka — это база данных? Нет, и вот почему

Kafka сохраняет события, но не заменяет основную БД.

Например:

  • Склад обновляет остатки в базе

  • Но также создаёт событие изменения склада, чтобы:

    • сработали оповещения о низком остатке

    • сервис авто-дозаказа сделал новый заказ

    • аналитика могла работать в реальном времени

Kafka — это не состояние.
Kafka — это история изменений.

Real-Time обработка: Kafka Streams

Некоторым приложениям нужно постоянное обновление:

  • realtime панель продаж

  • локации водителей в Uber

  • постоянная проверка порогов склада

Для такого Kafka предлагает Streams API — потоковую обработку событий.

Streams работают не «по одному», а непрерывным потоком.

Масштабируемость Kafka: Partitions

Kafka масштабируется благодаря партициям.

Представьте:
в почтовом отделении добавили больше сотрудников в каждый отдел:

  • письма в Европу → сотрудник A

  • письма в США → сотрудник B

  • письма в Азию → сотрудник C

В Kafka так же:

  • orders-eu

  • orders-us

  • orders-asia

Разные продюсеры могут писать в разные партиции параллельно.

Ускоряем: Consumer Groups

Если один сервис не успевает обрабатывать поток данных — запускаем несколько его копий.

Kafka автоматически:

  • объединяет их по group ID

  • распределяет партиции между ними

  • перераспределяет нагрузку, если одна копия падает

Это обеспечивает горизонтальное масштабирование «вширь».

Где физически хранится информация? Kafka Brokers

Kafka работает на кластере серверов — broker-ов.

Брокеры:

  • хранят данные на дисках

  • принимают запросы

  • реплицируют данные друг другу

  • обеспечивают отказоустойчивость

Kafka хранит события столько, сколько вы укажете в retention policy.

Это ключевое отличие от обычных очередей, которые удаляют сообщения после обработки.

Kafka vs классические очереди: Netflix vs ТВ

Обычная очередь — как телевизор:

  • смотрите то, что показывают

  • в тот момент, когда показывают

  • пропустили — всё, потеряли

Kafka — как Netflix:

  • смотрите что хотите

  • когда хотите

  • в своём темпе

  • можно пересматривать

Именно эта гибкость делает Kafka уникальной.

Прощай, ZooKeeper: привет, KRaft

Раньше Kafka использовала ZooKeeper для координации.
Сегодня современные версии используют KRaft, встроенную систему управления.

Это упрощает конфигурацию и уменьшает количество зависимостей.

Вывод

Kafka — это не просто message broker.
Это мощная платформа для потоковой обработки данных, которая решает:

  • жёсткую связность

  • проблемы синхронных вызовов

  • потерю данных

  • невозможность анализировать данные в реальном времени

  • проблемы масштабирования

Если эта статья помогла вам наконец понять Kafka — поделитесь ею с коллегой, которому она тоже пригодится.