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

Служебная шина Azure

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

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

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

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

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

Решение

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

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

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

Льготы

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опора	Как этот шаблон поддерживает цели основных компонентов
Оптимизация затрат сосредоточена на поддержании и улучшении рентабельности инвестиций вашей рабочей нагрузки.	Этот промежуточный шаг может увеличить долголетие существующей системы без необходимости перезаписи, позволяя взаимодействовать с системами, используюющими другую технологию обмена сообщениями или событиями. - CO:07 Стоимость компонентов
Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды.	Это разделение обеспечивает гибкость при переходе на новые технологии обмена сообщениями и событий в рабочих процессах или при наличии разнообразных требований от внешних зависимостей. - OE:06 Развертывание изменений рабочей нагрузки

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

Пример

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

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

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

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

Соавторы

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение

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

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

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

Льготы

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опора	Как этот шаблон поддерживает цели основных компонентов
Оптимизация затрат сосредоточена на поддержании и улучшении рентабельности инвестиций вашей рабочей нагрузки.	Этот промежуточный шаг может увеличить долголетие существующей системы без необходимости перезаписи, позволяя взаимодействовать с системами, используюющими другую технологию обмена сообщениями или событиями. - CO:07 Стоимость компонентов
Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды.	Это разделение обеспечивает гибкость при переходе на новые технологии обмена сообщениями и событий в рабочих процессах или при наличии разнообразных требований от внешних зависимостей. - OE:06 Развертывание изменений рабочей нагрузки

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

Пример

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

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

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

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

Соавторы

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

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

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

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

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

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

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

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