🐳 Docker + Kafka / RabbitMQ глазами тестировщика Где живут самые коварные баги асинхронных систем Если ты тестировал систему с очередями, ты знаешь: самые неприятные баги не падают сразу. Они тихо накапливаются в очередях, теряются, дублируются или застревают. И именно тут Docker становится для QA инструментом рентгена. 🧠 Почему очереди кошмар для тестирования Kafka и RabbitMQ ломают привычную модель: запрос - ответ - результат Вместо этого: - сообщение может прийти позже - может прийти дважды - может не прийти вообще - может обработаться не тем сервисом - может застрять навсегда, но UI об этом не знает Без локального стенда с очередями QA тестирует поверхность, а не систему. 🧱 Минимальный docker-compose для QA RabbitMQ (проще для старта) services: api: image: mycorp/api:1.6 environment: - QUEUE_HOST=rabbit depends_on: - rabbit rabbit: image: rabbitmq:3-management ports: - "15672:15672" # UI - "5672:5672" Ты получаешь: реальный брокер UI RabbitMQ возможность смотреть очереди глазами, а не угадывать Kafka (реалистичнее, но сложнее) services: zookeeper: image: confluentinc/cp-zookeeper environment: ZOOKEEPER_CLIENT_PORT: 2181 kafka: image: confluentinc/cp-kafka depends_on: - zookeeper ports: - "9092:9092" environment: KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 Да, это не просто, но это почти прод - а значит, и баги будут честные. 🐛Баги, которые QA реально ловит через очереди 1️⃣ Потеря сообщений Сценарий: API успешно отвечает 200 OK, но сообщение не появляется в очереди. QA-проверка: открыть UI RabbitMQ, проверить: exchange, routing key, очередь, количество сообщений. Частая причина: неправильный routing key или конфиг env. 2️⃣ Дублирование сообщений Сценарий: одно действие пользователя - два события в системе, бизнес-логика срабатывает дважды. QA через Docker: отправляет запрос, смотрит, сколько сообщений реально улетело, рестартует consumer-контейнер: docker restart consumer Если после рестарта сообщение обрабатывается снова - idempotency не соблюдена. 3️⃣ “Зависшие” сообщения Сценарий: очередь растёт, UI работает, пользователи жалуются на задержки. QA-диагностика: consumer контейнер запущен? падает ли он при обработке? есть ли retries / dead-letter queue? RabbitMQ: смотри DLQ, смотри unacked messages. Kafka: смотри consumer lag. 4️⃣ Нарушение порядка сообщений (особенно в Kafka) Сценарий: события приходят не в том порядке, состояние системы ломается. QA может: проверить key сообщений, отправить серию событий с одним ключом, проверить, что они попали в одну партицию. Если ключ пустой - порядок не гарантирован. 5️⃣ Баги при падении сервиса Сценарий: consumer падает в середине обработки, часть логики выполнена, часть — нет. QA-трюк: docker stop consumer в момент обработки сообщения. После старта: сообщение пропало? ❌ обработалось повторно? ❌ ушло в DLQ? ✅ Вот здесь и проявляется зрелость системы. 📓 Заметки тестировщика