Знакомство: зачем шина событий

Вопрос «зачем kafka» честнее отвечать ролями, а не определениями. Первая роль — журнал интеграции: сервисы обмениваются событиями через общий топик, не зная друг о друге; checkout публикует «заказ создан» и не интересуется, кто его слушает. Вторая — буфер на пики: продюсер пишет в лог со скоростью сети, а потребители разгребают в своём темпе; всплеск в пятницу вечером копится в топике, а не роняет вызывающие цепочки. Третья — история для повторного чтения: новый сервис, подключившийся через полгода после запуска потока, вычитывает события с самого начала и восстанавливает состояние без ручной синхронизации из базы. Четвёртая — потоковая обработка: аналитика, агрегаты и фиды собираются из того же журнала, который уже обслуживает продакшен-сервисы, без второго канала доставки. Заметьте общий знаменатель: везде событие — это факт, записанный на диск, а не задача, которую надо раздать и дождаться. Пока ваши данные исчезают после прочтения, все четыре роли недоступны в принципе. Отсюда и порядок изложения курса: сначала механика хранения и адресации, потом продюсер с ключами, потом читатели — на каждом шаге вы будете возвращаться к этим четырём ролям и узнавать их в коде.

Главное различие — судьба сообщения после чтения. В RabbitMQ сообщение маршрутизируется обменником в очередь, доставляется потребителю и после подтверждения удаляется: очередь — это буфер, который обязан опустошаться. В Kafka сообщение дописывается в конец топика и остаётся там до истечения срока хранения — по умолчанию примерно неделю, срок настраивается на топик. Потребитель не забирает сообщение, а читает его по оффсету — номеру позиции в логе — и двигает оффсет сам, отдельно от чтения. Отсюда три практических следствия. Первое: несколько независимых групп потребителей читают один топик в своём ритме, не мешая друг другу, — аналитика не конкурирует с биллингом. Второе: перечитать старые сообщения можно в любой момент — оффсеты крутятся назад, и поток проигрывается заново. Третье: у потребителя появляется измеримое отставание — лаг между последним сообщением и текущим оффсетом, который становится главной метрикой мониторинга. Платит Kafka за это отсутствием маршрутизации: никакого exchange с правилами — продюсер сам выбирает топик и партицию, дальше никаких развилок. Это и есть короткая шпаргалка: если вам нужен один получатель с подтверждением — очередь; если один факт для многих читателей с историей — лог.

Запрос kafka golang в поиске приводит к трём именам, и курс построен на kafka-go — библиотеке от компании segmentio. Её главный козырь — чистый Go: без cgo, без librdkafka, без крестовой компиляции, обычный go build собирает статичный бинарник, который деплоится куда угодно. API самый простой в экосистеме: Writer для записи, Reader для чтения, Admin-клиент для управления — интерфейсы, которые читаются слева направо. Официального клиента Apache Kafka для Go не существует в природе, поэтому выбор — между реализациями: sarama старше всех и умеет больше всего, но его API настолько объёмный, что половина туториалов начинается с боли; franz-go моложе и агрессивнее по производительности, хорош для высоконагруженных потоков; confluent-kafka-go — обёртка над C-библиотекой librdkafka, быстрая, но тянет за собой cgo и усложняет сборку в Docker с musl. Для обучения, типовых сервисов и средних нагрузок kafka-go закрывает всё: на ней и пройдём весь курс, а где у альтернатив потолок — отдельно в конце. Установка библиотеки и локального брокера — третий урок, туда и держим путь. Ничего страшного в этом выборе нет: API, изученный здесь, переносится между клиентами почти один к одному — Writer, Reader, метаданные и ошибки с кодами везде выглядят похоже, меняется только обвязка.

Кейс одной платформы, после которого шина перестала быть дискуссией. Платежи и заказы жили в Postgres, а об интеграции оповещали себя же: после коммита транзакции код дёргал HTTP-эндпоинты биллинга и аналитики. При падении биллинга события терялись молча — письма со статусом «оплата не дошла» собирались раз в неделю. Попытка чинить ретраями добавила дубли: аналитика считала один заказ дважды. Переезд на Kafka решает обе проблемы механикой: событие пишется в лог один раз, до упора — с подтверждением брокера; биллинг и аналитика читают независимо, каждый со своим оффсетом; упавший биллинг после рестарта продолжает с того места, где остановился, а не с того, что не забрал. Через полгода подключили антифрод: он вычитал историю с начала и восстановил картину без выгрузок из базы. Ключевой эффект не в скорости — в том, что потеря события перестала быть вопросом вежливости HTTP-эндпоинта. Отдельно заметьте, что шина здесь не заменила базу: Postgres остался источником правды, Kafka взяла на себя именно доставку событий — этот раздел ответственности проходит через весь курс.

Мнение для архитектурного созвона: пока сервис один, а потребителей события ноль или один, Kafka — лишняя зависимость. Брокер — это не библиотека, а демон с диском, JVM, мониторингом и местом в дежурном чате; монолит вместо него живёт с таблицей событий в Postgres и воркером на горутинах, и это честное решение на годы. Условие переезда конкретное: появились два и больше независимых потребителей одного потока, либо потеря события стоит денег, либо нужно повторное чтение истории. Пока условия нет, добавление Kafka — это минус один вечер на деплой и минус одна нить в дежурстве, а выигрывает строчка в резюме. Сравнение с очередями задач мы уже делали в курсе по RabbitMQ — там же про ack, dead letter и маршрутизацию, которые Kafka из коробки не даёт. Одна оговорка о формате этого курса: песочница сайта не умеет сеть и TCP-сокеты, поэтому kafka-код запускается локально против брокера в Docker, а интерактивы песочницы показывают тематические программы на чистом Go.