Kafka: архитектура и базовые принципы — Часть 1

Если сегодня открыть архитектуру практически любой крупной IT-компании — Aviasales, Uber, Avito, Яндекс или Ozon — почти наверняка где-нибудь между микросервисами окажется Kafka. Иногда аккуратно, иногда как тот самый провод под столом, который все боятся трогать, потому что «оно же работает».

Kafka давно перестала быть просто брокером сообщений и стала фундаментом современных распределённых систем.

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

Что такое Kafka

Apache Kafka — это распределённая платформа потоковой передачи событий (Distributed Event Streaming Platform).

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

Но этим её возможности не ограничиваются.

Kafka умеет:

• передавать данные между микросервисами;
• хранить события длительное время;
• масштабироваться практически бесконечно;
• выдерживать миллионы сообщений в секунду;
• восстанавливаться после отказа серверов.

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

Почему не HTTP?

Представим интернет-магазин.

Когда пользователь оформляет заказ, необходимо:

• списать деньги;
• уменьшить остаток товара;
• отправить письмо;
• начислить бонусы;
• обновить аналитику;
• отправить уведомление в мобильное приложение.

Самое очевидное решение выглядит так – сервис заказов вызывает каждый сервис напрямую:

Поначалу всё отлично. Демка работает, бизнес доволен, никто ещё не произнёс слово «интеграция» с болью в голосе. Но проходит полгода и появляются ещё сервисы:

Получается классическая проблема сильной связанности (tight coupling): один сервис знает слишком много о чужой жизни и начинает вести себя как слишком любопытный сосед.

Любое изменение затрагивает множество сервисов. Любая временная недоступность одного из них начинает ломать всю систему. И дай Бог в вашей компании будут люди, которые смогут в Make architecture great again и смогут внедрить Kafka.

Теперь сервис заказов больше никого не вызывает. Он просто публикует событие, а уже остальные сервисы самостоятельно подписываются на это событие. Пусть вас не пугает эта схема – мы дальше подробно остановимся на том как это работает на самом деле в следующих частях данного цикла.

Получается несколько преимуществ сразу.

1. Сервис заказов вообще не знает, кто будет читать событие.
2. Можно добавить новый сервис без изменения существующего кода.
3. Если один из сервисов временно недоступен, остальные продолжают работать.

Именно эта слабая связанность сделала Kafka настолько популярной.

Когда Kafka действительно нужна

Очень часто Kafka пытаются использовать абсолютно везде. Это ошибка.

Kafka отлично подходит, если:

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

Например:

• оформление заказов;
• банковские транзакции;
• логирование;
• аналитика;
• телеметрия;
• IoT;
• стриминг.

Когда Kafka только усложнит систему

Если у вас:

• небольшой интернет-магазин;
• CRM на 20 пользователей;
• простой REST API;
• монолит без высокой нагрузки,

Kafka почти наверняка окажется лишней.

Во многих случаях достаточно RabbitMQ или вообще обычной PostgreSQL.

Использование Kafka оправдано тогда, когда появляются реальные проблемы масштабирования, а не «на будущее».

Как думать о Kafka

Большинство новичков представляет Kafka как очередь.

На самом деле это неверная модель.

Правильнее думать о Kafka как о распределённом журнале событий.

Представьте длинный лог-файл.

----------------------------------
User Registered
Order Created
Payment Success
Email Sent
Product Viewed
Review Added
----------------------------------

Никто ничего не удаляет.

Новые записи просто дописываются в конец.

Всегда.

Это и есть основная идея Kafka.

Первое фундаментальное отличие от очередей

В классической очереди сообщение исчезает после обработки.

Queue

[A][B][C]

Consumer читает A

Queue

[B][C]

В Kafka всё иначе.

Log

A
B
C
D
E
F
G

Consumer лишь говорит:

Я прочитал до сообщения №15342.

Само сообщение остаётся.

Поэтому другой Consumer может прочитать его позже.

Или тот же Consumer может начать читать историю заново.

Именно это делает возможными:

• Event Sourcing;
• Replay;
• Stream Processing;
• CDC;
• аналитические системы.

Первые термины Kafka

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

Broker

Broker — это обычный сервер Kafka.

На нём лежат данные.

На нём работают клиенты.

На нём хранятся журналы сообщений.

+-----------+
| Broker 1  |
+-----------+

Обычно брокеров несколько.

Broker 1
Broker 2
Broker 3

Чем больше брокеров — тем больше производительность и выше отказоустойчивость.

Topic

Topic — это логическая категория сообщений.

Например:

• orders
• payments
• notifications
• users

Producer пишет сообщение не на конкретный сервер.

Он пишет в Topic.

Где именно окажется сообщение — Kafka решит сама.

Producer

Producer — приложение, которое отправляет сообщения.

Это может быть:

• backend;
• мобильное приложение;
• касса магазина;
• банкомат;
• IoT-датчик.

Producer
   ↓
 Kafka

Consumer

Consumer — приложение, которое читает сообщения.

Например:

Kafka
  ↓
Email Service

или

Kafka
  ↓
Analytics

или

Kafka
  ↓
Recommendation Engine

Producer и Consumer вообще ничего не знают друг о друге.

Они знают только Topic.

На этом месте остановимся. Базовые сущности уже на столе, теперь можно перестать смотреть на Kafka как на «ещё одну очередь» и перейти к механике.

В следующей части разберём Partition — механизм, который позволяет Kafka масштабироваться, не превращая порядок сообщений в лотерею. Затем рассмотрим Consumer Groups и соберём первую полноценную архитектуру Kafka.