Развертывание микрослужб с помощью приложений контейнеров Azure и Dapr

В этой статье описывается решение для запуска системы управления заказами с 10 микрослужбами в приложениях контейнеров Azure. Решение также использует рекомендации по микрослужбам с помощью Dapr и масштабирования на основе событий с помощью KEDA.

Dapr и Traefik являются товарными знаками своих соответствующих компаний. Никакое подтверждение не подразумевается использованием этих меток.

Архитектура

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

Поток данных

Это решение использует шаблоны Bicep для выполнения развертывания системы управления заказами Reddog и ее поддержки инфраструктуры Azure. Архитектура состоит из одной среды приложений контейнеров Azure, в которой размещаются 10 микрослужб .NET Core. Вы будете использовать пакет SDK dapr для .NET Core для интеграции с ресурсами Azure с помощью публикации подписки (pub/sub) и стандартных блоков состояния и привязки. Хотя Dapr обычно обеспечивает гибкость при реализации компонентов, это решение основано на мнении. Службы также используют правила масштабирования KEDA, чтобы обеспечить масштабирование на основе триггеров событий и масштабирования до нуля сценариев.

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

1. Traefik: базовый прокси-сервер для маршрутизации запросов пользователей из пользовательского интерфейса в службы учета и Makeline для интерактивной панели мониторинга.

2. Пользовательский интерфейс: панель мониторинга, показывающая заказ в режиме реального времени и агрегированные данные о продажах для системы управления заказами Reddog.

3. Виртуальный клиент: программа моделирования клиентов, которая имитирует заказы клиентов с помощью службы заказов.

4. Служба заказов: API CRUD для размещения заказов и управления ими.

5. Учетная служба: служба, которая обрабатывает, хранит и агрегирует данные заказа. Он преобразует заказы клиентов в значимые метрики продаж, демонстрируемые пользовательским интерфейсом.

6. Служба квитанций: архивная программа, которая создает и хранит квитанции заказов для аудита и исторических целей.

7. Служба лояльности: служба, управляющая программой лояльности, отслеживая баллы вознаграждения клиентов на основе расходов на заказ.

8. Служба Makeline: служба, которая отвечает за управление очередью текущих заказов, ожидающих выполнения. Он отслеживает обработку и завершение заказов службой виртуальной рабочей роли.

9. Виртуальная рабочая роль: программа моделирования рабочей роли, которая имитирует завершение заказов клиентов.

10. Начальная загрузка (не показана): служба, использующая Entity Framework Core для инициализации таблиц в База данных SQL Azure для использования со службой учета.

Компоненты

Это решение использует следующие компоненты.

• Группы ресурсов Azure — это логические контейнеры для ресурсов Azure. Вы используете одну группу ресурсов для структуры всего, связанного с этим решением в портал Azure.
• Приложения контейнеров Azure — это полностью управляемая бессерверная служба контейнеров , используемая для создания и развертывания современных приложений в масштабе. В этом решении вы размещаете все 10 микрослужб в приложениях контейнеров Azure и развертываете их в одной среде приложения-контейнера. Эта среда выступает в качестве безопасной границы вокруг системы.
• Служебная шина Azure — это полностью управляемый корпоративный брокер сообщений с очередями и разделами публикации и подписки. В этом решении используйте его для реализации компонента Dapr pub/sub. Несколько служб используют этот компонент. Служба заказов публикует сообщения на шине, а также службы makeline, бухгалтерского учета, лояльности и получения подписываются на эти сообщения.
• Azure Cosmos DB — это служба управляемой базы данных NoSQL с несколькими моделями. Используйте его в качестве компонента хранилища состояний Dapr для службы лояльности для хранения данных о лояльности клиента.
• Кэш Azure для Redis — это распределенный в памяти масштабируемый управляемый кэш Redis. Он используется в качестве компонента хранилища состояний Dapr для службы Makeline для хранения данных в обрабатываемых заказах.
• База данных SQL Azure — это интеллектуальная, масштабируемая служба реляционной базы данных, созданная для облака. Создайте ее для службы бухгалтерского учета, которая использует Entity Framework Core для взаимодействия с базой данных. Служба начальной загрузки отвечает за настройку таблиц SQL в базе данных, а затем выполняется один раз перед установкой подключения к службе учета.
• Хранилище BLOB-объектов Azure хранит большие объемы неструктурированных данных, таких как текстовые или двоичные файлы. Служба квитанций использует хранилище BLOB-объектов через выходную привязку Dapr для хранения квитанций заказа.
• Traefik является ведущим современным обратным прокси-сервером и подсистемой балансировки нагрузки, что упрощает развертывание микрослужб. В этом решении используйте функцию динамической конфигурации Traefik для выполнения маршрутизации на основе путей из пользовательского интерфейса, которая является Vue.js одностраничным приложением (SPA). Эта конфигурация также включает прямые вызовы API к внутренним службам для тестирования.
• Azure Monitor позволяет собирать, анализировать и действовать на основе данных содержимого клиента из сред инфраструктуры Azure. Вы будете использовать его с Application Insights для просмотра журналов контейнеров и сбора метрик из микрослужб.

Альтернативные варианты

В этой архитектуре вы развернете прокси-сервер Traefik, чтобы включить маршрутизацию на основе пути для API Vue.js. Существует множество альтернативных прокси-серверов с открытым исходным кодом, которые можно использовать для этой цели. Два других популярных проекта — NGINX и HAProxy.

Все инфраструктуры Azure, кроме База данных SQL Azure, используют компоненты Dapr для взаимодействия. Одним из преимуществ Dapr является то, что вы можете заменить все эти компоненты, изменив конфигурацию развертывания приложений-контейнеров. В этом случае Служебная шина Azure, Azure Cosmos DB, Cache for Redis и хранилище BLOB-объектов были выбраны для демонстрации некоторых доступных компонентов 70+ Dapr. Список альтернативных брокеров пабов и вложенных брокеров, хранилищ состояний и выходных привязок находятся в документации Dapr.

Подробности сценария

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

Приложения контейнеров Azure — это полностью управляемая служба контейнеров без сервера для запуска современных приложений в масштабе. Это позволяет развертывать контейнерные приложения с помощью абстракции базовой платформы. Таким образом, вам не нужно управлять сложной инфраструктурой. Приложения контейнеров Azure поддерживаются технологиями с открытым исходным кодом.

Эта архитектура использует интеграцию приложений контейнеров Azure с управляемой версией распределенной среды выполнения приложений (Dapr). Dapr — это проект открытый код, который помогает разработчикам с присущими проблемами в распределенных приложениях, таких как управление состоянием и вызов служб.

Приложения контейнеров Azure также предоставляют управляемую версию автомасштабирования На основе событий Kubernetes (KEDA). KEDA позволяет контейнерам автомасштабирование на основе входящих событий из внешних служб, таких как Служебная шина Azure и Кэш Azure для Redis.

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

Сведения о сравнении приложений контейнеров Azure с другими платформами размещения контейнеров в Azure см. в статье "Сравнение приложений контейнеров с другими параметрами контейнера Azure".

В этой статье описывается решение для запуска системы управления заказами с 10 микрослужбами в приложениях контейнеров Azure. Решение также использует рекомендации по микрослужбам с помощью Dapr и масштабирования на основе событий с помощью KEDA.

Потенциальные варианты использования

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

Эти другие решения имеют аналогичные конструкции:

• Архитектура микрослужб в Службе Azure Kubernetes (AKS)
• Архитектура микрослужб на Функции Azure
• Архитектуры на основе событий

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

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Надежность

Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".

Приложения контейнеров Azure выполняются в Kubernetes за кулисами. Механизмы устойчивости встроены в Kubernetes, которые отслеживают и перезапускают контейнеры или модули pod, если возникают проблемы. Механизмы устойчивости объединяются со встроенным подсистемой балансировки нагрузки для запуска нескольких реплик каждого приложения контейнера. Благодаря этой избыточности решение может терпеть недоступность экземпляра.

Azure Monitor и Application Insights можно использовать для мониторинга приложений контейнеров Azure. Журналы контейнеров можно просмотреть, перейдя на портал на панель журналов в каждом приложении контейнера, а затем выполните следующий запрос Kusto. В этом примере показаны журналы для приложения службы Makeline.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

Карта приложения в Application Insights также показывает, как службы взаимодействуют в режиме реального времени. Затем их можно использовать для отладки сценариев. Перейдите к карте приложения в ресурсе Application Insights, чтобы просмотреть примерно следующее.

Дополнительные сведения о мониторинге приложений контейнеров Azure см. в статье "Мониторинг приложения контейнеров Azure" в приложениях контейнеров Azure.

Оптимизация затрат

Оптимизируйте затраты, просматривая способы сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

Используйте калькулятор цен Azure для оценки стоимости служб в этой архитектуре.

Оптимизация производительности

Эффективность производительности — это возможность масштабирования рабочей нагрузки в соответствии с требованиями, которые вы используете для эффективного использования. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".

Это решение сильно зависит от реализации KEDA в Приложениях контейнеров Azure для масштабирования на основе событий. При развертывании виртуальной службы клиентов он будет постоянно размещать заказы, что приводит к тому, что служба заказов будет масштабироваться с помощью масштабировщика HTTP KEDA. Так как служба заказов публикует заказы на служебной шине, масштабировщики KEDA служебной шины вызывают увеличение масштаба учетных данных, квитанций, Makeline и служб лояльности. Приложения пользовательского интерфейса и контейнера Traefik также настраивают масштабировщики HTTP KEDA, чтобы приложения масштабироваться по мере доступа к панели мониторинга.

Если виртуальный клиент не работает, все микрослужбы в этом решении масштабируется до нуля, за исключением виртуальных рабочих и служб Makeline. Виртуальная рабочая роль не масштабируется, так как она постоянно проверяет выполнение заказа. Дополнительные сведения о масштабировании в приложениях-контейнерах см. в разделе "Настройка правил масштабирования в приложениях контейнеров Azure". Дополнительные сведения о масштабировании KEDA см. в документации KEDA по Scalers.

Развертывание этого сценария

Инструкции по развертыванию см. в демонстрации Red Dog: развертывание приложений контейнеров Azure на GitHub.

Демонстрация Red Dog: интеграция микрослужб — это упакованный шаблон приложения, который строится на предыдущих ресурсах кода, чтобы продемонстрировать интеграцию приложений контейнеров Azure, Служба приложений, функций и Управление API и подготавливает инфраструктуру, развертывает код с помощью GitHub Actions.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Алиса Гиббонс | Облачный собственный глобальный черный пояс

Другие участники:

• Кендалл Роден | Старший менеджер по программам
• Линн Оррелл | Главный специалист по решению (GBB)

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

• Документация по приложениям контейнеров Azure
• Сравнение предложений контейнеров в Azure
• Другие реализации системы управления заказами Reddog:
  • Гибридное развертывание Azure Arc
  • Развертывание AKS
  • Локальная разработка

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

• Архитектура микрослужб в Службе Azure Kubernetes
• Расширенная архитектура микрослужб Службы Azure Kubernetes (AKS)
• CI/CD для приложений AKS с помощью Azure Pipelines