Корпоративная интеграция в Azure с использованием очередей сообщений и событийEnterprise integration on Azure using message queues and events

В рамках этой эталонной архитектуры интегрируются внутренние системы предприятия и разделяются задачи между службами с помощью очередей сообщений и событий. Это повышает надежность и масштабируемость.This reference architecture integrates enterprise backend systems, using message queues and events to decouple services for greater scalability and reliability. Серверные системы могут включать в себя системы "программное обеспечение как услуга" (SaaS), службы Azure и существующие веб-службы предприятия.The backend systems may include software as a service (SaaS) systems, Azure services, and existing web services in your enterprise.

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

АрхитектураArchitecture

Показанная здесь архитектура основана на базовой архитектуре, описываемой в статье Базовые сценарии корпоративной интеграции.The architecture shown here builds on a simpler architecture that is shown in Basic enterprise integration. В архитектуре используется служба Logic Apps для оркестрации рабочих процессов и служба управление API для создания каталогов API.That architecture uses Logic Apps to orchestrate workflows and API Management to create catalogs of APIs.

В этом варианте архитектуры добавлены два компонента, повышающих надежность и масштабируемость системы:This version of the architecture adds two components that help make the system more reliable and scalable:

Асинхронное взаимодействие с помощью брокера сообщений обеспечивает ряд преимуществ по сравнению с непосредственными синхронными вызовами к серверным службам:Asynchronous communication using a message broker provides a number of advantages over making direct, synchronous calls to backend services:

  • Обеспечивает выравнивание нагрузки и способность справляться со скачками рабочих нагрузок с помощью шаблона балансировки нагрузки на основе очередей.Provides load-leveling to handle bursts in workloads, using the Queue-Based Load Leveling pattern.
  • Надежно отслеживает ход выполнения длительных рабочих процессов, состоящих из нескольких этапов или связанных с несколькими приложениями.Reliably tracks the progress of long-running workflows that involve multiple steps or multiple applications.
  • Способствует разделению задач между приложениями.Helps to decouple applications.
  • Интегрируется с существующими системами на основе сообщений.Integrates with existing message-based systems.
  • Позволяет формировать очередь заданий, если серверная система недоступна.Allows work to be queued when a backend system is not available.

При использовании Сетки событий Azure различные компоненты системы могут реагировать на события по мере их возникновения. Выполнять опрос или планировать задачи не требуется.Event Grid enables the various components in the system to react to events as they happen, rather than relying on polling or scheduled tasks. Как и в случае с очередью сообщений, Сетка событий Azure способствует разделению задач между приложениями и службами.As with a message queue, it helps decouple applications and services. Приложение или служба публикует события, а все заинтересованные подписчики уведомляются о них.An application or service can publish events, and any interested subscribers will be notified. Новые подписчики могут добавляться без обновления отправителя.New subscribers can be added without updating the sender.

Многие службы Azure поддерживают отправку событий в Сетку событий Azure.Many Azure services support sending events to Event Grid. Например, приложение логики может прослушивать событие при добавлении новых файлов в хранилище BLOB-объектов.For example, a logic app can listen for an event when new files are added to a blob store. Эта архитектура позволяет реализовать реактивные рабочие процессы, когда при передаче файла или помещении сообщения в очередь запускается ряд процессов.This pattern enables reactive workflows, where uploading a file or putting a message on a queue kicks off a series of processes. Процессы можно выполнять в параллельном режиме или в определенной последовательности.The processes might be executed in parallel or in a specific sequence.

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

Рекомендации, содержащиеся в статье Базовые сценарии корпоративной интеграции, касаются и этой архитектуры.The recommendations described in Basic enterprise integration apply to this architecture. Также применимы приведенные ниже рекомендации.The following recommendations also apply:

Cлужебная шинаService Bus

В Служебной шине доступны два режима доставки: по запросу и принудительно.Service Bus has two delivery modes, pull or push. В модели по запросу получатель постоянно выполняет опрос на наличие новых сообщений.In the pull model, the receiver continuously polls for new messages. Опрос может быть неэффективным, особенно при наличии множества очередей, каждая из которых получает несколько сообщений, или больших интервалов между сообщениями.Polling can be inefficient, especially if you have many queues that each receive a few messages, or if there a lot of time between messages. В модели принудительной отправки при появлении новых сообщений Служебная шина отправляет их через Сетку событий.In the push model, Service Bus sends an event through Event Grid when there are new messages. Получатель подписывается на событие.The receiver subscribes to the event. Когда событие активируется, получатель извлекает следующий пакет сообщений из Служебной шины.When the event is triggered, the receiver pulls the next batch of messages from Service Bus.

Если вы создаете приложение логики для получения сообщений из Служебной шины, рекомендуем использовать модель принудительной отправки, интегрированной с Сеткой событий Azure.When you create a logic app to consume Service Bus messages, we recommend using the push model with Event Grid integration. Такой вариант часто более экономичен, так как приложению логики не нужно выполнять опрос Служебной шины.It's often more cost efficient, because the logic app doesn't need to poll Service Bus. Дополнительные сведения см. в статье об интеграции Служебной шины Azure со службой "Сетка событий".For more information, see Azure Service Bus to Event Grid integration overview. Уведомления службы "Сетка событий Azure" сейчас доступны в Служебной шине Azure ценовой категории "Премиум".Currently, Service Bus Premium tier is required for Event Grid notifications.

Используйте режим получения сообщений PeekLock для доступа к группе сообщений.Use PeekLock for accessing a group of messages. При использовании PeekLock приложение логики может проверять каждое сообщение перед завершением или отменой.When you use PeekLock, the logic app can perform steps to validate each message before completing or abandoning the message. Такой подход защищает от случайной потери сообщений.This approach protects against accidental message loss.

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

Когда активируется триггер службы "Сетка событий", это означает, что произошло по крайней мере одно событие.When an Event Grid trigger fires, it means at least one event happened. Например, если приложение логики получает из Сетки событий триггеры сообщения из Служебной шины, скорее всего, для обработки доступно несколько сообщений.For example, when a logic app gets an Event Grid triggers for a Service Bus message, it should assume that several messages might be available to process.

Вопросы масштабируемостиScalability considerations

Служебная шина Azure уровня "Премиум" может горизонтально масштабировать число единиц обмена сообщениями для достижения более высокой масштабируемости.To achieve higher scalability, the Service Bus Premium tier can scale out the number of messaging units. В конфигурациях уровня "Премиум" может быть одна, две или четыре единицы обмена сообщениями.Premium tier configurations can have one, two, or four messaging units. Дополнительные сведения о масштабировании служебной шины см. в статье Рекомендации по повышению производительности с помощью обмена сообщениями через служебную шину.For more information about scaling Service Bus, see Best practices for performance improvements by using Service Bus Messaging.

Вопросы доступностиAvailability considerations

См. соглашение об уровне обслуживания для каждой службы:Review the SLA for each service:

Для служебной шины Azure уровня "Премиум" рекомендуется реализовать геоизбыточное аварийное восстановление для отработки отказа при серьезном сбое.To enable failover if a serious outage occurs, consider implementing geo-disaster recovery in Service Bus Premium. Дополнительные сведения см. в статье географическое аварийное восстановление в служебной шине Azure.For more information, see Azure Service Bus geo-disaster recovery.

Рекомендации для DevOpsDevOps considerations

См. рекомендации по DevOps в базовой архитектуре Корпоративная интеграцияSee DevOps considerations in Basic Enterprise Integration reference architecture

Вопросы безопасностиSecurity considerations

Защитите служебную шину с помощью подписанного URL-адреса (SAS).To secure Service Bus, use shared access signature (SAS). Вы можете предоставить пользователю доступ к ресурсам Служебной шины Azure с определенными правами, используя проверку подлинности на основе SAS.You can grant a user access to Service Bus resources with specific rights by using SAS authentication. Дополнительные сведения см. в разделе Аутентификация и авторизация в служебной шине.For more information, see Service Bus authentication and authorization.

Если очередь служебной шины должна быть предоставлена ​​как конечная точка HTTP (чтобы разрешить публикацию новых сообщений), для ее защиты путем превращения в интерфейсную следует использовать службу управления API.If you need to expose a Service Bus queue as an HTTP endpoint, for example, to post new messages, use API Management to secure the queue by fronting the endpoint. Затем при необходимости вы можете защитить конечную точку с помощью сертификатов или проверки подлинности OAuth.You can then secure the endpoint with certificates or OAuth authentication as appropriate. Проще всего защитить конечную точку с помощью приложения логики с триггером HTTP-запросов и HTTP-ответов в качестве посредника.The easiest way to secure an endpoint is using a logic app with an HTTP request/response trigger as an intermediary.

Служба "Сетка событий" защищает доставку событий с помощью кода проверки.The Event Grid service secures event delivery through a validation code. Если вы используете события с помощью Logic Apps, проверка выполняется автоматически.If you use Logic Apps to consume the event, validation is automatically performed. Дополнительные сведения см. в разделе Сетка событий: безопасность и проверка подлинности.For more information, see Event Grid security and authentication.

Рекомендации по затратамCost Considerations

Как правило, для оценки затрат используйте Калькулятор цен Azure .In general, use the Azure pricing calculator to estimate costs. Ниже приведены некоторые другие рекомендации.Here are some other considerations.

Управление APIAPI Management

При выполнении вы платите за все экземпляры службы "Управление API".You are charged for all API Management instances when they are running. Если вы увеличили масштаб, но вам не нужен такой уровень производительности все время, можно уменьшить масштаб вручную или настроить автомасштабирование.If you have scaled up and don't need that level of performance all the time, manually scale down or configure autoscaling.

Logic AppsLogic Apps

Logic Apps использует бессерверную модель.Logic Apps uses a serverless model. Cчета выставляются на основе действий и выполнения соединителей.Billing is calculated based on action and connector execution. Дополнительные сведения см. на странице с ценами на Logic Apps.For more information, see Logic Apps pricing.

Очереди служебной шиныService Bus queues

Очереди служебной шины поддерживают как принудительные, так и опрашивающие модели для доставки сообщений.Service Bus queues support both push and pull models for delivering messages. В модели извлечения каждый опрашивающий запрос измеряется как действие.In the pull model, every polling request is metered as an action. Даже при длительном опросе с частотой 30 секунд (по умолчанию) стоимость может быть высокой.Even with long polling at 30 secs (default), cost can be high. Если вам не требуется доставка сообщений в режиме реального времени, рассмотрите возможность использования модели push-уведомлений.Unless you need real-time delivery of messages, consider using the push model.

Очереди служебной шины включены во все уровни (уровни "базовый", "Стандартный" и "Премиум").Service Bus queues are included in all tiers (Basic, standard, and premium tiers). Дополнительные сведения см. в статье цены на служебную шину Azure.For more information, see Azure Service Bus pricing.

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

Служба "Сетка событий" использует бессерверную модель.Event Grid uses a serverless model. Плата начисляется на основе количества операций (выполнения событий).Billing is calculated based on the number of operations (event executions). К операциям относятся приемы событий в домены или разделы, расширенные соответствия, попытки доставки и вызовы управления.Operations include ingress of events to Domains or Topics, advanced matches, delivery attempts, and management calls. Использование до 100 000 операций бесплатно.Usage of up to 100,000 operations is free of charge.

Дополнительные сведения см. на странице цен на службу "Сетка событий".For more information, see Event Grid pricing.

См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.For more information, see the cost section in Microsoft Azure Well-Architected Framework.