Стиль архитектуры веб-Queue-Worker

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

Следующие компоненты обычно включаются в эту архитектуру:

• Одна или несколько баз данных

• Кэш для хранения значений из базы данных для быстрого чтения

• Сеть доставки содержимого для обслуживания статического содержимого

• Удаленные службы, такие как электронная почта или служба коротких сообщений (SMS), которые поставщики услуг, отличные от Майкрософт, обычно предоставляют

• Поставщик удостоверений для проверки подлинности

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

Интерфейс может включать веб-API. Одностраничные приложения могут использовать веб-API, выполняя вызовы AJAX, или собственное клиентское приложение может использовать его напрямую.

Когда следует использовать эту архитектуру

Архитектура веб-Queue-Worker обычно реализуется с помощью управляемых вычислительных служб, таких как Служба приложений Azure или Служба Azure Kubernetes.

Рассмотрим эту архитектуру для следующих вариантов использования:

• Приложения с относительно простым доменом

• Приложения с длительными рабочими процессами или пакетными операциями

• Сценарии, в которых вы предпочитаете управляемые службы вместо инфраструктуры как услуги (IaaS)

Преимущества

• Архитектура, которая проста и удобна для выполнения

• Развертывание и управление с минимальными усилиями

• Четкое разделение обязанностей

• Разделение интерфейса и рабочего процесса с помощью асинхронного обмена сообщениями

• Независимое масштабирование внешнего интерфейса и рабочей роли

Сложности

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

• Если фронтенд и обработчик совместно используют схемы данных или модули кода, могут быть скрытые зависимости.

• Веб-интерфейс может завершиться сбоем после сохранения данных в базе, но перед отправкой сообщений в очередь, что приводит к проблемам согласованности, так как рабочий процесс не выполняет свою часть логики. Чтобы устранить эту проблему, можно использовать такие методы, как паттерн "Transactional Outbox", которые требуют, чтобы исходящие сообщения вначале возвращались через отдельную очередь. Библиотека сеансов транзакций NServiceBus поддерживает этот метод.

Лучшие практики

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

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

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

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

• При необходимости используйте полиглотную устойчивость. Дополнительные сведения см. в разделе "Общие сведения о моделях данных".

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

Веб-очередь и воркер на службе приложений

В этом разделе описывается рекомендуемая архитектура веб-Queue-Worker, использующая службу приложений.

Схема архитектуры, показывающая пользователям, как они получают доступ к веб-приложениям через Azure CDN для передачи статического контента. Потоки трафика направляются в веб-приложения службы приложений, которые обрабатывают пользовательские запросы и отправляют сообщения в Azure Service Bus или очереди Azure Storage. Функции Azure обрабатывают сообщения из очередей, чтобы выполнять ресурсоемкие задачи. Система включает управляемый Redis Azure для состояния сеанса и доступа к данным с низкой задержкой, Azure Blob Storage для хранения файлов и документов и многоязычное хранилище данных с базой данных Azure SQL и Azure Cosmos DB. Веб-приложения и функции выполняются в планах службы приложений для вычислительной инфраструктуры.

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

Рабочий процесс

• Фронтенд реализуется как веб-приложение App Service, а воркер реализуется как приложение Azure Functions. Веб-приложение и приложение "Функции" связаны с планом службы приложений, который предоставляет экземпляры виртуальной машины.

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

• Azure Managed Redis сохраняет состояние сеанса и другие данные, требующие низкой латентности доступа.

• Сеть доставки содержимого Azure используется для кэширования статического содержимого, например изображений, CSS или HTML.

• Для хранения выберите технологии, которые лучше всего соответствуют потребностям вашего приложения. Этот подход, известный как полиглотная стойкость, использует несколько технологий хранения в одной системе для удовлетворения различных требований. Чтобы проиллюстрировать эту идею, на схеме показана база данных SQL Azure и Azure Cosmos DB.

Дополнительные сведения см. в разделе Высокодоступное зонально избыточное веб-приложение и Создание бизнес-приложений на основе сообщений с помощью NServiceBus и Service Bus.

Другие вопросы

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

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

• Рекомендуется поместить веб-приложение и приложение "Функции" в отдельные планы службы приложений, чтобы они могли масштабироваться независимо.

• Используйте отдельные планы службы приложений для рабочей среды и тестирования.

• Используйте слоты развертывания для управления развертываниями. Этот метод позволяет развернуть обновленную версию в промежуточном слоте, а затем переключить ее на новую версию. Он также позволяет переключиться на предыдущую версию, если во время обновления возникла проблема.

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

• шаблон выравнивания нагрузкиQueue-Based