Основные компоненты этой архитектуры — это веб-интерфейс , обслуживающий клиентские запросы, а также рабочий процесс , выполняющий ресурсоемкие задачи, длительные рабочие процессы или пакетные задания. Веб-интерфейс взаимодействует с рабочей ролью через очередь сообщений.
Другие компоненты, которые обычно включаются в эту архитектуру:
- Одна или несколько баз данных.
- Кэш для хранения значений из базы данных для быстрого чтения.
- CDN для обслуживания статического содержимого
- Удаленные службы, такие как электронная почта или служба SMS. Часто эти функции предоставляются сторонними лицами.
- Поставщик удостоверений для проверки подлинности.
Веб-сайт и рабочая роль являются бессерверными. Состояние сеанса может храниться в распределенном кэше. Все длительные работы выполняются асинхронно рабочей ролью. Рабочая роль может быть активирована сообщениями в очереди или выполняться по расписанию для пакетной обработки. Рабочая роль является необязательным компонентом. Если длительных операций нет, рабочий элемент может быть опущен.
Интерфейс может состоять из веб-API. На стороне клиента веб-API может использоваться одностраничным приложением, которое выполняет вызовы AJAX или собственным клиентским приложением.
Когда следует использовать эту архитектуру
Архитектура веб-Queue-Worker обычно реализуется с помощью управляемых вычислительных служб, службы приложений Azure или облачных служб Azure.
Рассмотрим этот стиль архитектуры:
- Приложения с относительно простым доменом.
- Приложения с некоторыми длительными рабочими процессами или пакетными операциями.
- Если вы хотите использовать управляемые службы, а не инфраструктуру как службу (IaaS).
Преимущества
- Относительно простая архитектура, которую легко понять.
- Она проста в развертывании и управлении.
- Четкое разделение проблем.
- Интерфейсная часть отделяется от рабочей роли с помощью асинхронного обмена сообщениями.
- Интерфейсная часть и рабочая роль могут масштабироваться независимо.
Сложности
- Без тщательного проектирования внешний интерфейс и рабочая роль могут стать большими монолитными компонентами, которые трудно поддерживать и обновлять.
- Могут быть скрытые зависимости, если интерфейсная часть и рабочие совместно используют схемы данных или модули кода.
- Интерфейс веб-интерфейса может завершиться ошибкой после успешного сохранения в базе данных, но перед отправкой сообщений в очередь. Это может привести к возможным проблемам согласованности, так как рабочая роль не будет выполнять свою часть логики. Такие методы, как шаблон исходящих транзакций , можно использовать для устранения этой проблемы, но требуют изменения маршрутизации исходящих сообщений на первый цикл обратно через отдельную очередь. Одна из библиотек, которая обеспечивает поддержку этого метода, — сеанс транзакций NServiceBus.
Лучшие практики
- Предоставление клиенту хорошо разработанного API. Ознакомьтесь с рекомендациями по проектированию API.
- Автомасштабирование для обработки изменений в нагрузке. Ознакомьтесь с рекомендациями по автомасштабированию .
- Кэшируйте полустатические данные. Ознакомьтесь с рекомендациями по кэшированию .
- Используйте CDN для размещения статического содержимого. Ознакомьтесь с рекомендациями CDN.
- При необходимости используйте сохраняемость polyglot. См. статью [Использование лучшего хранилища данных для задания][polyglot].
- Секционирование данных для повышения масштабируемости, уменьшения количества состязаний и оптимизации производительности. Рекомендации по секционированию данных.
Веб-Queue-Worker в Службе приложений Azure
В этом разделе описана рекомендуемая архитектура веб-Queue-Worker, использующая службу приложений Azure.
Скачайте файл Visio для этой архитектуры.
Рабочий процесс
Интерфейс реализуется как веб-приложение службы приложений Azure , а рабочий элемент реализуется как приложение Функций Azure . Веб-приложение и приложение-функция связаны с планом службы приложений, предоставляющим экземпляры виртуальной машины.
Для очереди сообщений можно использовать служебную шину Azure или очереди службы хранилища Azure . (На схеме показана очередь службы хранилища Azure.)
Кэш Azure для Redis хранит состояние сеанса и другие данные, которым требуется низкий доступ к задержке.
Azure CDN используется для кэширования статического содержимого, например изображений, CSS или HTML.
Для хранения выберите технологии хранения, которые лучше всего соответствуют потребностям приложения. Вы можете использовать несколько технологий хранения (сохраняемость polyglot). Чтобы проиллюстрировать эту идею, на схеме показаны база данных SQL Azure и Azure Cosmos DB.
Дополнительные сведения см. в справочной архитектуре веб-приложения службы приложений и создании бизнес-приложений на основе сообщений с помощью NServiceBus и служебной шины Azure.
Другие вопросы
Не каждая транзакция должна проходить через очередь и рабочую роль в хранилище. Веб-интерфейс может выполнять простые операции чтения и записи напрямую. Рабочие роли предназначены для задач с большим объемом ресурсов или длительных рабочих процессов. В некоторых случаях может не потребоваться рабочая роль вообще.
Используйте встроенную функцию автомасштабирования службы приложений для масштабирования количества экземпляров виртуальной машины. Если нагрузка на приложение соответствует прогнозируемым шаблонам, используйте автомасштабирование на основе расписания. Если загрузка непредсказуема, используйте правила автомасштабирования на основе метрик.
Рекомендуется поместить веб-приложение и приложение-функцию в отдельные планы службы приложений. Таким образом, их можно масштабировать независимо.
Используйте отдельные планы службы приложений для рабочей среды и тестирования. В противном случае, если вы используете тот же план для рабочей среды и тестирования, это означает, что тесты выполняются на рабочих виртуальных машинах.
Используйте слоты развертывания для управления развертываниями. Этот метод позволяет развернуть обновленную версию в промежуточном слоте, а затем переключить ее на новую версию. Он также позволяет переключиться на предыдущую версию, если возникла проблема с обновлением.