Использование брокера сообщений и событий для интеграции корпоративных систем

Сетку событий Azure
Служебная шина Azure

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

Архитектура

Серверные системы, ссылающиеся на эти проекты, включают в себя системы программного обеспечения как услуга (SaaS), Azure службы, службы на основе сообщений и существующие веб-службы в вашей организации.

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

Скачайте файл Visio этой архитектуры.

Подробности сценария

Предыдущая архитектура основана на более простой архитектуре интеграции basic enterprise integration architecture, которая использует Azure Logic Apps для оркестрации рабочих процессов непосредственно с внутренними системами и использует Azure API Management для создания каталогов API.

В этом варианте архитектуры добавлены два компонента, повышающих надежность и масштабируемость системы:

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

  • Использует шаблон выравнивания нагрузки на базе очередей (Queue-Based Load Leveling pattern) для обработки всплесков в рабочих нагрузках с помощью выравнивания.

  • Использует шаблон Publisher-Subscriber, чтобы передавать сообщения нескольким потребителям.

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

  • Помогает отделить приложения

  • Интеграция с существующими системами на основе сообщений

  • Предоставляет возможность постановки сообщений в очередь, когда серверная часть недоступна.

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

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

Рекомендации

Рассмотрим следующие рекомендации. Дополнительные рекомендации см. в статье "Базовая архитектура интеграции предприятия".

Service Bus

Service Bus имеет две модели доставки: модель pull и модель прокси push.

  • Модель извлечения: Получатель постоянно проверяет наличие новых сообщений. Если вам нужно управлять несколькими очередями и временем опроса, опрос может оказаться неэффективным. Но эта модель может упростить архитектуру, так как она удаляет дополнительные компоненты и прыжки данных.

  • Модель проксированной отправки: Получатель изначально подписывается на определенный тип события в теме Event Grid. Когда новое сообщение доступно, Service Bus вызывает и отправляет событие через сетку событий. Затем это событие активирует приемника для извлечения следующего пакета сообщений из Service Bus. Эта модель позволяет системам получать сообщения почти в режиме реального времени, но без использования ресурсов для непрерывного опроса новых сообщений. В этой архитектуре используются дополнительные компоненты, которые необходимо развертывать, управлять и защищать.

При создании рабочего процесса Standard Logic Apps, который использует сообщения Service Bus, рекомендуется использовать встроенные триггеры соединителя Service Bus. Встроенный соединитель упрощает большую часть конфигурации модели выборки без дополнительных затрат. Эта возможность обеспечивает правильный баланс между затратами, управлением областями поверхности и безопасностью, так как соединитель постоянно циклит в подсистеме среды выполнения Logic Apps. Дополнительные сведения см. в разделе встроенные триггеры соединителя Service Bus.

Используйте режим PeekLock для доступа к группе сообщений. При использовании PeekLock приложение логики может валидировать каждое сообщение перед завершением или отказом от него. Этот подход предотвращает случайную потерю сообщения.

Сетка событий

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

Рекомендации

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

Надежность

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

Сведения о гарантированной доступности каждой службы см. раздел SLA для онлайн-сервисов.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Для получения дополнительной информации см. контрольный список по проверке проектирования на безопасность.

Чтобы защитить Service Bus, используйте аутентификацию Microsoft Entra вместе с управляемыми удостоверениями. интеграция Microsoft Entra ID для ресурсов Service Bus обеспечивает Azure управление доступом на основе ролей (Azure RBAC) для точного контроля доступа клиента к ресурсам. Вы можете использовать Azure RBAC для предоставления разрешений субъекту безопасности, например пользователю, группе или субъекту-службе приложений. Принципал службы приложений в этом сценарии является управляемым удостоверением.

Если вы не можете использовать Microsoft Entra ID, используйте проверку подлинности с общей подписью доступа (SAS) для предоставления пользователям доступа и конкретных прав для ресурсов Service Bus.

Если необходимо предоставить очередь или тему Service Bus в качестве HTTP-конечной точки, например, для публикации новых сообщений, используйте API Management, чтобы помочь защитить очередь, защищая конечную точку. Затем можно использовать сертификаты или проверку подлинности OAuth, чтобы защитить конечную точку. Самый простой способ защитить конечную точку — использовать приложение логики с триггером HTTP-запроса или ответа в качестве посредника.

Служба "Сетка событий" помогает защитить доставку событий с помощью кода проверки. Если вы используете Logic Apps для обработки события, проверка выполняется автоматически. Дополнительные сведения см. в разделе Сетка событий: безопасность и проверка подлинности.

Безопасность сети

Рассмотрите возможность безопасности сети на протяжении всего проекта.

Оптимизация затрат

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

Используйте калькулятор цен Azure для оценки затрат. Ниже приведены некоторые другие соображения.

Управление API

Плата взимается за все экземпляры Управления API во время их работы. Если вы увеличите масштабирование, а затем этот уровень производительности больше не требуется, можно вручную уменьшать масштаб или настроить автомасштабирование.

Для малых рабочих нагрузок рассмотрите уровень потребления, который является дешёвым бессерверным вариантом. Плата за тариф потребления взимается за каждый вызов API. Оплата за другие уровни производится за час.

Логические приложения

Logic Apps использует бессерверную модель. Биллинг вычисляется исходя из количества действий и вызовов соединителя. Дополнительные сведения см. на странице с ценами на Logic Apps.

Service Bus очереди, разделы и подписки

Очереди и подписки Service Bus поддерживают обе модели: прокси-модель push и pull-модель для доставки сообщений. В pull-модели каждый запрос на опрос учитывается как действие. Даже если вы устанавливаете длительное опрашивание по умолчанию на 30 секунд, стоимость может быть высокой. Если вам не нужна доставка сообщений в режиме реального времени, рассмотрите возможность использования прокси-модели отправки.

Очереди Service Bus включены во все уровни: Базовый, Стандартный и Премиум. Service Bus разделы и подписки доступны на уровнях "Стандартный" и "Премиум". Дополнительные сведения см. в разделе цены на Service Bus.

Сетка событий

Служба "Сетка событий" использует бессерверную модель. Выставление счетов вычисляется на основе количества операций. К операциям относятся события, которые отправляются в домены или разделы, расширенные совпадения, попытки доставки и вызовы управления. Использование до 100 000 операций совершается бесплатно.

Дополнительные сведения см. в разделе цены на Event Grid и оптимизации затрат Well-Architected Framework.

Эффективность работы

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

Базовая эталонная архитектура корпоративной интеграции предоставляет рекомендации по шаблонам DevOps, которые соответствуют принципу Well-Architected Framework Operations Excellence .

Автоматизируйте операции восстановления как можно больше, чтобы повысить эффективность работы. Учитывая автоматизацию, вы можете объединить мониторинг журналов Azure с Azure Automation, чтобы автоматизировать отработку отказа ресурсов Service Bus. Пример логики автоматизации для запуска отработки отказа см. в разделе "Поток отработки отказа".

Уровень производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки проектного решения на эффективность производительности .

Чтобы обеспечить более высокую масштабируемость, уровень Service Bus Premium может масштабировать количество единиц обмена сообщениями. Для получения дополнительной информации см. уровни обмена сообщениями "Премиум" и "Стандартный" в Service Bus и функция Автомасштабирования.

Дополнительные рекомендации по использованию Service Bus см. в статье Лучшие практики для повышения производительности с помощью обмена сообщениями Service Bus.

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