Операция выполнена!
Закрыть
Хабы: Блог компании Reksoft, Тестирование IT-систем, Тестирование мобильных приложений

Привет, Хабр!

Ранее мы разбирались с основами Kafka (часть1), рассматривали, как тестировать микросервисы (часть2) и предугадывали ошибки offset explorer и kafka ui (часть 3). В этой части – так сказать, невошедшее, но полезное, что ещё можно предусмотреть при работе с брокером. 

Преимущества брокеров

Когда я готовила материал из первой части, у меня возникло несколько предположений. Мне казалось, что некоторые преимущества относятся именно к брокерам сообщений и не имеют прямого отношения к API (временное хранение данных, обмен в реальном времени, вычитка раз в сутки, отслеживание Kafka-лага). Особенно я задумалась об этом, когда разбирала пример с мобильным веб-приложением и форматами данных для Kafka (см. раздел из статьи часть1). Казалось бы — зачем Kafka, если можно просто забирать данные из БД через API?

Я решила проверить свои догадки у знакомого бэкенд-разработчика. Его первый вопрос был: «Зачем тебе как тестировщику это знать?», а потом добавил, что API можно настроить похожим образом. Но всё же я выделила два ключевых отличия брокеров: 

1. Асинхронное взаимодействие

API — это всегда запрос-ответ. Если сервис упал, мы получим 503, и данные могут потеряться. В Kafka продюсер просто оставляет сообщение в топике, и ему всё равно, читает ли его кто-то. Даже если консьюмер упал — поднимется и дочитает. 

2. Масштабируемость

В случае с Kafka это значит, что можно гибко добавлять продюсеров и консьюмеров. Данные можно переиспользовать — допустим, создать один топик для нескольких консьюмеров. Либо, что очень важно в продакшене, например, если продюсер начал слать мусор — его можно просто отключить. 

Читать далее
Читайте также
СТАТЬ АВТОРОМ
НОВОСТИ

ПИШИТЕ

Техническая поддержка проекта ВсеТут

info@vsetut.pro