Для чего используется Message Broker?

# Message Broker в архитектуре приложений

Message Broker — это ключевой компонент в современных распределённых системах. Я использую его регулярно в своей практике, и это один из самых мощных паттернов для масштабирования.

Что такое Message Broker

Message Broker — это промежуточная система, которая:

1. Получает сообщения от отправителя (producer)
2. Хранит их (в очереди или топике)
3. Доставляет получателю (consumer)
4. Гарантирует надёжность доставки

Основные задачи Message Broker

1. Asynchronous Communication (Асинхронная коммуникация)

Без Message Broker:

// Синхронный вызов — если сервис B вниз, всё падает
Response response = serviceB.process(data); // Блокирует

С Message Broker:

// Асинхронный вызов
messageBroker.send("orders-queue", order);
// Продолжаем работу, не ждём
return "Order received";

2. Decoupling Services (Развязывание сервисов)

Сервис A не нужно знать о сервисе B:

• Сервис A отправляет сообщение в очередь
• Сервис B слушает эту очередь
• Если B упал, он восстановится и обработает сообщения
• Если добавить сервис C, он просто слушает ту же очередь

3. Load Balancing (Распределение нагрузки)

// Множество потребителей обрабатывают сообщения параллельно
@KafkaListener(topics = "events", groupId = "group1")
public void consumeEvent(String message) {
    processEvent(message);
}

Каждое сообщение обрабатывается ровно одним consumer-ом. Если приходит spike трафика:

• Сообщения копятся в очереди
• Consumer-ы обрабатывают в своём темпе
• Система не падает

4. Message Persistence (Сохранение сообщений)

Сообщения хранятся на диске, не теряются при перезагрузке. Гарантии delivery:

• At Most Once (может не доставиться)
• At Least Once (может доставиться несколько раз)
• Exactly Once (доставляется ровно один раз)

Популярные Message Broker

RabbitMQ

@Configuration
public class RabbitConfig {
    @Bean
    public Queue orderQueue() {
        return new Queue("orders", true);
    }
    
    @Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory factory) {
        return new RabbitTemplate(factory);
    }
}

// Отправка
rabbitTemplate.convertAndSend("orders", order);

// Получение
@RabbitListener(queues = "orders")
public void processOrder(Order order) {
    service.handle(order);
}

Плюсы: надёжность, гибкость, стабильность Минусы: управление, поддержка infra

Apache Kafka

@Configuration
public class KafkaProducerConfig {
    @Bean
    public ProducerFactory<String, Order> producerFactory() {
        return new DefaultKafkaProducerFactory<>(producerConfigs());
    }
    
    @Bean
    public KafkaTemplate<String, Order> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }
}

// Отправка
kafkaTemplate.send("orders", order);

// Получение с partition
@KafkaListener(topics = "orders", groupId = "order-group")
public void consume(Order order) {
    service.process(order);
}

Плюсы: высокая производительность, партиционирование, stream processing Минусы: сложность, требует экспертизы

Amazon SQS / Azure Service Bus

Управляемые облачные решения. Не нужно управлять infra.

Реальные примеры использования

Сценарий 1: E-commerce платформа

Пользователь → Заказ (API) → Order Service → Message Broker → 
  → Email Service (отправляет письмо)
  → Payment Service (обрабатывает платёж)
  → Analytics Service (логирует события)

Если Email Service упадёт, заказ не потеряется. Письмо отправится, когда сервис восстановится.

Сценарий 2: Микросервисная архитектура

User Service → Event: UserCreated → Message Broker →
  → Notification Service (отправляет приветствие)
  → Profile Service (создаёт профиль)
  → Analytics Service

Сценарий 3: Stream processing (Kafka)

IoT Sensors → Kafka Topic → Stream Processor → 
  → Real-time analytics
  → Alerts
  → Data warehouse

Когда использовать Message Broker

✓ Асинхронные операции (отправка email, логирование) ✓ Микросервисная архитектура ✓ Интеграция с внешними системами ✓ Обработка больших объёмов данных ✓ Нужна надёжность доставки ✓ Система должна быть resilient

Когда НЕ использовать

✗ Простое синхронное приложение ✗ Низкие требования к надёжности ✗ Небольшой объём данных ✗ Команда не готова поддерживать infra

Выводы

Message Broker — это не "для галочки". Это фундаментальный инструмент для:

• Масштабируемости
• Надёжности
• Гибкости архитектуры
• Разделения ответственности

В современных системах с микросервисами Message Broker — это почти обязательный компонент.