Лекція 205: Інструменти для подійно-орієнтованої архітектури: Kafka, RabbitMQ, ActiveMQ

Уявіть, що ви організатор конференції і маєте донести важливе повідомлення до всіх учасників. Звісно, ви можете підійти до кожного особисто (як роблять REST API у синхронній архітектурі), але це займе вічність. Замість цього розумно використати гучномовець (!) (брокер повідомлень), щоб розіслати ваше повідомлення один раз, а слухачі (підписники) уже самі його почують.

У світі EDA такими гучномовцями є message brokers. Їхнє завдання — передати подію від відправника (producer) до отримувачів (consumers). При цьому потрібно забезпечити:

• Надійність доставки повідомлень.
• Масштабованість і високу продуктивність.
• Асинхронну обробку повідомлення.

На допомогу приходять три популярні технології: Apache Kafka, RabbitMQ і ActiveMQ.

Огляд Apache Kafka, RabbitMQ і ActiveMQ

Apache Kafka

Ви вже знаєте, що Kafka — це ракетний двигун світу брокерів повідомлень. Нагадаю, це розподілена система, спочатку розроблена в LinkedIn, а тепер підтримується Apache Software Foundation. Kafka створена для обробки величезних обсягів даних в реальному часі з високою пропускною здатністю.

• Основні переваги Kafka:
  • Висока продуктивність: мільйони повідомлень за секунду.
  • Гарантована доставка повідомлень завдяки логам.
  • Підтримка горизонтального масштабування.
  • Добра інтеграція з Big Data екосистемою (Spark, Flink та ін.).
• Коли використовувати Kafka:
  • Потокова обробка даних (наприклад, логування або трекінг подій).
  • Аналітика в реальному часі.
  • Створення мікросервісів, де потрібна висока продуктивність.
• Недоліки:
  • Відносна складність налаштування і управління.
  • Вимагає добрих знань архітектури розподілених систем.

RabbitMQ

RabbitMQ — це класичний кролик у світі брокерів повідомлень. Це один із найстаріших брокерів, який використовує протокол AMQP (Advanced Message Queuing Protocol). Він підтримує ширшу функціональність для взаємодії між застосунками.

• Основні переваги RabbitMQ:
  • Підтримка багатьох протоколів (AMQP, MQTT, HTTP, STOMP тощо).
  • Різні патерни маршрутизації повідомлень (черги, широкомовна розсилка).
  • Гнучкість у налаштуванні і легкість інтеграції.
• Коли використовувати RabbitMQ:
  • Якщо потрібна гнучкість у маршрутизації повідомлень.
  • Для інтеграції різнорідних систем з використанням різних протоколів.
  • Коли система має невеликий обсяг і середнє навантаження.
• Недоліки:
  • Не така висока продуктивність у порівнянні з Kafka.
  • Обмеження по масштабуванню.

ActiveMQ

ActiveMQ — це ветеран ринку брокерів повідомлень, розроблений Apache Foundation. На відміну від Kafka, яка фокусується на потоках даних, ActiveMQ більше підходить для класичних сценаріїв обміну повідомленнями в бізнес-застосунках.

• Основні переваги ActiveMQ:
  • Простота у використанні та конфігурації.
  • Підтримка транзакцій і гарантованої доставки повідомлень.
  • Добре підходить для невеликих систем.
• Коли використовувати ActiveMQ:
  • У монолітних системах або невеликих мікросервісах.
  • Коли потрібна підтримка транзакцій і збереження черг.
• Недоліки:
  • Продуктивність суттєво поступається Kafka.
  • Менше функціональних можливостей, ніж у RabbitMQ.

Порівняння Kafka, RabbitMQ і ActiveMQ

Як обирати інструмент для EDA?

Щоб не помилитися з вибором, задайте собі два важливих питання:

1. Які вимоги до продуктивності?
2. Наскільки складні маршрути повідомлень вам потрібні?

Для потокової обробки даних або аналізу логів в реальному часі ваш вибір — Kafka.

Якщо потрібен гнучкий інструмент з різними патернами взаємодії, краще взяти RabbitMQ.

А якщо у вас проста система з невеликими чергами, то ActiveMQ стане відмінним вибором.

Приклади використання інструментів

Приклад 1: Apache Kafka

В інтернет-магазині відстежуються дії покупців: додавання товарів у кошик, перегляд карток товару. Ці дії записуються в Kafka-топік, після чого аналітичні системи обробляють потоки даних для створення рекомендацій.

// Приклад створення продюсера Kafka
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer7<String, String> producer = new KafkaProducer7<>(props);
producer.send(new ProducerRecord7<>("shopping-cart", "user123", "add_to_cart: product456"));
producer.close();

Приклад 2: RabbitMQ

В CRM-системі замовлення клієнтів надходять у чергу RabbitMQ. Сервіс обробки замовлень (consumer) забирає повідомлення з черги для подальшої обробки.

ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
try (Connection connection = factory.newConnection();
     Channel channel = connection.createChannel()) {
    channel.queueDeclare("orders_queue", false, false, false, null);
    String message = "New Order: 12345";
    channel.basicPublish("", "orders_queue", null, message.getBytes());
    System.out.println(" [x] Sent '" + message + "'");
}

Приклад 3: ActiveMQ

В банківській системі відбувається обмін транзакціями з використанням ActiveMQ. Кожне повідомлення містить інформацію про транзакцію, яка потім зберігається в базі даних.

ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
try (Connection connection = connectionFactory.createConnection()) {
    connection.start();
    Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
    Queue queue = session.createQueue("transaction_queue");
    MessageProducer producer = session.createProducer(queue);
    TextMessage message = session.createTextMessage("Transaction: 100$ to Account 12345");
    producer.send(message);
    System.out.println("Sent: " + message.getText());
}

Підводні камені роботи з брокерами повідомлень

Працюючи з будь-яким брокером, можна зіткнутися з типовими проблемами. Наприклад, при використанні Kafka потрібно звертати увагу на правильну конфігурацію партицій, щоб уникнути перевантаження окремих брокерів. RabbitMQ, у свою чергу, може вимагати глибокого аналізу маршрутизації повідомлень для складних сценаріїв. А ActiveMQ може стати пляшковим горлечком при високих навантаженнях.

Підсумок: що обрати?

Ваш вибір брокера повідомлень залежить від конкретного завдання і характеристик вашої системи. Kafka — це ваш вибір для великої, навантаженої системи потокової обробки даних. RabbitMQ краще підходить для гнучкої маршрутизації і інтеграції, а ActiveMQ закриє потреби невеликих систем з мінімальними вимогами.

Не забувайте, що краще протестувати кілька варіантів перед тим, як зупиняти вибір на одному інструменті. І так, не забудьте регулярно чистити черги повідомлень, інакше ці "свята життя" закінчаться швидше, ніж ви думаєте.