Опубликован: 10.06.2008 | Уровень: специалист | Доступ: платный | ВУЗ: Компания IBM
Лекция 3:

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

< Лекция 2 || Лекция 3: 12345 || Лекция 4 >

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.

Примеры архитектуры с одним менеджером очередей WebSphere MQ

увеличить изображение
Рис. 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.

Пример центрально-лучевой архитектуры WebSphere MQ

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

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

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

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

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

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

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

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

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

увеличить изображение
Рис. 3.3. Пример архитектуры WebSphere MQ на базе кластера менеджеров
< Лекция 2 || Лекция 3: 12345 || Лекция 4 >
Михаил Завалко
Михаил Завалко
Беларусь, Минск
Artem Bardakov
Artem Bardakov
Россия