Привет, Хабр!
Это вторая часть статьи о Kafka (первая тут). Давайте продолжим разбираться.
Итак, часто тестирование сводится к эмуляции работы сервиса и наблюдением за топиками кафки. Для этого необходимо подключиться к кластеру кафки с теми же правами доступа, что и у вашего сервиса либо сервиса, с которым у вас интеграция (креды для кластера обычно подсказывают коллеги-разработчики, девопсы, тестировщики). Это позволит отслеживать появление записей в нужное время, в правильном топике, с корректным форматом и заголовками. Пространство для тестирования обширно: проверка валидности данных, наличия обязательных полей, структуры, формата, а также заголовков и возможных ошибок в них.
Вот пример подключения с SSL сертификатом в десктоп-приложении (offset explorer):
Как тестировать, если микросервис — producer
Если ваш микросервис является продюсером, задача заключается в выполнении действий, ведущих к записи в Kafka. Необходимо инициировать событие‑триггер, например, авторизацию, чтобы микросервис получил данные, сформировал сообщение и отправил его в топик кафки. Инициируйте триггер, а затем подключитесь к кластеру Kafka, найдите нужный топик и проверьте, появилась ли запись, соответствует ли её формат ожиданиям. Формат ожидаемой записи можно узнать у системного аналитика либо сравнить с существующими записями. Однако примеры из системной аналитики могут оказаться надёжнее, поскольку продюсеры могут отправлять записи разного формата в один и тот же топик.
Если вы — аналитик, посыл к вам — не пренебрегайте, пожалуйста, никакими подробностями: уровни доступа, формат сообщений (заголовки, тело), уникальные заголовки/строки, даже нагрузка (количество партиций и прочее).
Вот краткий чек-лист со схемой:
Важно учитывать логирование, проверяя успешность подключения и записи в Kafka. Оно играет особую роль в тестировании: чем больше данных фиксируется, тем легче будет определить корректность работы сервисов.
Как тестировать, если микросервис — consumer
Если ваш микросервис выступает в роли консьюмера, то вам потребуется эмулировать работу продюсера. Нужно подключиться к Kafka с использованием сертификатов или учетных данных продюсера, затем самостоятельно создать сообщение и отправить его в соответствующий топик. Ваш реальный микросервис-консьюмер обработает эту запись, возможно, сохранит данные в базе и зафиксирует результаты в логах.
Аналогичный чек-лист:
При проверке логов обращайте внимание на возможные ошибки в записи. Если ваш консьюмер читает реальные записи от продюсеров, но игнорирует тестовые, скорее всего, ошибка кроется в ваших действиях. Микросервис не должен игнорировать записи в Kafka без веской причины. Для проверки вы можете скопировать данные, которые уже лежат в топике (от продюсеров или других тестировщиков) и закинуть сообщение ещё раз, только не забудьте добавить заголовки и изменить поля, требующие уникальных значений.
Как тестировать, еслимикросервис — и consumer, и producer
Бывают ситуации, когда один и тот же микросервис одновременно является консьюмером для одного топика и продюсером для другого. В таком случае вам потребуется вручную создать запись в первом топике, чтобы ваш микросервис‑консьюмер смог прочитать её, обработать и отправить новую запись в следующий топик, где её уже будут читать другие реальные сервисы.
В конце статьи будет практическая часть по этому сценарию.
Кстати, Kafka может использоваться не только для передачи данных между сервисами, но и для резервирования внутри одной системы. Например, в одном из проектов Kafka применялась для синхронизации основной и резервной базы данных. Сообщения в топике содержали инструкции по действиям с записями (например, создание, обновление или удаление), а также поля сущности, которые должны быть сохранены/изменены в базе данных. Таким образом обеспечивалась синхронность между основными и резервными базами данных.
Инструменты работы с Kafka
Взаимодействовать с Kafka можно разными способами и инструментами. Я уже упоминала offset explorer, отмечу пару особенностей. В десктопном приложении можно попросить коллегу экспортнуть настройки подключения к кластеру — не придется сверять каждое поле вручную. А еще есть удобная фича — мультисообщения (вкладка Data → зелёный плюс). Можно одной строкой отправить весь JSON, где каждая строка — отдельное сообщение. Отлично для нагрузочного тестирования, если знаешь допустимый RPS сервиса. Единственное, такой способ не подойдёт для реализации с уникальными заголовками, т.к. они заполняются отдельно.
Примерно мультисообщение может выглядеть так:
Далее будут скрины с web kafka ui.
Наконец, практика)
Давайте рассмотрим живой пример. У меня есть небольшой локальный проект с двумя топиками (в каждом — по одной партиции) и микросервис. Он работает как консьюмер для топика event и как продюсер для топика communication.
Суть моего проекта такая: в топик event приходят сообщения с id клиента и типом нотификации, которую следует отправить. Типов нотификаций реализовано два — новая авторизация и смена пароля. Клиент — один, и у него захардкожены номер телефона и email. Сервис вычитывает запись из топика event и на основе полученных данных формирует нотификацию — передает в топик communication json, в котором содержатся канал, адрес и текст для нотификации.
На скриншоте видны топики event и communication.
«_consumer_offsets» — техническое, нам сейчас не понадобится.
Переходим в топик event, на вкладку Messages, сейчас в нем есть пара записей, я настроила подгрузку сообщений как Newest (вверху — самые новые).
Кстати, может быть такое, что при отсутствии сообщений в топике он не отображается в кластере, хотя корректно заведён.
Я нажимаю на «Producemessage», вставляю в value json — id клиента и тип нотификации (в данном случае это изменение пароля). И нажимаю «Produce message» внизу.
Получаю, что сообщение успешно отправлено.
Сервис принимает это сообщение, обрабатывает и формирует json для второго топика.
Проверяем содержимое топика communication, для этого в левом меню возвращаемся на Topics и переходим communication → Messages. Дефолтно подгрузка сообщений настроена на Oldest, не забывайте об этом при тестировании. Появилась ещё одна запись.
Если мы на нее нажмём, то увидим полностью содержимое — сейчас есть value с json-ом для отправки нотификации (подразумевается, что здесь мы можем проверить корректность канала, адреса, типа сообщения, в целом валидность json-а).
В Headers только технический заголовок.
Вернусь в топик event и отправлю еще одно сообщение. На этот раз добавлю еще ключ и заголовки.
Теперь переходим в топик communication, настраиваем сортировку по новым сообщениям и видим сформированное сообщение: канал EMAIL, адрес (у меня захардкожен для этого клиента), текст об авторизации.
Кстати, полезный лайфхак: можно открыть две вкладки с кафкой — в одной открыть топик, в который требуется писать, в другой читать — тогда не придется постоянно переключаться.
Поиск сообщений
Попробую поиск в топике event. Был в сообщении уникальный ключ — поиск по нему срабатывает корректно.
Поищу ещё по типу нотификации (содержится в теле), всё работает, показывает записи только с CHANGING_PASSWORD.
Логирование
Теперь поговорим о налогах. При тестировании Kafka без них никуда. Кстати, именно в логах при старте сервиса можно увидеть все нужные настройки подключения к кафке.
Если мы откроем логи сервиса, который сейчас работает с топиками, и отправим новое сообщение, в конце логов увидим, что оно успешно ушло из event topic в communication topic.
А теперь специально сделаем ошибку. Отправим несуществующий тип нотификации. И сразу видим в логах: такой тип ивента не поддерживается.
Можно попробовать ещё проверить обязательное поле или заголовок. Когда что-то идёт не так, в логах появляется целая простыня текста, которую потом нужно прикрепить к багу.
Обратите внимание, в логах указана консьюмер-группа, номер оффсета и партиции, это позволяет быстрее находить, в каком сообщении пришли некорректные данные. Не будет лишним сходить к лиду разработки с предложением расширить логирование.
Kafka lag
Помните, в первой части я рассказывала про kafka lag? Его можно отслеживать в kafka ui. Показываю!Для начала — потушу сервис и оставлю кафку. Затем добавлю 3 сообщения в топик event.
Итак, в топике event +3 сообщения от 08.04.25:
В топике communication – только от 07.04.25:
Перехожу в раздел Consumers в боковом меню (до этого мы взаимодействовали только с Topics), и вижу свою консьюмер-группу — kafkaDemo. Consumer Lag = 3, именно столько сообщений у нас не прочитано, т.к. сервис не работает.
Когда сервис поднимется и прочитает очередь, Consumer Lag = 0:
На этом пока прервусь, спасибо за внимание и успехов в тестировании!
