В каких доменах полезно использовать промежуточное ПО, ориентированное на сообщения, например, AMQP? - PullRequest
56 голосов
/ 05 марта 2010

Какую проблему решает MOM (Message Oriented Middleware)? Масштабируемость? Интеграция

В каком домене они обычно используются и в каких доменах они обычно не используются?

Например, скажем, Google использует такое решение для своей основной поисковой системы или для питания GMail?

А как насчет крупных сайтов, таких как Walmart, eBay, FedEx (в значительной степени магазин Java) и buy.com (в значительной степени магазин MS)? Мама решает проблему там?

Имеет ли смысл когда вы пишете веб-приложение, в котором вы управляете серверной стороной и имеете однородную среду (например, десятки экземпляров Amazon EC2, на которых все работают JVM Linux + Java) там и там, где находятся клиенты, ну Веб-браузеры?

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

Или это «только» для крупных предприятий, где у вас обычно есть счастливое сочетание бесчисленных различных систем, которым необходимо обмениваться данными так или иначе?

Я немного сбит с толку относительно того, для чего они полезны, и я думаю, что на примере того, где они уместны, а где нет, я мог бы лучше понять их использование.

Ответы [ 4 ]

33 голосов
/ 15 марта 2010

Это отличный вопрос.

Основными видами использования сообщений являются: масштабирование, разгрузка, интеграция, мониторинг, обработка событий, маршрутизация, работа в сети, push, мобильность, буферизация, организация очередей, совместное использование задач, оповещения, управление, ведение журнала, пакетная обработка, доставка данных, pubsub, многоадресная рассылка, аудит, планирование, ... и многое другое.В основном: все, что вам нужно, но вы не хотите делать запрос к базе данных.(Кэширование - это еще одна, более длинная история).

Еще один способ взглянуть на это состоит в том, чтобы заметить, что многие приложения раньше создавались, предполагая, что пользователи (люди) будут выполнять действия, которые будут выполняться путем выполнения транзакции вбаза данных (включая чтение, запись).Но сегодня многие действия не инициируются пользователем.Вместо этого они инициируются приложением.Например, «скажите мне, когда книга, которую я хочу купить, есть в наличии».Лучший способ решить этот класс проблем - это обмен сообщениями.Неважно, называете ли вы это промежуточное ПО, веб-пуш или салатная заправка в реальном времени.Это все сообщения.

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

Надеюсь, это поможет.Мы стараемся поддерживать список полезных ссылок об обмене сообщениями здесь

Пожалуйста, свяжитесь с вопросами и комментариями по любому из них, нас очень легко найти.

14 голосов
/ 15 марта 2010

Чтобы ответить на ваши конкретные вопросы:

В каком домене они обычно используются и в каких доменах они обычно не используются?

Как и базы данных, системы обмена сообщениями обрезаютсяповсюду.

Например, скажем, использует ли Google такое решение для своей основной поисковой системы или для питания GMail?

Google использует множество отечественных технологий,но многие из их вкладов с открытым исходным кодом и известных вариантов использования предполагают, что обмен сообщениями является (или должен быть) центральным для некоторых основных служб.

Что насчет крупных сайтов, таких как Walmart, eBay, FedEx (довольномагазин Java) и buy.com (магазин MS)?Мама решает проблему там?

Очень так.

Пример использования - масштабирование запросов веб-страниц.Когда пользователь делает веб-запрос, веб-сервер помещает его в очередь для фоновой обработки.Это означает, что веб-сервер может продолжать работать, пока обрабатывается запрос.Это также означает, что веб-серверу не нужно знать, как обрабатывается запрос, что значительно упрощает обслуживание, обновление и откат системы, поскольку основные части «разъединены».

Так или иначе, веб-запрос обрабатывается серверной службой или, возможно, многими службами, например, «поиск названий книг», «оформление корзины покупок», «получение рекламы», «проверка учетной записи пользователя».«... Наконец, все результаты помещаются в другую очередь, готовую для сбора и ответа пользователя веб-сервером.Обычно система включает время ожидания около 100 мс, поэтому любые поздние запросы просто отбрасываются.Пользователь видит все, что было обработано за промежуток времени.Это одна из причин, по которой некоторые крупные сайты электронной коммерции имеют страницы, которые загружаются поэтапно.

Существует еще много вариантов использования ...

Имеет ли смысл когда вы 'переписываете веб-приложение, в котором вы управляете серверной стороной и имеете однородную среду (скажем, десятки экземпляров Amazon EC2, на которых установлены JVM Linux +), там и где находятся клиенты, ну, в общем, веб-браузеры?

Определенно.Если у вас неизвестное или неограниченное количество пользователей, экземпляров на стороне сервера и задержек приложений, то имеет смысл использовать обмен сообщениями, даже если он является просто масштабируемой подложкой для неблокирующих RPC.

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

Во многих случаях.Один очень распространенный случай - когда сервер отправляет события в настольное приложение, например, игровые события, твиты, ценовые фиды в финансах, системные оповещения ....

Или это «только» для крупного предприятиявещи, где у вас обычно есть счастливое сочетание бесчисленных различных систем, которым нужно общаться так или иначе?

Определенно, не только для тех случаев «унаследованной интеграции», но они также важны.В RabbitMQ крупнейшими клиентами, которые у нас есть, с точки зрения чистого масштаба или объема сообщений, являются облачные провайдеры и крупные поставщики веб-приложений.

6 голосов
/ 05 марта 2010

Я отвечу только на один ответ из предыдущего опыта - взгляните на это промежуточное программное обеспечение , которое используется здесь крупными компаниями - промежуточное программное обеспечение имеет одну цель - склеивать отключенные системы ( написанные на разных языках) вместе, чтобы они могли взаимодействовать друг с другом и оптимизировать бизнес-процесс - Entera, как я уже имел опыт работы, создает промежуточный уровень, в котором Unix-блок, использующий процессы, написанные на C, взаимодействует с системой мэйнфреймов (DB2 , COBOL) через интерфейс, написанный на PowerBuilder (я не называю компанию!).

Из описания, которое я дал, Entera - это промежуточное программное обеспечение, которое содержит несколько вещей - плавную интеграцию потока данных независимо от формата байтов, возможность взаимодействия разных языков с посредником промежуточного программного обеспечения ( брокер - это CORBA или DCE -подобный процесс, который соответствует 'Открытой группе), которая прослушивает определенный порт) и определяется IDL , который делает процесс кажется локальным - если вы понимаете терминологию, используемую в Remoting под Microsoft .NET Framework, вы не за горами! Промежуточное программное обеспечение генерирует заглушки, которые связаны во время компиляции, и управляет созданием процесса, размещением его через порт, многопоточностью во время выполнения, а также современными интерфейсами (такими как .NET, Java PowerBuilder, даже невероятный VB6 (хорошо ... VB.NET для пуристов) может взаимодействовать, открывая соединение с указанным портом на определенном IP-адресе, и используя созданные заглушки, может напрямую взаимодействовать с ним.

Очевидно, из того, что было описано, вы можете увидеть, как унаследованные системы могут вдохнуть новую жизнь и, следовательно, масштабируемость процесса, основным недостатком этого является фактор стоимости, который может исчисляться тысячами долларов. Крупные компании, которые используют мэйнфреймы в качестве своих внутренних систем обработки для выставления счетов / выставления счетов, которые приносят огромные доходы, очевидно, могут позволить себе такой дорогой продукт - для них это было бы похоже на бросание копеек в лужу воды ... из-за использования промежуточного программного обеспечения, которое продлевает бизнес-процесс и вдыхает в него новую жизнь, может продлить бизнес на многие годы в будущем, не беспокоясь о прикрепленной к нему метке «наследство»

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

Edit: @cocotwo: Это именно то, что промежуточное программное обеспечение делает, как вы сказали, что это сантехнический инструмент ... промежуточное программное обеспечение, ориентированное на сообщения, на самом деле не слышно об AFAIK, потому что я представляю, что процессы (функции) должны вызываться так, как если бы они локально видны в домене приложения внешнего интерфейса, чтобы с ним было легко взаимодействовать.

Использование сообщений может иметь свои преимущества перед вызовами RPC в том, что сообщения помещаются в очередь в области безопасного хранения в случае отключения сети - в этом аспекте может происходить некоторое кэширование данных, чтобы разрешить интерфейс продолжить независимо ... это было бы полезно в случаях «обновления статуса определенного номера счета / счета» - односторонней записи данных в серверную часть через промежуточное ПО.

Хорошо, у крупных компаний была бы развитая системная инфраструктура, в которой технические специалисты постоянно работают круглосуточно, чтобы обеспечить бесперебойную доставку потока данных, так что это необходимо учитывать. У компании, с которой я работал, был контракт с IBM Global Support. выполнить, чтобы обеспечить максимальное время безотказной работы 99% с шестью девятью после десятичной запятой ... с горячими заменами / сбалансированными кластерами / зеркальными системами ...

Принимая во внимание, что с RPC, если происходит разъединение, внешний интерфейс должен был бы быть перезапущен или должен был бы обработать событие разъединения. Это действительно зависит от того, обрабатывает ли промежуточное программное обеспечение очереди сообщений каждое сообщение в режиме реального времени и немедленно передает результаты внешнему интерфейсу ...

Именно здесь у каждого (промежуточное ПО для организации очереди сообщений и связанного с RPC) есть свои сильные и слабые стороны ... а также фактор снижения затрат, такой как поддержка, максимальное время безотказной работы, усилия по разработке и обучение - это здесь важно так как промежуточное ПО действительно проприетарное (несмотря на то, что оно соответствует макету / стандартам Open Group) и сложное в настройке и склеивании всего вместе с помощью скриптов.

5 голосов
/ 29 июня 2010

Хорошие ответы и обсуждение здесь. Наша консалтинговая команда имеет два предпочтительных решения для обмена сообщениями: RabittMQ и NXTera - высокоскоростное промежуточное программное обеспечение RPC, современная версия Entera, упомянутая выше. Я и мои партнеры разработали несколько решений, используя RabittMQ, это лучший инструмент, доступный в этой области прямо сейчас. Кроме того, мне довелось работать в компании, которая производит NXTera / Entera.

Из опыта я могу четко сказать, что оба эти продукта отвечают требованиям надежности и минимального обслуживания, как обсуждалось выше. Существуют ситуации, когда сервис обмена сообщениями, такой как RabittMQ, является правильным выбором - когда требуются публикация и подписка, сертифицированная доставка, организация очереди или хранение и пересылка.

В других случаях RPC (удаленные вызовы процедур) являются лучшими и самыми быстрыми решениями для транзакционной и распределенной обработки для корпоративных или облачных приложений. Когда использование RPC является правильным, но SOAP / .NET (да, это реализации RPC) слишком медленные, дорогие или сложные, для нас подходит легкий высокоскоростной промежуточный программный продукт RPC, такой как NXTera / Entera.

Существует некоторое совпадение вариантов использования между промежуточным программным обеспечением RPC и промежуточным программным обеспечением, ориентированным на сообщения, и там, где они есть, вы можете использовать любое из них успешно. Но оба являются сильным и надежным выбором.

Крупные компании, с которыми я работаю, используют как RPC, так и MoM. Что касается интернет-компаний, то Google (Protocol Buffers) и Facebook (Thrift) показывают, что RPC имеют преимущество в современной веб- и облачной разработке.

...