Взаимодействие через Kafka - Краткий обзор

Архитектура взаимодействия

┌─────────────────────────┐           ┌──────────┐         ┌──────────────────────┐
│  Основное приложение    │ ───────>  │  Kafka   │────────>│ Микросервис аналитики│
│ (Producer and Consumer) │ События   │          │ События │    (Consumer)        │
└─────────────────────────┘           └──────────┘         └──────────────────────┘
         ▲                                                          │
         │                                                          │
         │                  ┌──────────┐                            │
         └──────────────────│  Kafka   │<───────────────────────────┘
          Агрегированные    │          │   Агрегированные данные
             данные         └──────────┘    (каждую 1 минуту)

Прямой поток: Основное приложение → Kafka → Микросервис аналитики

1. Отправка событий (Producer)

Основное приложение отправляет события в Kafka при действиях пользователей:

2. Обработка событий (Consumer)

Микросервис аналитики подписывается на топики и активно запрашивает (polls) события из Kafka:

Как это работает:

• Kafka использует pull-модель (не push): Consumer сам запрашивает данные, а не получает их автоматически
• Микросервис периодически опрашивает (poll) Kafka на наличие новых сообщений в подписанных топиках
• Kafka распределяет события по партициям на основе ключа
• Consumer читает события из назначенных ему партиций
• Статистика обновляется в оперативной памяти микросервиса (ConcurrentHashMap)
• Kafka отслеживает offset (позицию чтения) для каждого consumer

Важно: Kafka не отправляет данные автоматически - микросервис сам запрашивает их через метод poll()

Обратный поток: Микросервис аналитики → Kafka → Основное приложение

1. Агрегация данных

Важно: Это два разных процесса в микросервисе аналитики:

1. Постоянное чтение событий (см. раздел "Обработка событий" выше):
   • Микросервис постоянно запрашивает (polls) события из Kafka
   • Каждое событие обрабатывается сразу и обновляет статистику в памяти
   • Это происходит в реальном времени, не раз в минуту
2. Периодическая агрегация (каждую 1 минуту):
   • Отдельный scheduled task запускается раз в минуту
   • Агрегирует уже накопленные в памяти данные
   • Отправляет агрегированные результаты обратно в Kafka

Типы агрегированных данных:

• BOOK_STATS - статистика по каждой книге
• SYSTEM_OVERVIEW - общая статистика системы
• POPULAR_BOOKS - список популярных книг

2. Получение и сохранение (Consumer)

Основное приложение также использует Kafka Consumer и активно запрашивает (polls) агрегированные данные из топика analytics.aggregated-stats:

Как это работает:

• Основное приложение подписывается на топик analytics.aggregated-stats
• Consumer периодически опрашивает (poll) Kafka на наличие новых агрегированных данных
• При получении данных основное приложение сохраняет их в БД (таблицы book_analytics, system_analytics)
• Это также pull-модель: основное приложение само запрашивает данные, а не получает их автоматически

Ключевые концепции

Партиционирование

Зачем: Параллельная обработка и гарантия порядка для связанных событий

Как работает:

• Kafka вычисляет партицию: partition = hash(key) % numberOfPartitions
• События с одинаковым ключом попадают в одну партицию
• Гарантируется порядок обработки событий одной книги/пользователя

Пример:

Топик book.views (3 партиции):
Partition 0: [bookId=3] [bookId=6]
Partition 1: [bookId=1] [bookId=1] ← Все события bookId=1 здесь
Partition 2: [bookId=2] [bookId=5]

Consumer Groups

Зачем: Распределение нагрузки между несколькими экземплярами сервиса

Как работает:

• Все consumers в одной группе делят партиции между собой (может быть несколько экземпляров микросервиса или разные сервисы, но в данном случае только один)
• Каждое сообщение обрабатывается только одним consumer из группы
• При падении consumer его партиции перераспределяются

Пример:

Consumer Group: analytics-service-group
- Consumer 1 → обрабатывает Partition 0
- Consumer 2 → обрабатывает Partition 1
- Consumer 3 → обрабатывает Partition 2

Offset

Зачем: Отслеживание позиции чтения, чтобы не потерять сообщения

Как работает:

• Kafka запоминает, какое сообщение уже прочитано
• При перезапуске consumer продолжает с последнего offset
• Гарантирует, что каждое сообщение обработано

Полный цикл данных

1. Пользователь выполняет действие (просмотр, покупка и т.д.)
2. Основное приложение отправляет событие в Kafka (это называется - асинхронно, так как после отправки основное приложение не ждет обработки отправленного сообщения микросервисом аналитики)
3. Kafka сохраняет событие в соответствующем топике и партиции
4. Микросервис аналитики постоянно запрашивает (polls) новые события из Kafka, получает событие и сразу обновляет статистику у себя в памяти (в данном случае у него нет БД, он хранит все в RAM)
5. Каждую 1 минуту отдельный scheduled task агрегирует уже накопленные в памяти данные и отправляет агрегированные результаты обратно в Kafka (в топик analytics.aggregated-stats)
6. Основное приложение постоянно запрашивает (polls) агрегированные данные из топика analytics.aggregated-stats и сохраняет их в БД
7. Админ панель получает статистику через REST API из БД

Топики Kafka

Преимущества подхода

• Неблокирующая обработка - основное приложение отправляет событие и сразу возвращает ответ пользователю, не ожидая обработки аналитики
• Масштабируемость - можно запустить несколько экземпляров микросервиса
• Надежность - Kafka сохраняет события, они не теряются при падении сервиса
• Разделение ответственности - аналитика вынесена в отдельный микросервис
• История данных - агрегированные данные сохраняются в БД для анализа

Мониторинг

Kafka UI (http://localhost:8089) (admin, admin):

• Просмотр топиков и партиций
• Просмотр сообщений
• Мониторинг consumer groups и offsets
• Отслеживание lag (задержки обработки)