Изменить

Стиль архитектуры "Интерфейс — очередь — рабочая роль"

Служба приложений Azure

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

Logical diagram of Web-Queue-Worker architecture style.

Также в эту архитектуру часто включают другие компоненты, в том числе:

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

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

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

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

Архитектура "Интерфейс — очередь — рабочая роль" обычно реализуется на основе управляемых вычислительных служб, таких как служба приложений Azure или облачные службы Azure.

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

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

Льготы

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

Сложности

  • К разработке нужно подходить внимательно, иначе внешний интерфейс и (или) рабочая роль могут стать громоздкими и монолитными компонентами, которые трудно обслуживать и обновлять.
  • Если во внешнем интерфейсе и рабочей роли используются общие схемы данных или модули, могут возникнуть скрытые зависимости.
  • Интерфейс веб-интерфейса может завершиться ошибкой после успешного сохранения в базе данных, но перед отправкой сообщений в очередь. Это может привести к возможным проблемам согласованности, так как рабочая роль не будет выполнять свою часть логики. Такие методы, как шаблон исходящих транзакций, можно использовать для устранения этой проблемы, но требуют изменения маршрутизации исходящих сообщений на первый цикл обратно через отдельную очередь. Одна из библиотек, которая обеспечивает поддержку этого метода, — сеанс транзакций NServiceBus.

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

Модель "Интерфейс — очередь — рабочая роль" в службе приложений Azure

В этом разделе описана рекомендуемая архитектура "Интерфейс — очередь — рабочая роль" для службы приложений Azure.

Physical diagram of Web-Queue-Worker architecture style.

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

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

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

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

  • Кэш Azure для Redis хранит состояние сеанса и другие данные, которым требуется низкий доступ к задержке.

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

  • Для хранения данных вы можете выбрать любую технологию, соответствующую требованиям приложения. Можно одновременно использовать несколько технологий хранения данных (Polyglot Persistence). Чтобы проиллюстрировать эту идею, на схеме показаны База данных SQL Azure и Azure Cosmos DB.

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

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

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

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

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

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

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