В каких доменах полезно использовать промежуточное ПО, ориентированное на сообщения, например, AMQP?
Какую проблему решает MOM (Message Oriented Middleware)? Масштабируемость? Интеграция?
В каком домене они обычно используются и в каких доменах они обычно не используются?
Например, скажем, Google использует такое решение для своей основной поисковой системы или для питания GMail?
А как насчет крупных сайтов, таких как Walmart, eBay, FedEx (в значительной степени магазин Java) и buy.com (в значительной степени магазин MS)? Мама решает проблему там?
Имеет ли какой-то смысл, когда вы пишете веб-приложение, в котором вы управляете серверной стороной и имеете однородную среду (скажем, десятки экземпляров Amazon EC2, на которых все работают JVM Linux + Java) там и где клиенты, ну, в общем, веб-браузеры?
Имеет ли это смысл для настольных приложений, которым необходимо общаться с сервером?
Или это "только" для крупных корпоративных предприятий, где у вас обычно есть счастливое сочетание бесчисленного множества различных систем, которые должны взаимодействовать так или иначе?
Я немного сбит с толку относительно того, для чего они полезны, и я думаю, что с примером того, где они уместны, а где нет, я мог бы лучше понять их использование.
4 ответа
Это большой вопрос.
Основное использование сообщений: масштабирование, разгрузка, интеграция, мониторинг, обработка событий, маршрутизация, работа в сети, push, мобильность, буферизация, организация очередей, совместное использование задач, оповещения, управление, ведение журналов, пакет, доставка данных, pubsub, multicast, аудит, планирование,... и многое другое. В основном: все, что вам нужно, но вы не хотите делать запрос к базе данных. (Кэширование - другая, более длинная история).
Другой способ взглянуть на это - заметить, что многие приложения раньше создавались, предполагая, что пользователи (люди) будут выполнять действия, которые будут выполнены при выполнении транзакции в базе данных (включая чтение, запись). Но сегодня многие действия не инициируются пользователем. Вместо этого они инициируются приложением. Например, "скажите мне, когда книга, которую я хочу купить, есть в наличии". Лучший способ решить этот класс проблем - это обмен сообщениями. Неважно, называете ли вы это промежуточное ПО, веб-пуш или салатная заправка в реальном времени. Это все сообщения.
Когда вы позволяете приложениям инициировать или реагировать на события, масштабирование становится намного проще, поскольку ваша архитектура может основываться на слабосвязанных компонентах. Также намного проще интегрировать эти компоненты, если ваш обмен сообщениями основан на стабильном, масштабируемом и удобном инструменте, предпочтительно с использованием открытых стандартных API и протоколов.
Надеюсь, это поможет. Мы стараемся поддерживать список полезных ссылок об обмене сообщениями здесь.
Пожалуйста, свяжитесь с вопросами и комментариями по любому из этого, нас очень легко найти.
Чтобы ответить на ваши конкретные вопросы:
В каком домене они обычно используются и в каких доменах они обычно не используются?
Как и базы данных, системы обмена сообщениями возникают везде.
Например, скажем, Google использует такое решение для своей основной поисковой системы или для питания GMail?
Google использует множество собственных технологий, но многие из их вкладов в открытый исходный код и известные варианты использования предполагают, что обмен сообщениями является (или должен быть) центральным для некоторых основных служб.
А как насчет крупных сайтов, таких как Walmart, eBay, FedEx (в значительной степени магазин Java) и buy.com (в значительной степени магазин MS)? Мама решает проблему там?
Даже очень.
Пример использования - масштабирование запросов веб-страниц. Когда пользователь делает веб-запрос, веб-сервер помещает его в очередь для фоновой обработки. Это означает, что веб-сервер может продолжать работать, пока обрабатывается запрос. Это также означает, что веб-серверу не нужно знать, как обрабатывается запрос, что значительно упрощает обслуживание, обновление и откат системы, поскольку основные части "разъединены".
Так или иначе, веб-запрос обрабатывается серверной службой или, возможно, многими службами, например, "поиск названий книг", "оформление корзины покупок", "получение рекламы", "проверка учетной записи пользователя"... Наконец, все результаты помещаются в другую очередь, готовые для сбора и ответа пользователя веб-сервером. Обычно система включает время ожидания около 100 мс, поэтому любые поздние запросы просто отбрасываются. Пользователь видит все, что было обработано за промежуток времени. Это одна из причин, почему некоторые крупные сайты электронной коммерции имеют страницы, которые загружаются поэтапно.
Есть еще много вариантов использования...
Имеет ли какой-то смысл, когда вы пишете веб-приложение, в котором вы управляете серверной стороной и имеете однородную среду (скажем, десятки экземпляров Amazon EC2, на которых все работают JVM Linux + Java) там и где клиенты, ну, в общем, веб-браузеры?
Определенно. Если у вас есть неизвестное или неограниченное количество пользователей, экземпляров на стороне сервера и задержек приложений, то имеет смысл использовать обмен сообщениями, даже если он является просто масштабируемой подложкой для неблокирующих RPC.
Имеет ли это смысл для настольных приложений, которым необходимо общаться с сервером?
Во многих случаях. Один очень распространенный случай - когда сервер отправляет события в настольное приложение, например, игровые события, твиты, ценовые потоки в финансах, системные оповещения...
Или это "только" для крупных корпоративных предприятий, где у вас обычно есть счастливое сочетание бесчисленного множества различных систем, которые должны взаимодействовать так или иначе?
Определенно не только для тех случаев "унаследованной интеграции", но они также важны. В RabbitMQ крупнейшими клиентами, которые у нас есть, с точки зрения чистого масштаба или объема сообщений, являются облачные провайдеры и крупные поставщики веб-приложений.
Я отвечу только на один ответ из предыдущего опыта - взгляните на это промежуточное программное обеспечение, которое используется здесь крупными компаниями - промежуточное программное обеспечение имеет одну цель - склеить разъединенные системы (написанные на разных языках) вместе, чтобы они может взаимодействовать друг с другом и оптимизировать бизнес-процесс - 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) и сложное в настройке и склеивании всего вместе с помощью скриптов.
Хорошие ответы и обсуждение здесь. У нашей консалтинговой команды есть два предпочтительных решения для обмена сообщениями: 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 имеют преимущество в современной веб- и облачной разработке.