Шаблон моста обмена сообщениями

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

Контекст и проблема

Многие организации и рабочие нагрузки могут непреднамеренно использовать ИТ-системы, использующие несколько инфраструктур обмена сообщениями, таких как Microsoft Message Queueing (MSMQ), RabbitMQ, Служебная шина Azure и Amazon SQS. Эта проблема может возникнуть из-за слияний, приобретений или из-за расширения текущих локальных систем до облачных компонентов для повышения эффективности затрат и удобства обслуживания.

Разработчики могут решить эту проблему, изменив интегрированные системы для обмена данными с помощью веб-служб на основе HTTP. Однако этот подход имеет недостатки, в том числе:

• Системы должны быть изменены путем добавления HTTP-клиента на одной стороне и обработчика HTTP-запросов на другую. Затем системы должны быть повторно протестированы и повторно развернуты.
• Конечные точки HTTP должны размещаться, что повышает сложность при обеспечении безопасности и высокой доступности веб-служб.
• Частые проблемы с сетевым подключением, для которых требуются пользовательские механизмы повторных попыток.

Решение

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

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

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

Льготы

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

Недостатки

• Дополнительные возможности одного или обоих технологий обмена сообщениями могут быть недоступны на мостовом маршруте.
• Мостовой маршрут должен учитывать ограничения обоих технологий. Например, максимальный размер сообщения может составлять 4 МБ в MSMQ, но только 64 КБ в очередях служба хранилища Azure.

Проблемы и рекомендации

При реализации шаблона моста обмена сообщениями следует учитывать следующие моменты:

• Если одна из интегрированных систем использует распределенные транзакции, например координатор распределенных транзакций (DTC), необходимо реализовать механизм дедупликации в мосту.

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

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

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

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

Когда следует использовать этот шаблон

Используйте шаблон моста обмена сообщениями, если необходимо:

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

Этот шаблон может не подходить, если:

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

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон моста обмена сообщениями можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах платформы Azure Well-Architected Framework. Например:

Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.

Пример

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

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

Команда решает использовать шаблон моста обмена сообщениями для подключения двух систем. Шаблон состоит из двух частей. Одна часть получает сообщения из существующей очереди MSMQ и пересылает их в служебная шина. Другая часть принимает сообщения из служебная шина и пересылает их в существующую очередь MSMQ.

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Роб Багби | Руководство по содержимому основной архитектуры
• Кайл Бейли | Программист
• Udi Dahan | Основатель и генеральный директор конкретного программного обеспечения
• Чад Киттель | Главный инженер программного обеспечения
• Брайан Ламос | Отношения разработчика
• Szymon Pobiega | Инженер

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

• Описание шаблона моста обмена сообщениями из сообщества шаблонов интеграции предприятия.
• Узнайте, как реализовать мост обмена сообщениями в платформе Spring Java.
• Мост QPid можно использовать для моста технологий обмена сообщениями с поддержкой AMQP.
• Мост обмена сообщениями NServiceBus — это реализация моста обмена сообщениями по очереди .NET, который поддерживает различные инфраструктуры обмена сообщениями, включая MSMQ, служебная шина и хранилище очередей Azure.
• NServiceBus.Router — это проект с открытым исходным кодом, который реализует шаблон моста обмена сообщениями. Кроме того, он позволяет выполнять мост более двух технологий в одном экземпляре и имеет расширенные возможности маршрутизации сообщений.

Связанные ресурсы

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