Кафка: преимущества и на что ещё обратить внимание при тестировании
Привет, Хабр! Ранее мы разбирались с основами Kafka ( часть1 ), рассматривали, как тестировать микросервисы ( часть2 ) и предугадывали ошибки offset explorer и kafka ui ( часть 3 ). В этой части – так сказать, невошедшее, но полезное, что ещё можно предусмотреть при работе с брокером. Преимущества брокеров Когда я готовила материал из первой части, у меня возникло несколько предположений. Мне казалось, что некоторые преимущества относятся именно к брокерам сообщений и не имеют прямого отношения к API (временное хранение данных, обмен в реальном времени, вычитка раз в сутки, отслеживание Kafka-лага). Особенно я задумалась об этом, когда разбирала пример с мобильным веб-приложением и форматами данных для Kafka (см. раздел из статьи часть1 ). Казалось бы — зачем Kafka, если можно просто забирать данные из БД через API? Я решила проверить свои догадки у знакомого бэкенд-разработчика. Его первый вопрос был: «Зачем тебе как тестировщику это знать?», а потом добавил, что API можно настроить похожим образом. Но всё же я выделила два ключевых отличия брокеров: 1. Асинхронное взаимодействие API — это всегда запрос-ответ. Если сервис упал, мы получим 503, и данные могут потеряться. В Kafka продюсер просто оставляет сообщение в топике, и ему всё равно, читает ли его кто-то. Даже если консьюмер упал — поднимется и дочитает. 2. Масштабируемость В случае с Kafka это значит, что можно гибко добавлять продюсеров и консьюмеров. Данные можно переиспользовать — допустим, создать один топик для нескольких консьюмеров. Либо, что очень важно в продакшене, например, если продюсер начал слать мусор — его можно просто отключить.
https://habr.com/ru/companies/reksoft/articles/911132/
#kafka #микросервисы #тестирование #брокеры #тестирование_микросервисов #kafka_consumer #kafka_producer
Habr
Habr 25+
