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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Очень.

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

Итак, в любом случае, веб-запрос обрабатывается службой back-end или, возможно, многими службами, например "искать названия книг", "рисовать корзину покупок", "получать рекламу", "проверять учетную запись пользователя". Наконец, все результаты попадают в очередную очередь, готовые для сбора и ответа пользователя веб-сервером. Как правило, система будет включать тайм-аут около 100 мс, чтобы любые поздние запросы просто отбрасывались. Пользователь видит все, что было обработано за промежуток времени. Это одна из причин, почему некоторые крупные сайты электронной коммерции имеют страницы, которые, как представляется, загружаются поэтапно.

Есть много других вариантов использования...

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

В то время как при RPC, если происходит отключение, фронт-сервер должен быть перезапущен или должен будет обрабатывать событие разъединения. На самом деле это зависит от того, обрабатывает ли каждое сообщение сообщение в очереди в режиме реального времени и передает результаты непосредственно в интерфейс...

Здесь каждый (Message-queueing и RPC related middle-ware) имеют свои сильные и слабые стороны..., а также фактор снижения затрат, такой как поддержка, максимальное время работы, усилия по развитию и обучение, - что здесь biggie поскольку средние продукты действительно запатентованы (несмотря на то, что они соответствуют макете/стандарту "Открытая группа" ) и сложны в настройке и склеивании всего элемента через скрипты.

Ответ 4

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

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

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

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

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