У нас на предприятии интегрируется новая системы типа CRM называется СПМ, она должна будет общаться через API с 1С и другими прогами у которых тип данных отличается, встал вопрос ставить шину данных ESB, вопрос в том какой брокер ставить kafka или Rabbit, информация такая что у Кафки сообщения можно потом много пересматривать и хранение сообщений постоянное, но с Раббитом проще потому что один раз настраивается и всё, а кафку постоянно надо настраивать ?
Дополнительно:
Какой брокер сообщений в ESB лучше, Kafka или RabbitMQ?
Тот, который лучше знаете?
Михаил Р., никакой не знаю.
ArtLash, на мой взгляд, RabbitMQ будет попроще.
Михаил Р., слышал что у Кафки есть возможность хранить сообщение, типа лога что ли, что-то такое, а у рэбитта нету
ArtLash, у рэббита есть свойство durable если вы про это.
Дмитрий, то есть это тот-же самый лог получается ?У нас ещё проблема на предприятии, у нас в стеке будет 1С, а у Раббита проблемы с 1С, там нужно какую то доп программу ставить типа ПинкРаббит что-ли. Пока думаем, с командой интеграции они готовят решение, но хотелось бы поменьше геммороя, говорят с Кафкой геммороя больше. Также думаем про Датареон.
ArtLash, я не понимаю что вы подразумеваете под словом лог. В кролике у очереди можно выставить свойство durable и тогда он будет сообщения сбрасывать на диск и в случае чего нибудь незапланированного, он их подхватит. Вы это имеете ввиду?
1С не занимался от слова совсем.
Дмитрий, ну что-то вроде того, то есть посмотреть какие сообщение были отправлены ранее, чтобы эта инфа хранилась до востребования
ArtLash, это какой то странная задача для очереди. она явно этим не должна заниматься. этим должен заниматься consumer.
Дмитрий, у нас просто задача чтобы можно было получить лог по очереди сообщений которые были отправлены, поэтому вопрос и был может Кафку, там вроде бы есть специальное хранилище для этого
ArtLash, смотрите. Очередь это такая труба - в нее producers кладут сообщения, на другом конце consumers их обрабатывают. Задача трубы доставить сообщение.
Если нужно что бы consumer еще что-то сделал кроме каких вычислений - положил сообщение в файл, или еще куда - он это делает сам или передает сообщение в другую трубу другому consumer задача которого складировать это в файл. И все.
Дмитрий, то есть мы можем сказать одному из consumers положить все дублированные файлы в папку на локальном компе, а сами файлы пойдут куда нужно и если понадобится мы посмотрим в тех файлах которые лежат на локальном комп. ?
ArtLash, если вы обработчик сообщений напишете так что он не только будет обрабатывать но и складировать в файл - у вас будет файл со всеми сообщениями. однако как бы обычно стараются распределять отвественность, что бы не получить обработчика который и что то вычисляет, и что то логирует, и что отправляет на почту, и кофе варит. А делают несколько простых - вот есть очередь 1 куда валятся сообщения ну не знаю - уменьшить баланс клиента, обработчик уменьшает и кладет в очередь 2, на конце которого сидит другой обработчик задача которого составить письмо о том что у клиента баланс уменьшился, и так далее.
Дмитрий, у нас ситуация проще. нам просто нужен брокер который будет пересылать сообщения о том какие изменения только что были внесены в БД, и будет пока что только три программы - СПМ, ЕРП(1С), WindChill, то есть создать отдельный обработчик который будет всё это складировать, понял примерно, спасибо, буду сейчас изучать всё это.
ESB (Enterprise Service Bus) - это архитектурный подход, который объединяет различные приложения и сервисы в единую систему коммуникации. Одним из ключевых компонентов ESB является брокер сообщений, который отвечает за передачу сообщений между различными компонентами системы.
Kafka и RabbitMQ - два популярных брокера сообщений, которые могут быть использованы в качестве компонента ESB. Оба брокера имеют свои особенности и преимущества, поэтому выбор между ними зависит от конкретных требований и задач проекта.
Kafka - это распределенная платформа для потоковых данных, которая обеспечивает высокую производительность и надежность при передаче больших объемов данных. Он хорошо подходит для сценариев, где требуется обработка больших объемов данных в реальном времени, таких как аналитика данных, мониторинг и логирование. Kafka также обладает возможностью хранения данных на диске, что делает его отличным выбором для сценариев с высокой нагрузкой.
RabbitMQ, с другой стороны, является более традиционным брокером сообщений, который обеспечивает надежную доставку сообщений и поддерживает различные протоколы обмена сообщениями, такие как AMQP и MQTT. Он хорошо подходит для сценариев, где требуется гарантированная доставка сообщений и обработка их в определенном порядке.
При выборе между Kafka и RabbitMQ необходимо учитывать следующие факторы:
- Объем и скорость обработки данных: если ваш проект требует обработки больших объемов данных в реальном времени, то Kafka может быть лучшим выбором.
- Надежность и гарантированная доставка сообщений: если ваш проект требует гарантированной доставки сообщений и обработки их в определенном порядке, то RabbitMQ может быть более подходящим вариантом.
- Сложность развертывания и поддержки: оба брокера имеют свои особенности и требования к конфигурации и поддержке, поэтому необходимо учитывать их при выборе.
В итоге, выбор между Kafka и RabbitMQ зависит от конкретных требований вашего проекта и предпочтений команды разработчиков. Оба брокера сообщений являются популярными и широко используемыми в индустрии, поэтому важно провести тщательный анализ и выбрать тот, который лучше всего подходит для вашего конкретного случая.