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

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

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

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

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

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

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

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

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

Именно здесь у каждого (Message-queueing и RPC middle-ware) есть свои сильные и слабые стороны... а также фактор снижения стоимости, такой как поддержка, максимальное время работы, усилия по разработке и обучение - это очень важно, так как middle-ware действительно проприетарные (несмотря на следование схеме/стандартам 'The Open Group') и сложные в настройке и склеивании всего этого вместе с помощью скриптов.

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

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

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

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

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

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

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

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

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

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

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

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

Очень.

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

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

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

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

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

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

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

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

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

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

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

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

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

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