Какой брокер сообщений в ESB лучше, Kafka или RabbitMQ?

Question

[ArtLash]

У нас на предприятии интегрируется новая системы типа CRM называется СПМ, она должна будет общаться через API с 1С и другими прогами у которых тип данных отличается, встал вопрос ставить шину данных ESB, вопрос в том какой брокер ставить kafka или Rabbit, информация такая что у Кафки сообщения можно потом много пересматривать и хранение сообщений постоянное, но с Раббитом проще потому что один раз настраивается и всё, а кафку постоянно надо настраивать ?

Comments

[Михаил Р.]

Какой брокер сообщений в ESB лучше, Kafka или RabbitMQ?

Тот, который лучше знаете?

[ArtLash]

Михаил Р., никакой не знаю.

[Михаил Р.]

ArtLash, на мой взгляд, RabbitMQ будет попроще.

[ArtLash]

Михаил Р., слышал что у Кафки есть возможность хранить сообщение, типа лога что ли, что-то такое, а у рэбитта нету

[Дмитрий]

ArtLash, у рэббита есть свойство durable если вы про это.

[ArtLash]

Дмитрий, то есть это тот-же самый лог получается ?У нас ещё проблема на предприятии, у нас в стеке будет 1С, а у Раббита проблемы с 1С, там нужно какую то доп программу ставить типа ПинкРаббит что-ли. Пока думаем, с командой интеграции они готовят решение, но хотелось бы поменьше геммороя, говорят с Кафкой геммороя больше. Также думаем про Датареон.

[Дмитрий]

ArtLash, я не понимаю что вы подразумеваете под словом лог. В кролике у очереди можно выставить свойство durable и тогда он будет сообщения сбрасывать на диск и в случае чего нибудь незапланированного, он их подхватит. Вы это имеете ввиду?

1С не занимался от слова совсем.

[ArtLash]

Дмитрий, ну что-то вроде того, то есть посмотреть какие сообщение были отправлены ранее, чтобы эта инфа хранилась до востребования

[Дмитрий]

ArtLash, это какой то странная задача для очереди. она явно этим не должна заниматься. этим должен заниматься consumer.

[ArtLash]

Дмитрий, у нас просто задача чтобы можно было получить лог по очереди сообщений которые были отправлены, поэтому вопрос и был может Кафку, там вроде бы есть специальное хранилище для этого

[Дмитрий]

ArtLash, смотрите. Очередь это такая труба - в нее producers кладут сообщения, на другом конце consumers их обрабатывают. Задача трубы доставить сообщение.
Если нужно что бы consumer еще что-то сделал кроме каких вычислений - положил сообщение в файл, или еще куда - он это делает сам или передает сообщение в другую трубу другому consumer задача которого складировать это в файл. И все.

[ArtLash]

Дмитрий, то есть мы можем сказать одному из consumers положить все дублированные файлы в папку на локальном компе, а сами файлы пойдут куда нужно и если понадобится мы посмотрим в тех файлах которые лежат на локальном комп. ?

[Дмитрий]

ArtLash, если вы обработчик сообщений напишете так что он не только будет обрабатывать но и складировать в файл - у вас будет файл со всеми сообщениями. однако как бы обычно стараются распределять отвественность, что бы не получить обработчика который и что то вычисляет, и что то логирует, и что отправляет на почту, и кофе варит. А делают несколько простых - вот есть очередь 1 куда валятся сообщения ну не знаю - уменьшить баланс клиента, обработчик уменьшает и кладет в очередь 2, на конце которого сидит другой обработчик задача которого составить письмо о том что у клиента баланс уменьшился, и так далее.

[ArtLash]

Дмитрий, у нас ситуация проще. нам просто нужен брокер который будет пересылать сообщения о том какие изменения только что были внесены в БД, и будет пока что только три программы - СПМ, ЕРП(1С), WindChill, то есть создать отдельный обработчик который будет всё это складировать, понял примерно, спасибо, буду сейчас изучать всё это.