Kafka: что нужно знать тестировщику? Часть 1
Всем привет!
В этой серии из нескольких статей мы разберемся, что делать тестировщику на проекте с кафкой (как впервые, так и имея какой-то опыт). Здесь я не буду говорить о брокерах и zookeeper-ах, о том, как развернуть кафку. Но мы разберемся, как её настроить и как с её помощью тестировать ваши микросервисы.
Начнём с «базы» (точнее, теории).
Apache Kafka — распределённый программный брокер сообщений с открытым исходным кодом, разрабатываемый в рамках фонда Apache на языках Java и Scala.
Что такое кафка?
Кафку можно представить как большую трубу, внутри которой много трубочек поменьше.
А если проще?
Представим, что есть 2 микросервиса: один должен писать данные, а второй — читать. И между ними поместили кафку, как трубу, через которую данные должны двигаться от одного сервиса к другому.
Простыми словами, у нас есть микросервис, который что-то пишет, а второй его читает.
Если эту схему расширить, получается, что писать и читать одну и ту же кафку могут разные микросервисы в направлениях «туда» и «обратно».
Представим себе новостной портал, состоящий из нескольких микросервисов. Один микросервис получил по API какие-то данные, например, что в веб-версии какого-то приложения пользователь прочитал новость. Он это обработал, может, даже что-то себе в БД записал и передал через кафку другому. Другой микросервис также это прочитал и записал к себе в БД, например, для истории, когда пользователь читает новости — утром или вечером. Допустим, есть еще мобильное приложение, и тут проблема — пользователь в веб-версии новость уже прочитал, и в приложении она не должна у него светиться как непрочитанная. Мы снова кидаем сообщение в кафку, чтобы отобразить в приложении актуальный статус.
Можно сказать, что это обмен данными в реальном времени.
Уже должно быть больше похоже на первую схему вверху статьи.
Микросервис, который пишет, — это продюсер, а тот, который читает, — консьюмер.
Уровни доступа — что запомнить
1. На схеме выше есть слова producer и consumer, так и разделяются микросервисы по ролям относительно кафки (producer — пишет, consumer — читает).
2. Права могут регулироваться сертификатами SSL, либо юзер+пароль. Сертификаты умеют протухать.
3. Один сервис может и читать, и писать.
4. Вы, как тестировщик, тоже играете роль продюсера или консьюмера и используете те же креды для доступа (об этом будет подробнее во второй части).
Топики и партиции
Вернемся к трубам — это и есть кафка. У одного топика, в который пишут и который читают микросервисы, есть одна или более партиций. Это нужно для распределения нагрузки, чтобы не получать всю кучу данных.
Топик я себе представляю для аналогии как определённую тему — например, я хочу читать статьи на Хабре только из этого «топика».
Или как таблицу в БД — это не вся база, это определённая её часть.
С точки зрения хранения, партиции — это единицы хранения сообщений, а топики — что-то вроде контейнеров, в которых эти партиции находятся.
Разработчик при настройке Producer может указать, что данные нужно записывать в определенный топик, при этом партиции он не указывает. В таком случае Kafka сама распределит по партициям весь набор передаваемых сообщений:
Количество партиций зависит от проекта, а точнее — от ресурсов, которые потребуются.
Приоритет
Разработчик может настроить и наоборот, чтобы микросервис писал/читал только из конкретной партиции топика.
Напомню, что таких писателей и читателей у одного топика может быть много. Например, группа читателей так и называется — консьюмер-группа.
А еще разработчик может настроить задержку — например, чтобы в топике появлялась только 1 запись в секунду и распределялась нагрузка.
Формат данных, которые можно передавать через кафку, напоминает API:
Таким образом, в топиках кафки накапливается очередь из таких сообщений.
Очередь
Выглядит примерно следующим образом:
У каждой записи есть партиция, в которую она попала, оффсет, уникальный ключ (по которому, кстати, можно искать сообщения при тестировании), тело сообщения, а также еще время, в которое оно было отправлено.
Оффсет — это указатель в очереди, который используется для отслеживания прогресса консьюмера при чтении данных. Можно сравнить это со страницей в книге. В какой-то момент вы приостановили чтение (микросервис упал, сертификат протух), потом поднялись и нужно продолжить читать с того же места. Или, наоборот, вы только подключились к топику (или что-то пошло совсем не так), и нужно прочитать всё заново. Для этого есть сброс оффсета.
Пример команды по сбросу оффсета:
./bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group [myConsumerGroup] --reset-offsets --to-earliest --topic [my_topic] –execute
Тогда консьюмер, к которому применили данную команду, будет вычитывать всю очередь заново.
Или, наоборот, оффсет можно сбросить, т.е. сдвинуть к конец.
./bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group [myConsumerGroup] --reset-offsets --to-latest --topic [my_topic] –execute
Это требуется, например, при подключении консьюмера, которому не нужны данные в реальном времени, т.е ему всё равно, что было до него (как подключиться к каналу/чату, например).
Можно также и сдвинуть к конкретному времени, с которого требуется начать читать:
./bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group [myConsumerGroup] --reset-offsets --to-datetime 2024–05–20T00:00:00.000 --topic [my_topic] –execute
Оффсет ещё используется для вычисления так называемого Kafka Lag.
kafka lag = последний оффсет в топике — последний вычитанный консьюмером оффсет
Это количество показывает, сколько записей консьюмер «упустил». Например, в таблице выше это может быть так: всего записей 7 (от 0 до 6), а консьюмер вычитал последним второй оффсет. 6–2=4 записи у нас «лага».
Kafka lag иногда отображают в графике в Grafana.
В норме Kafka lag = 0, если происходит скачок, скорее всего, сервис упал, либо протух доступ к топику. Затем очередь «рассасывается», следовательно, проблема устранена.
А еще можно настроить сервис так, чтобы он читал не в реальном времени, а, например, раз в сутки — ночью.
Временное хранение
Пока микросервис-консьюмер упал или потерял доступ, кафка еще выступает временным хранилищем — как раз чтобы продолжить читать с оффсета, на котором остановились.
Время хранения может быть неделя-месяц, но также в целях разгрузки и безопасности может быть совсем коротким, на моей практике самое короткое время — полчаса.
К сожалению, это не очень удобно для тестирования. Пока первый раз проходишь последовательность или ведешь детективное расследование, на каком этапе что упало, — можно уже начинать заново.
По умолчанию время хранения — 7 дней.
Итак, на этом первую часть статьи я, пожалуй, завершу. Мы рассмотрели теоретические основы, принципы и особенности взаимодействи в рамках тестирования микросервисов. А вот во второй части мы перейдем к практике тестирования и обсудим методы поиска и исправления возможных ошибок. До скорого!
