Разница между брокером сообщений и ESB
Я прошел через различные вопросы / статьи о Message Brokers и ESB (даже о stackru). До сих пор не понимаю, какова четкая разница между брокером сообщений и ESB? Теперь я пытаюсь сравнить продукты, Websphere Broker и Mule ESB!!
Во-первых, является ли (любая версия) Webshere Broker ESB? Наши ребята из IBM заявляют, что это ESB!(Я не удивлен этим).
Моя ограниченная информация говорит мне, что Message Broker работает на модели HUB-SPOKE. Однако ESB работает на архитектуре шины. Теперь, что на земле это должно означать? Я прочитал, что, если HUB отказывает (недоступно, я думаю), то брокер полностью отказывает. Что не относится к ESB (так говорят эти парни). То, что я не понимаю здесь, это "Что делать, если автобус" терпит неудачу?
Теперь обычные вещи о ESB и брокерах состоят в том, что они обеспечивают маршрутизацию, преобразование, оркестровку и т. Д. Итак, если оба они предоставляют это, то почему я выберу одно из другого?
Другая область конфликта касается ТРАНСФОРМАЦИИ. ESB облегчают это по-другому по сравнению с Message Brokers? Мне бы очень хотелось немного разобраться в этом.
Теперь говорим о ГОРИЗОНТАЛЬНОМ масштабировании. Кто кого превосходит? Или они оба одинаково масштабируемы с точки зрения сложности (или любых других факторов). Конечно, брокер Webshpere будет взимать плату за каждую коробку (не говоря уже о каждом процессоре). Я считаю, что даже коммерческий MULE ESB этого не делает. Оставляя в стороне часть затрат, каковы последствия масштабирования ESB и Message Broker. Я знаю, что вы можете повысить уровень обслуживания в ESB. Возможно ли это в Message Broker?
7 ответов
Вы можете использовать посредника преобразования без служебной шины, и наоборот. Что касается конкретных продуктов, я не думаю, что кто-то является одним или другим из-за того, как каждый дополняет другой. Некоторые продукты сильнее в одной области, другие сильнее в другой. Возможно, необходимо сделать выбор в зависимости от того, какая функция лучше всего подходит для решения конкретной проблемы.
У брокера могут быть лучше встроенные "лего-блоки" для построения цепочки трансформации, чем у продукта ESB. Брокер, задействованный в качестве ESB, может быть сломлен под нагрузкой и плохо масштабироваться, или может не иметь надежного ведения журналов и инструментов для работы с журналами.
Некоторые ESB позволяют откатывать обновления базы данных и воспроизводить очереди в исправленном приложении после обнаружения и исправления вопиющей ошибки в логике. Я не думаю, что большинство брокеров интегрируют этот уровень поддержки транзакций. Чтобы это работало во всех ваших "транзакциях", вам, скорее всего, должны быть деловые события (продажа, продление, смена владельца и т. Д.), А не что-то вроде RPCish "обновления базы данных".
Отказ от ответственности: я консультант IBM и специализируюсь на WebSphere ESB. Этот комментарий не оставлен ни в каком официальном качестве.
ESB - это скорее архитектурный шаблон или концепция, чем продукт - в общем, сервисный способ проектирования слабой связи. Его определение обдумано и не совсем заложено в камне. В общем, ESB - это набор несвязанных (в техническом смысле) сервисов - они предоставляют интерфейсы и используют их из других сервисов. Как правило, здесь не используется хаб и спицевая архитектура, хотя она может быть.
IBM, безусловно, продает и WebSphere Message Broker, и WebSphere ESB как продукты, облегчающие создание ESB (вместе с аппаратным устройством DataPower). У них разные технологические корни, но они частично совпадают по назначению. Кроме того, это не значит, что вы не можете создать ESB с множеством других вещей, которые не обозначены как "продукт ESB".
Это не отвечает на все ваши вопросы, но, надеюсь, относится к части IBM.
Разница между Message Broker и ESB заключается в основном в слове "шина".
Для меня Message Broker - это один (обычно большой) процесс, который преобразует данные из одной структуры в другую или модифицирует контент.
ESB - это промежуточное программное обеспечение, ориентированное на сообщения (MOM), плюс дополнительные сервисы, одним из которых может быть брокер сообщений. Таким образом, ESB может включать Message Broker в качестве одного из своих компонентов. Шина состоит из более чем одного процесса, иначе я бы не назвал это "шиной". Природа шины заключается в том, что существует несколько компонентов, выполняющих различные задачи, каждый из которых взаимодействует через MOM и придерживается той или иной формы "общего формата данных". Шина будет состоять из: приложений, отправляющих данные в MOM, адаптеров базы данных, Message Brokers, мостов MOM и т. Д.
Разделение немного постепенное, но самое большое различие между архитектурой Message Broker и Bus заключается в гранулярности. Если ваша задача - объединить приложения A, B, .., Z и пару баз данных, вы можете сделать это с помощью одного большого Message Broker, соединяющего всех и каждого. Или с ESB, где несколько небольших компонентов выполняют только небольшие задачи. Например, один адаптер подключается к A, другой к B (но они не выполняют преобразование), затем каждый отправляет свои материалы одному (или нескольким) Message Broker, каждый из которых должен быть максимально простым - например, не необходимость знать о модели данных "А" или "В". Хороший ESB должен иметь общее определение данных на шине, абстрагируясь от "различий" отдельных приложений.
ТРАНСФОРМАЦИЯ: ESB не помогает с преобразованием, если он не поставляется с Message Broker. Но каждый хороший ESB должен в любом случае включать брокера сообщений. Message Broker должен быть экспертом вашего автобуса для преобразований, но не более того.
ГОРИЗОНТАЛЬНОЕ масштабирование: если вам нужно подключить только 3 вещи (сейчас и навсегда), вероятно, не стоит усилий, чтобы получить полноценный ESB. Message Broker имеет преимущество в том, что он представляет собой один большой процесс. Вы можете настроить там все и иметь центральное расположение для всех ваших отображений данных, фильтрации и маршрутизации.
Но если у вас есть 30 приложений для подключения, один Message Broker, вероятно, остановится. Конечно, вы можете покупать больше экземпляров, запускать избыточные вещи и т. Д., Но вы должны изменить свою стратегию, чтобы "локализовать" рабочие места. Адаптер каждого приложения (может быть один маленький экземпляр Message Broker каждый) должен иметь возможность генерировать и / или получать абстрактную общую модель данных (например, XML с общим XSD). Также может быть центральный Message Broker для задач преобразования, но этот экземпляр не должен знать о модели данных A или B. Поэтому ESB должен перенести обработку в экспертный компонент, а не хранить все в центральном месте.
Я только что прочитал эту статью Уди Дахана несколько дней назад, которая может дать вам более четкое представление о том, что я считаю одним из фундаментальных отличий.
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
Цитирование:
Правило о том, что для данного типа событий может быть только один издатель, - это одна из вещей, которая отличает шины от брокеров, хотя оба, очевидно, позволяют иметь несколько подписчиков.
...
К сожалению, существует множество технологий в стиле брокера, которые продаются под флагом Enterprise Service Bus. Хотя некоторые продукты имеют возможность развертывания как централизованным, так и распределенным образом (иногда называемым "объединенным" или "встроенным" режимом), во многих не применяется правило "одиночная конечная точка публикации на тип события".
Без этого ограничения просто слишком легко совершать ошибки.
Надеюсь, поможет.
Enterprise Service Bus предоставляет три ключевых значения для бизнеса:
- Контекстная или контентная маршрутизация транзакций;
- Преобразование из одного домена сообщений или транспорта в другой домен сообщений или транспорта;
- связь многих со многими.
ESB обеспечивают слабую связь сервисов, позволяют реконструировать сервисы в совершенно иной контекст приложения, чем когда сервисы были впервые задуманы или разработаны, и способствуют повторному использованию приложений без необходимости перекодирования приложений. WebSphere Message Broker (или теперь называется IBM Integration Bus) является ярким примером Enterprise Service Bus. Для примера простоты кода, который дает большую силу в несколько строк, вы можете просмотреть мой пост здесь: http://soabus.org/viewtopic.php?f=3&t=13. Фундаментальная конструкция внутри среды выполнения IIB называется логическим деревом сообщений (LMT). Все, что хочет сделать разработчик, - это какая-то операция на LMT. ESQL является наиболее эффективным языком, который разработчик может использовать для выполнения этих операций на LMT, хотя поддерживаются многие другие языки (например, Java, PHP, Python и т. Д.). Ни один другой продукт не может приблизиться к эффективности и простоте разработки ESB. приложений, чем IBM Integration Bus, так как 90 процентов кодирования этих приложений выполняется путем перетаскивания узлов на поддон. Это оставляет только 10 процентов кодирования, выполняемого разработчиком потока сообщений. Кстати, IBM прекратила выпуск WebSphere ESB, и многие конкурирующие продукты для IBM Integration Bus не видели каких-либо новых разработок для них уже несколько лет. Список различных предложений продуктов ESB можно увидеть на soabus.org.
Я копирую это объяснение Шимона Амита, найденное в другой теме ( /questions/2678122/kak-rabbitmq-sravnivaetsya-s-mule/2678151#2678151), что для меня имеет смысл.
ESB предоставляет дополнительные уровни поверх брокера сообщений, такие как маршрутизация, преобразования и управление бизнес-процессами. Это посредник между приложениями, интегрирующий веб-службы, конечные точки REST, соединения с базой данных, серверы электронной почты и ftp — что угодно. Это высокоуровневая интеграционная магистраль, которая обеспечивает взаимодействие в сети приложений, использующих разные протоколы.
Брокер сообщений — это компонент более низкого уровня, который позволяет вам как разработчику передавать необработанные сообщения между издателями и подписчиками, обычно между компонентами одной и той же системы, но не всегда. Он используется для включения асинхронной обработки, чтобы сократить время отклика. Некоторые задачи требуют больше времени для обработки, и вы не хотите, чтобы они задерживались, если они не чувствительны ко времени. Вместо этого отправьте сообщение в очередь (в качестве издателя), чтобы подписчик забрал его и обработал «позже».
С тех пор IBM изменила названия своего предложения ESB, поэтому я не буду вдаваться в названия или поставщиков.
ESB позволяет передавать бизнес-информацию между разнородными приложениями на нескольких аппаратных и программных платформах. ESB - это скорее промежуточный уровень, который содержит логику подключения приложений и минимальную бизнес-логику. Это позволяет приложениям делать то, что они умеют лучше всего, не беспокоясь о встраивании какой-либо логики подключения, касающейся того, как взаимодействовать с другим числом N приложений, которым требуются данные от него. Архитектура ESB пытается устранить беспорядок со спагетти "точка-точка" на предприятии.
ESB и Message Broker - это своего рода синонимы друг друга, однако, как было подчеркнуто в одном из приведенных выше ответов, шаблон Messages Broker является частью более крупного домена ESB. Буква "B" в ESB аналогична шине (аппаратному обеспечению) в компьютерной архитектуре. Шина на материнской плате или в компьютере соединяет различные компоненты для функционирования компьютера. ESB - это программная шина, соединяющая различные службы на предприятии. Концентратор и спица - один из шаблонов, поддерживаемых архитектурой ESB. В монолитном мире каждый поставщик имеет собственную архитектуру развертывания высокой доступности, чтобы гарантировать доступность ESB. Последние предложения любого поставщика ESB основаны на модели развертывания на основе микросервисов или размещены в их собственном облаке, известном как iPAAS.Таким образом, это гарантирует, что Bus никогда не выйдет из строя или временно выйдет из строя с самовосстановлением на основе выбранной модели развертывания. Благодаря развертыванию на основе микросервисов или iPAAS, ESB теперь имеют возможности автоматического масштабирования (по горизонтали или вертикали) с функциями, которые зависят от выбранного поставщика.
Для возможностей очень высокого уровня, которые предоставляет ESB, вы можете перейти по следующей ссылке => https://en.wikipedia.org/wiki/Enterprise_service_bus