Как RabbitMQ сравнивается с Mule
Как RabbitMQ сравнивается с Mule, я собираюсь создать приложение, использующее ориентированную на сообщения архитектуру, и AMQP (RabbitMQ) предоставляет все, что я хочу, но я озадачен множеством смежных технологий и аналогичных концепций, таких как ESB. У меня есть сомнения, если я делаю выбор, не учитывая другие альтернативы.
В основном я понимаю, что RabbitMQ является брокером сообщений, и он помогает мне в посредничестве между производителем и потребителем (все формы или публикация подписки, и я мог бы понять, как она используется на реальных примерах, таких как twitter или Facebook update и т.д.)
Что такое Mule, если бы я мог достичь того, что я делаю в RabbitMQ с помощью mule, должен ли я рассматривать mule, похожий на RabbitMQ?
Есть ли у мула другая цель, чем у брокера сообщений?
Предполагает ли mule, что в основе этого лежит брокер сообщений, который доставляет сообщение соответствующим слушателям мула (я мог бы легко написать слушателя в RabbitMQ)
Является ли mule полной базой Java-системы (текущий эксперимент, который я сделал с RabbitMQ, занял у меня меньше 30 минут, чтобы написать простой RPC-клиентский сервер с клиентом как С# и Server как Java, так будет легко выполняться в Mule).
Ответы
Ответ 1
Mule - ESB (Enterprise Service Bus). RabbitMQ является брокером сообщений.
An ESB предоставляет дополнительные слои поверх брокера сообщений, такие как маршрутизация, преобразования и управление бизнес-процессами. Это посредник между приложениями, интеграция Web-сервисов, конечных точек REST, соединений с базами данных, серверов электронной почты и ftp-серверов - вы называете это. Это высокоуровневая интегральная магистраль, которая организует взаимодействие в сети приложений, которые говорят по разным протоколам.
A брокер сообщений - это компонент более низкого уровня, который позволяет вам как разработчику передавать необработанные сообщения между издателями и подписчиками, как правило, между компонентами одной и той же системы, но не всегда. Он используется для обеспечения асинхронной обработки, чтобы поддерживать низкое время ответа. Некоторые задачи занимают больше времени, и вы не хотите, чтобы они занимались, если они не чувствительны ко времени. Вместо этого отправьте сообщение в очередь (как издатель) и попросите подписчика поднять его и обработать "позже".
Ответ 2
Mule - это услуга "более высокого уровня", реализованная с помощью брокера сообщений. Из docs
Основой обмена сообщениями ESB является обычно реализуется с использованием JMS, но любой другая реализация сервера сообщений можно использовать
Вы можете построить ESB с кроликом; однако вы будете ограничены отправкой пакетов byte [], и вам придется создавать свою систему из примитивов обмена сообщениями, таких как темы и очереди. Это может быть немного быстрее (основано на абсолютном отсутствии бенчмаркинга, тестирования или данных), поскольку количество переводов меньше. Mule обеспечивает абстракцию поверх этого, говорит множество транспортов и может обрабатывать некоторую логику маршрутизации.
Ответ 3
RabbitMQ, программное обеспечение брокера сообщений с открытым исходным кодом написано на языке программирования Erlang и построено на платформе Open Telecom для кластеризации и восстановления после сбоев. Он прост в использовании, поддерживает огромное количество платформ разработчиков и работает на всех основных операционных системах. Он работает над концепцией Exchange.
Mule соединяет RabbitMQ с разъемом AMQP.
Ответ 4
Mule - это служебная шина Enterprise, предоставляющая комплексное решение интеграции, где, поскольку Rabbit является брокером сообщений для сообщений о очередях между абонентом и получателем.
Ответ 5
Кролик относится к эпохе клиент-сервер, а Mule относится к эпохе API Network. Если вы не вынуждены внедрять его в рамках устаревшей платформы, лучше использовать API Mule и Rest. Как бы то ни было, через несколько лет код, который вы написали для Rabbit, должен быть модифицирован для поддержки архитектуры настоящего и будущего на основе API. Так почему бы не сделать это сейчас? мои несколько центов.
