Использование MSMQ, когда у вас уже есть SQL Server и BizTalk

Question

Простой вопрос: есть ли веская причина для добавления MSMQ в существующую инфраструктуру обмена сообщениями, в которой уже есть несколько узлов BizTalk и SQL Server?

Вот фон: у нас есть структура обмена сообщениями для обработки счетов, загрузкасейчас довольно низок (не более 10 000 в день), но растет.Мы используем BizTalk и SQL Server для всей обработки, и мы начали замечать несколько тайм-аутов при вставке (синхронно) в одну из баз данных (НЕ окно сообщения BizTalk).Один из наших старших программистов предложил использовать MSMQ для сохранения (асинхронно) данных, которые вызывают таймаут, и последующей обработки;разработанное им решение работает, и оно должно быть развернуто, но я все еще задаюсь вопросом, было ли это правильным решением, учитывая, что мы могли бы использовать сам BizTalk или SQL Server Service Broker (SSSB).Существует много дискуссий об этих трех технологиях, но они обычно о необходимости выбирать одну из них среди других, я не видел ни одного случая, чтобы кто-то уже имел BizTalk и SSSB и решил добавить MSMQ к смеси.В нашем случае я думаю, что это ненужное дополнение к нашему технологическому стеку, но это может быть моим собственным предубеждением (и также невежеством), так как я знаю SSSB лучше и никогда не делал ничего особенного с MSMQ.Что ты думаешь?

Answer 1

Похоже, вы должны выяснить, почему ваши вставки так долго, и исправить это вместо этого.10 000 / день - это ничего для приличного бокса, на котором запущен SQL Server.

РЕДАКТИРОВАТЬ:

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

Теперь, с учетом сказанного, я не думаю, что в этом случае есть какое-то убедительное преимущество использования MSMQ поверх SSSB (или наоборот).Можно утверждать, что с MSMQ вам нужно вручную закодировать демон слушателя, который выполняет вставки, тогда как с SSSB это происходит автоматически в базе данных.С другой стороны, с помощью MSMQ вы разгружаете хранилище сообщений на другой сервер, потенциально снимая часть немедленной нагрузки с вашего SQL Server.

Answer 2

Я с Хью - мы успешно использовали MSMQ (и IBM MQ Series) с BizTalk для асинхронного транзакционного трафика (в основном финансовых транзакций, где потребность в отслеживаемой, надежной доставке сообщений типа ACID перевешивает любую потребность в транзакциизадержка).

Мы обнаружили, что MSMQ имеет следующие преимущества:

• Транзакционная доставка - сообщения могут быть отправлены целевой системой и вставлены в SQL в течение 2-х фаз UOW..
• Пункт Хью о доставке отделен от доступности системы (и у вас все еще есть очередь недоставленных сообщений, если целевая система не работает в течение неоправданного периода времени)
• Балансировка / регулирование нагрузки - пункт назначенияСистема может защитить от чрезмерной доставки сообщений, вытягивая сообщения из очереди в более равномерном темпе.
• Аудит - использование журналирования в MSMQ обеспечивает дополнительный уровень трассировки.
• Также обратите внимание, что существуетадаптер WCF для MSMQ - не требуется для пользовательских слушателей.

Обычно мы избегаем вызова SQL напрямую из BizTalk:

• Для чтения это равносильно опросу базы данных в надежде, что есть сообщения, готовые для отправки (это можетсоздавать проблемы, связанные с частотой вызовов, т. е. избыточностью, вынужденной задержкой и нагрузкой на SQL, а также конфликтами - например, опрос, когда данные добавляются приложением в таблицы.Мы бы предпочли, чтобы каждое приложение решало, когда отправлять сообщения в BizTalk / ESB.
• для операций записи, если только данные не выгружаются в промежуточную область для обработки целевыми приложениями, это может привести к большей части «бизнеса»перемещение обработки в BizTalk (то есть проверка, применение бизнес-правил и т. д.) - ИМХО, это слишком детально для BizTalk.И, как вы обнаружили, может быть сложно контролировать скорость доставки сообщений в SQL (например, если вы не начнете использовать Singleton Orhcestrations и т. Д.), Что снова вызывает проблемы блокировки / конфликтов.

Answer 3

Я бы сказал, что если вы просто хотите перевести вызовы базы данных в автономный режим, вы можете сделать это с помощью BizTalk (например, путем создания «автономного» хоста - тем самым создав новую очередь хоста).

Где MSMQ действительно превосходит находится на входящей стороне BizTalk.Системы могут звонить в BizTalk, не заботясь о доступности самого BizTalk.Сообщения будут просто зависать, пока BizTalk снова не станет доступен.