Привет, Хабр!
Ранее мы разбирались с основами Kafka (часть1), рассматривали, как тестировать микросервисы (часть2) и предугадывали ошибки offset explorer и kafka ui (часть 3). В этой части – так сказать, невошедшее, но полезное, что ещё можно предусмотреть при работе с брокером.
Преимущества брокеров
Когда я готовила материал из первой части, у меня возникло несколько предположений. Мне казалось, что некоторые преимущества относятся именно к брокерам сообщений и не имеют прямого отношения к API (временное хранение данных, обмен в реальном времени, вычитка раз в сутки, отслеживание Kafka-лага). Особенно я задумалась об этом, когда разбирала пример с мобильным веб-приложением и форматами данных для Kafka (см. раздел из статьи часть1). Казалось бы — зачем Kafka, если можно просто забирать данные из БД через API?
Я решила проверить свои догадки у знакомого бэкенд-разработчика. Его первый вопрос был: «Зачем тебе как тестировщику это знать?», а потом добавил, что API можно настроить похожим образом. Но всё же я выделила два ключевых отличия брокеров:
1. Асинхронное взаимодействие
API — это всегда запрос-ответ. Если сервис упал, мы получим 503, и данные могут потеряться. В Kafka продюсер просто оставляет сообщение в топике, и ему всё равно, читает ли его кто-то. Даже если консьюмер упал — поднимется и дочитает.
Кстати, часто сравнивают Kafka и RabbitMQ. Оба брокера существуют для обмена данными, но работают по-разному:
RabbitMQ — push (сообщения идут получателю)
Kafka — pull (консьюмеры сами забирают), и в этом контексте Kafka звучит надёжнее, чем RabbitMQ
2. Масштабируемость
В случае с Kafka это значит, что можно гибко добавлять продюсеров и консьюмеров. Данные можно переиспользовать — допустим, создать один топик для нескольких консьюмеров. Либо, что очень важно в продакшене, например, если продюсер начал слать мусор — его можно просто отключить.
На что ещё обратить внимание при тестировании
Помимо непосредственного эмулирования микросервисов при тестировании с кафкой есть ещё несколько аспектов, на которые стоит обратить внимание.
Например, у вас консьюмер, и к топику, который он вычитывает (на который он подписан), подключено несколько продюсеров. Понаблюдайте за распределением сообщений по партициям – возможно, какой-то из продюсеров пишет в конкретную партицию, хотя архитектурой такое поведение не было предусмотрено. Если у него высокая нагрузка, то это может критично отразиться на вашем консьюмере.
Теперь пару слов о нагрузочном тестировании и продакшене.
Первое правило бойцовского клуба: не копируйте настройки тестовой среды в продакшен. Да, звучит как «делайте хорошо, не делайте плохо», но на практике я постоянно сталкиваюсь с ситуациями, когда это правило нарушают. В тестовых средах часто ограничены ресурсы — к примеру, ставят одну партицию или упрощают настройки безопасности. В продакшене такой подход недопустим. Вот, на что стоит обратить особое внимание, исходя из преимуществ брокеров:
Распределение нагрузки. Не ограничивайтесь одной партицией. Минимум две, а лучше – больше. При проведении нагрузочного тестирования нужна тестовая среда, максимально приближенная к проду;
Отказоустойчивость. Kafka и так надёжна (если сервис упадёт, сообщения не потеряются), но лучше подстраховаться – запустить несколько pod-ов (экземпляров) сервиса, настроить количество реплик, организовать мониторинг. Особенно критично это предусмотреть для сообщений с коротким сроком годности – например, OTP (One-Time Password).
Как могут выглядеть эти настройки:
В заключение, пожалуй, отмечу следующее: держите в памяти эти преимущества брокеров, и со временем вы сами найдёте, что ещё интересного, кроме самих json-ов в сообщениях, можно протестировать в интеграции с брокерами. Не отказывайте себе в этом удовольствии!
