Когда Spring Cloud Stream хуже прямого Spring Kafka или Spring AMQP?
- Когда лучше Spring Kafka, а не Spring Cloud Stream?
Cloud Stream хуже, когда нужен тонкий контроль над брокером: транзакции, ручные коммиты, особые стратегии повторов, работа с заголовками и партициями, производительность и прозрачность. Тогда — прямой Spring Kafka или Spring AMQP.
- Абстракция протекает: настройки всё равно специфичны для брокера
- Отладка через дополнительный слой сложнее
- Cloud Stream хорош для простых конвейеров и единого стиля в многих сервисах
А ещё Переход «на другой брокер» почти никогда не бывает реальной целью
Подробно
Cloud Stream хорош для стандартных функций и унификации. Но когда важны детали commit/ack, transactions, retry topics, container hooks или Rabbit-specific routing, native API проще контролировать. Дополнительная abstraction усложняет debug broker-specific поведения: проблема может быть в binder, конвертере или контейнере одновременно.
Что хотят услышать
- Когда абстракция мешает.
- Где Cloud Stream уместен.
Частые ошибки
- Использовать Cloud Stream, чтобы не понимать брокер.
- Переусложнять простой pipeline прямым API без нужды.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Всегда — Cloud Stream устарел и удалён из актуальных версий Spring
- ✓Когда нужен тонкий контроль над брокером
- ✗Когда сервисов много и нужен единый простой стиль обработки сообщений во всех конвейерах
- ✗Когда сообщений мало и брокер работает в одном экземпляре
Что спросят дальше
- Какие binder-specific properties вы настраивали?
- Как тестировать Cloud Stream функции?
Разбор темы
- Spring Cloud Stream
Binder abstraction, functional model, bindings, consumer groups, partitioning и trade-offs поверх Kafka/RabbitMQ.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.