Привет, Хабр! Представляю вашему вниманию перевод статьи "Surprisingly simple messaging with Spring Cloud Stream" автора Richard Seroter.

Существует множество вариантов взаимодействия микросервисов. Вы можете использовать обнаружение сервисов (Service Discovery, например, Spring Cloud Discovery Server/Client в реализации Netflix Eureka) и совершать прямые вызовы. Или можете использовать общую базу данных для обмена результами работы. Но брокеры сообщений продолжают оставаться популярным выбором.

Они варьируются от простых движков вроде Amazon SQS или RabbitMQ до событийных потоковых процессоров вроде Azure Event Hubs или Apache Kafka и вплоть до служебных шин вроде Microsoft BizTalk Server. Когда разработчики выбирают один из движков, они критически нуждаются в знаниях об их эффективности. Как вы можете повысить производительность разработчиков? Для Java разработчиков Spring Cloud Stream предлагает ценную абстракцию.

Spring Cloud Stream предлагает интерфейс для разработчиков, которым не требуются нюансы базового брокера. Этот брокер, Apache Kafka или RabbitMQ, настраивается самим Spring Cloud Stream. Связь с брокером и обратно от брокера осуществляется также через библиотеку Stream.

Что меня волнует, так это то, что все брокеры обрабатываются одинаково. Spring Cloud Stream нормализует поведение, даже если оно не является родным для брокера. Например, хотите создать конкурирующую модель консюмера для своих клиентов или секционировать обработку? Эти концепции ведут себя по-разному в RabbitMQ и Kafka. Нет проблем. Spring Cloud Stream делает работу одинаково прозрачной. Давайте фактически попробуем оба этих сценария.
Читать дальше →

https://habrahabr.ru/post/350454/