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