Возможно ли и целесообразно использовать IBM MQ без локального администратора очередей?
Моя команда находится в процессе создания приложения, которое будет развернуто в AWS EC2 и будет взаимодействовать с локальными устаревшими системами через IBM MQ (ранее известный как WebSphere MQ, ранее известный как MQSeries).
У нас уже есть администраторы очередей IBM MQ. Нам также нужно развернуть один в EC2? Нужно ли их развертывать на блоках EC2, где будет работать наше приложение?
Я новичок в IBM MQ, хотя у меня есть некоторый опыт работы с RabbitMQ. В компании есть люди с большим опытом работы с IBM MQ, но нет облачных приложений. Они мне несколько раз говорили, что нам нужно запустить менеджер очередей с нашим приложением, который затем может пересылать другим администраторам очередей, но на облачной машине с временным диском, что не имеет никакого смысла для меня - это не добавляет надежности.
Мы могли бы развернуть администратор очередей на машине EC2 с томом EBS, что было бы более разумно, и наши приложения могли бы с этим поговорить. Но разве это лучше, чем просто поговорить напрямую с существующими администраторами очередей в наших собственных помещениях?
Чтобы добавить еще больше удовольствия, мы развертываем не приложение непосредственно в EC2, а в Cloud Foundry, развернутом в EC2, поэтому экземпляры приложений работают внутри контейнеров, на которые мы не имеем большого влияния.
1 ответ
Беспокоиться о томе, на котором будет развернут администратор очередей, не стоит беспокоиться. В IBM MQ есть конкретные рекомендации о том, какие тома поддерживаются, а какие нет. Загляните в MQ Knowledge Center для получения дополнительной информации.
Приложения MQ могут запускаться локально или удаленно (для администратора очередей).
(1) Приложения MQ, которые подключаются локально (режим связывания) к администратору очередей, могут значительно упростить разработку и поддержку приложений, поскольку НИКАКАЯ сеть не участвует в получении и / или отправке сообщений.
(2) Приложения MQ, которые подключаются удаленно (в режиме клиента) к администратору очередей, намного сложнее. Кто-то недавно опубликовал аналогичный вопрос на MQ ListServer, и вот превосходный ответ T.Rob Wyatt.
Существует множество проблем при консолидации от автономных QMgrs до общих концентраторов. Тот, о котором вы спрашиваете, является одним из самых механических и неинтересных из всех. Как отмечает FJ, существуют некоторые последствия для безопасности и проблемы с подключением, с которыми вы сами столкнулись. Позвольте мне дать вам сводку некоторых других. Степень, с которой вы сталкиваетесь с большинством из них, зависит от того, насколько среда в настоящее время является автономной и как много она имеет в настоящее время. Исключением является целостность данных при переключении на клиента, поэтому я сначала расскажу об этом.
Нет потерянных или дублированных сообщений, порядок в основном гарантирован:
Это требует транзакционности XA. XA налагает свой собственный набор конструктивных ограничений, среди которых то, что рассматриваемое приложение не может переключиться на другой QMgr. Как правило, MQ ведет себя так, как все ожидают, поскольку при нормальных обстоятельствах никакие сообщения не дублируются, не теряются и не разрываются.
Двойные сообщения, возможны беспорядки:
Это требует как минимум однофазного коммита. Если вы получаете сообщение из очереди в syncpoint, а клиентское приложение получает 2059 при следующем вызове API, вы можете быть уверены, что сообщение будет откатано и не потеряно. Но приложение увидит его снова, и если оно было обработано правильно в первый раз, оно окажется обманом. Кроме того, если приложение получило 2059 на COMMIT после PUTING сообщения, у него нет другого выбора, кроме как предположить, что COMMIT не удалось, и снова вывести PUT. В отличие от "функционального дубликата" из GET, он генерирует несколько идентичных сообщений.
Канальный агент, удерживающий транзакцию с одним или несколькими GET, не выпустит сообщения, пока MQ или TCP его не истечут и не разорвут потерянное соединение. Поскольку откат не обязательно происходит до повторного подключения приложения, он может получить последующие сообщения, не находящиеся под этой точкой синхронизации. Когда осиротевший канал будет убит и сообщения снова появятся в очереди, они будут доставлены, но порядок будет нарушен.
Возможны дублирование, пропущенные сообщения, возможность беспорядка: клиентские соединения, которые не используют XA и однофазный COMMIT, могут потерять или продублировать сообщения или дезорганизовать их по причинам, указанным выше.