Применение службы сообщений MSMQ в распределенных системах

Рассмотрим возможности, предоставляемые службой MSMQ как промежуточным программным обеспечением с точки зрения требований, предъявляемых к распределенной системе.

Открытость. Требование выполняется частично: используя в качестве сообщения XML-документ с заданной XSD-схемой, можно добиться открытости передаваемых данных. Однако сама технология MSMQ является закрытой и одноплатформенной.
Безопасность. MSMQ поддерживает обычные для Windows NT списки управлением доступа (ACL) для каждой очереди, а при наличии домена AD – прозрачное шифрование сообщений. Таким образом, система, использующая MSMQ, может являться безопасной при развертывании в пределах домена Active Directory.
Расширяемость. MSMQ позволяет создавать масштабирумые системы, поскольку не накладывает ограничений на число машин, считывающих сообщения из одной очереди. Если время обработки сообщения удаленным приложением несравнимо больше времени на его пересылку между очередями, то возможен линейный рост производительности при увеличении числа компьютеров, считывающих и обрабатывающих сообщения из очереди.
Обеспечение целостности данных. MSMQ поддерживает внутренние транзакции, распределенные транзакции среды COM+ и транзакции из System.Transactions. Внутренние транзакции гарантируют, что некоторая последовательность операций компоненты с очередями (например, получение сообщение и отправка ответа на него) будет либо выполнена полностью, либо не выполнена вообще. Транзакции среды COM+ и пространства имен System.Transactions используют координатор распределенных транзакций (MS DTC). При их использовании в последовательность операций, образующих транзакцию, кроме действий с очередями сообщений могут входить операции с любыми службами, поддерживающие распределенные транзакции. Кроме использования транзакций, для повышения надежности в MSMQ следует использовать механизм восстанавливаемых сообщений, который повышает вероятность того, что после принятия службой MSMQ сообщение не будет потеряно при аварийном отключении питания.
Распределенные транзакции COM+ будут рассмотрены в следующем разделе.
Устойчивость. Основной особенностью MSMQ является возможность использования нескольких читающих из очереди серверов. Кроме того, при использовании общих очередей возможен выбор того или иного компьютера с требуемой очередью. В силу этого при использовании очередей сообщений можно избежать возникновения уникальной точки уязвимости.

Таким образом, с точки зрения требований к распределенной системе технология MSMQ обладает многочисленными достоинствами. Однако данная технология промежуточного ПО также имеет ряд важных недостатков.

Использование сообщений происходит непрозрачно для приложения, в отличие от использования механизмов удаленного вызова.
MSMQ неудобно использовать вне LAN/VPN. Если какой-либо компоненте нужно посылать сообщения по протоколу HTTP и при этом получать ответы с результатом обработки своих сообщений, то вероятно предпочтительнее либо использовать VPN, либо рассмотреть вариант использования синхронных удаленных вызовов.
Для реализации модели "запрос-ответ" при использовании MSMQ предпочтительно применять отдельную очередь ответов для каждой посылающей запросы компоненты.

Использование очередей, поддерживающих транзакции, отличается от использования очередей без поддержки транзакций, причем использование внутренних и внешних транзакций заметно отличается. Работа с частными очередями может отличаться от работы с общими очередями. В свою очередь набор возможных операций с частными локальных очередями (.\Private$\LocalQueueName) отличается от такового для удаленных частных очередей (SomeComputer\Private$\RemoteQueueName). Поэтому при использовании MSMQ, как и других промежуточных сред, рекомендуется создать промежуточный слой взаимодействия с ним. Такой слой скрывал бы использование очередей от вышестоящих компонент и позволял безболезненно перейти от частных к общим очередям или наоборот, от внутренних транзакций ко внешним и упростил бы переход на другое промежуточное программное обеспечение.

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

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

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

Отдельным вопрос при использовании службы MSMQ является решение такой проблемы, как единственность используемой очереди. Поскольку очередь находится на каком либо заданном компьютере, она является узким местом с точки зрения устойчивости и расширяемости системы. К сожалению, при использовании MSMQ из .NET Framework нет возможности узнать, например, среднюю длину или время нахождения заявок в очереди для выбора приложением одной из нескольких очередей. Для увеличения устойчивости системы можно было бы выбирать работающую очередь из нескольких возможных, но для проверки готовности компьютера с удаленной очередью видимо скорее имеет смысл реализовать посылку тестового пакета ICMP, чем дожидаться от MSMQ известия о невозможности послать сообщение в очередь. Таким образом, решение вопроса балансировки нагрузки на менеджеры очередей и дублирование их функций в настоящий момент остается за разработчиком распределенной системы.

Содержание раздела

Главная сайта