Средства поддержки очередей сообщений в WebSphere MQ

3.3. Расширяемость и скорость работы

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

3.3.1. Расширяемость менеджеров очередей WebSphere MQ

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

Количество параллельных активных подключений к одному менеджеру может достигать десятков, сотен, а иногда – тысяч. Такая совокупность соединений может одновременно обрабатывать сообщения из одних и тех же очередей, которые реализуются одним менеджером. WebSphere MQ предполагает гибкость в реализации обращающихся к менеджерам очередей приложений и допускает увеличение их пропускной способности и скорости их работы.

Приложения, которые обращаются к инфраструктуре WebSphere MQ, могут разрабатываться и размещаться на серверах приложений WebSphere Application Server, что позволит им пользоваться возможностями расширения WebSphere Application Server как такового.

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

3.3.2. Архитектура с одним менеджером очередей сообщений

Асинхронность приема и отправления сообщений в WebSphere MQ помогает плавно наращивать возможности приложений даже тогда, когда в предоставлении службы задействована одна-единственная машина.

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

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

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

Такова простейшая форма инфраструктуры WebSphere MQ: единственный менеджер очередей сообщений реализует службу, необходимую подключенным к нему приложениям. Эта схема показана на правой части рис. 3.1.

увеличить изображение
Рис. 3.1. Примеры архитектуры с одним менеджером очередей WebSphere MQ

3.3.3. Центрально-лучевая архитектура WebSphere MQ

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

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

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

Еще одним вариантом служит подключение обращающихся к работе служб приложений к менеджеру в роли клиентов по быстрому сетевому соединению; скажем, так можно подключить все приложения, вызывающие службу в офисе филиала. Благодаря наличию этого менеджера связь со службами на другом основном (hub) менеджере очередей становится асинхронной. При этом в реализации приложений как таковых может иметься внешний интерфейс к службе (к примеру, дающий возможность использовать ее через сеть Интернет и Web-браузер).

Те менеджеры очередей, которые предоставляют доступ к службам hub-менеджера, носят название spoke-менеджеров (spokes) центрально-лучевой ("hub and spoke") архитектуры WebSphere MQ.

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

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

Примером центрально-лучевой архитектуры служит рис. 3.2.

увеличить изображение
Рис. 3.2. Пример центрально-лучевой архитектуры WebSphere MQ

3.3.4. Кластеры менеджеров как возможность гибкого расширения

Более гибким подходом является объединение менеджеров очередей в кластер (queue manager cluster). Кластеры менеджеров дают возможность множеству экземпляров одной-единственной службы располагаться на нескольких менеджерах очередей.

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

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

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

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

Пример инфраструктуры WebSphere MQ на базе кластера менеджеров показан на рис. 3.3.

увеличить изображение
Рис. 3.3. Пример архитектуры WebSphere MQ на базе кластера менеджеров