Поделиться через

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

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

Логическая схема, показывющая архитектуру веб-Queue-Worker.

Эта архитектура обычно использует следующие компоненты:

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

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

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

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

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

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

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

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

Как правило, для реализации архитектуры Web-Queue-Worker вы используете управляемые вычислительные службы, такие как Служба приложений Azure, Azure Kubernetes Service (AKS), или Azure Container Apps.

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

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

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

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

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

  • Простая архитектура, которую легко понять

  • Простое развертывание и управление

  • Четкое разделение обязанностей между фронтендом и рабочим процессом

  • Асинхронный обмен сообщениями, который отделяет интерфейс от рабочего процесса.

  • Возможность масштабирования внешнего интерфейса и рабочей роли независимо

Сложности

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

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

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

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

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

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

Схема, показывющая архитектуру веб-Queue-Worker.

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

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

  • Веб-приложение App Service служит фронтендом, а приложение Azure Functions выполняет функцию рабочего процесса. Оба компонента выполняются на плане службы приложений Azure.

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on