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

Приложения-контейнеры Azure

.NET

База данных SQL Azure

Azure Cosmos DB

Кэш Azure для Redis

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

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

Архитектура

На изображении показана система управления заказами с микрослужбами в приложениях контейнеров. Он содержит шаги 1–9. Стрелка от значка пользователя к Traefik. Две стрелки из Traefik в раздел службы учета и раздел службы Makeline. Двусторонняя стрелка от Traefik к разделу пользовательского интерфейса. Стрелка указывает из раздела виртуального клиента на раздел службы заказа. Стрелка из раздела службы заказа указывает на раздел "Публикация-подписка". Четыре стрелки из раздела "Публикация-подписка": в раздел службы учета, в раздел службы квитанций, в раздел службы лояльности и в раздел службы Makeline. Стрелка из раздела службы учета в базу данных SQL Azure с помощью Entity Framework. Точки строки из раздела службы квитанций в привязку хранилища BLOB-объектов Azure. Строка из раздела службы лояльности в Azure Cosmos DB. Точки строки из раздела службы Makeline в кэш Azure для Redis. И двойные стрелки со стрелками из раздела службы Makeline в раздел виртуальной рабочей роли.

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

Поток данных

Это решение описывает вымышленную систему управления заказами Red Dog и ее поддержку инфраструктуры Azure. Архитектура состоит из одной среды приложений контейнеров, в которой размещаются 10 приложений микрослужб .NET Core. Решение использует пакет SDK Dapr для интеграции с ресурсами Azure через стандартные блоки публикации, подписки на публикацию, состояние и привязку. Службы также используют правила масштабирования KEDA, чтобы обеспечить масштабирование на основе триггеров событий и сценариев масштабирования до нуля.

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

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

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

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

4. Служба заказа: Api создания, чтения, обновления и удаления для размещения заказов и управления ими.

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

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

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

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

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

Услуга	Входящий трафик	Компоненты Dapr	Правила масштабирования KEDA
Траефик	Внешняя.	Dapr не включен	HTTP
Пользовательский интерфейс	Внутренняя	Dapr не включен	HTTP
Виртуальный клиент	нет	Вызов между службами	Н/П
Служба заказа	Внутренняя	Публикация-подписка: служебная шина Azure	HTTP
Служба учета	Внутренняя	Публикация-подписка: служебная шина	Длина раздела служебной шины, HTTP
Служба квитанций	Внутренняя	Публикация-подписка: служебная шина Привязка: хранилище BLOB-объектов Azure	Длина раздела служебной шины
Служба лояльности	Внутренняя	Публикация-подписка: служебная шина Состояние: Azure Cosmos DB	Длина раздела служебной шины
Служба Makeline	Внутренняя	Публикация-подписка: служебная шина Состояние: кэш Azure для Redis	Длина раздела служебной шины, HTTP
Виртуальная рабочая роль	нет	Вызов между службами Привязка: Cron	Н/П

Примечание.

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

Компоненты

• Application Insights — это расширяемая служба управления производительностью приложений, которую можно использовать для мониторинга динамических приложений и автоматического обнаружения аномалий производительности. В этой архитектуре вы используете Application Insights с Azure Monitor для просмотра журналов контейнеров и сбора метрик из микрослужб.

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

• Кэш Azure для Redis — это распределенный в памяти масштабируемый управляемый кэш Redis. В этой архитектуре он используется в качестве компонента хранилища состояний Dapr для службы Makeline для хранения данных в обрабатываемых заказах.

• Azure Cosmos DB — это служба управляемой базы данных с несколькими моделями NoSQL. В этой архитектуре он используется в качестве компонента хранилища состояний Dapr для службы лояльности для хранения данных о лояльности клиентов.

• Azure Monitor — это единая платформа, которая позволяет собирать, анализировать и действовать на основе данных содержимого клиента из сред инфраструктуры Azure. В этой архитектуре вы используете Azure Monitor с Application Insights для просмотра журналов контейнеров и сбора метрик из микрослужб.

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

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

• База данных SQL — это интеллектуальная, масштабируемая, реляционная служба баз данных, созданная для облака. В этой архитектуре он служит хранилищем данных для службы бухгалтерского учета, которая использует Entity Framework Core для взаимодействия с базой данных. Служба начальной загрузки отвечает за настройку таблиц SQL в базе данных. Затем он запускается один раз, прежде чем установить подключение к службе учета.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность

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

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

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

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

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

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

• Используйте брандмауэр веб-приложения (WAF) для защиты от распространенных уязвимостей. Используйте Azure Front Door или Шлюз приложений Azure для реализации WAF в этой архитектуре.

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

• Используйте управляемое удостоверение для удостоверений рабочей нагрузки. Управляемое удостоверение устраняет необходимость для разработчиков управлять учетными данными проверки подлинности. Например, базовая архитектура проходит проверку подлинности в SQL Server с помощью пароля в строке подключения. По возможности используйте идентификаторы Microsoft Entra для проверки подлинности в SQL Server Azure.

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

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

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

Операционное превосходство

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

Azure Monitor и Application Insights можно использовать для мониторинга приложений контейнеров. Журналы контейнеров можно просматривать, перейдя на портал в область журналов в каждом приложении контейнера, а затем выполнив следующий запрос 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, чтобы просмотреть примерно следующую карту.

Снимок экрана: карта приложения в Application Insights. Изображение содержит семь кругов, представляющих экземпляры. Имена экземпляров — виртуальные клиенты, заказ-служба, чек-gen... ion-service, virtual-worker, make-line-service, loyalty-service и accounting-service. Поток нескольких кривых линий между этими экземплярами. Изображение также содержит состояние Dapr и привязки Dapr.

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

Эффективность производительности

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

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

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

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

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

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

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

• Документация по приложениям-контейнерам
• Сравнение приложений контейнеров с другими параметрами контейнера Azure

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

• Архитектура микрослужб в AKS
• Расширенная архитектура микрослужб AKS
• Непрерывная интеграция и непрерывная доставка приложений AKS с помощью Azure Pipelines

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

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

Архитектура

На изображении показана система управления заказами с микрослужбами в приложениях контейнеров. Он содержит шаги 1–9. Стрелка от значка пользователя к Traefik. Две стрелки из Traefik в раздел службы учета и раздел службы Makeline. Двусторонняя стрелка от Traefik к разделу пользовательского интерфейса. Стрелка указывает из раздела виртуального клиента на раздел службы заказа. Стрелка из раздела службы заказа указывает на раздел "Публикация-подписка". Четыре стрелки из раздела "Публикация-подписка": в раздел службы учета, в раздел службы квитанций, в раздел службы лояльности и в раздел службы Makeline. Стрелка из раздела службы учета в базу данных SQL Azure с помощью Entity Framework. Точки строки из раздела службы квитанций в привязку хранилища BLOB-объектов Azure. Строка из раздела службы лояльности в Azure Cosmos DB. Точки строки из раздела службы Makeline в кэш Azure для Redis. И двойные стрелки со стрелками из раздела службы Makeline в раздел виртуальной рабочей роли.

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

Поток данных

Это решение описывает вымышленную систему управления заказами Red Dog и ее поддержку инфраструктуры Azure. Архитектура состоит из одной среды приложений контейнеров, в которой размещаются 10 приложений микрослужб .NET Core. Решение использует пакет SDK Dapr для интеграции с ресурсами Azure через стандартные блоки публикации, подписки на публикацию, состояние и привязку. Службы также используют правила масштабирования KEDA, чтобы обеспечить масштабирование на основе триггеров событий и сценариев масштабирования до нуля.

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

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

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

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

4. Служба заказа: Api создания, чтения, обновления и удаления для размещения заказов и управления ими.

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

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

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

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

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

Услуга	Входящий трафик	Компоненты Dapr	Правила масштабирования KEDA
Траефик	Внешняя.	Dapr не включен	HTTP
Пользовательский интерфейс	Внутренняя	Dapr не включен	HTTP
Виртуальный клиент	нет	Вызов между службами	Н/П
Служба заказа	Внутренняя	Публикация-подписка: служебная шина Azure	HTTP
Служба учета	Внутренняя	Публикация-подписка: служебная шина	Длина раздела служебной шины, HTTP
Служба квитанций	Внутренняя	Публикация-подписка: служебная шина Привязка: хранилище BLOB-объектов Azure	Длина раздела служебной шины
Служба лояльности	Внутренняя	Публикация-подписка: служебная шина Состояние: Azure Cosmos DB	Длина раздела служебной шины
Служба Makeline	Внутренняя	Публикация-подписка: служебная шина Состояние: кэш Azure для Redis	Длина раздела служебной шины, HTTP
Виртуальная рабочая роль	нет	Вызов между службами Привязка: Cron	Н/П

Примечание.

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

Компоненты

• Application Insights — это расширяемая служба управления производительностью приложений, которую можно использовать для мониторинга динамических приложений и автоматического обнаружения аномалий производительности. В этой архитектуре вы используете Application Insights с Azure Monitor для просмотра журналов контейнеров и сбора метрик из микрослужб.

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

• Кэш Azure для Redis — это распределенный в памяти масштабируемый управляемый кэш Redis. В этой архитектуре он используется в качестве компонента хранилища состояний Dapr для службы Makeline для хранения данных в обрабатываемых заказах.

• Azure Cosmos DB — это служба управляемой базы данных с несколькими моделями NoSQL. В этой архитектуре он используется в качестве компонента хранилища состояний Dapr для службы лояльности для хранения данных о лояльности клиентов.

• Azure Monitor — это единая платформа, которая позволяет собирать, анализировать и действовать на основе данных содержимого клиента из сред инфраструктуры Azure. В этой архитектуре вы используете Azure Monitor с Application Insights для просмотра журналов контейнеров и сбора метрик из микрослужб.

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

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

• База данных SQL — это интеллектуальная, масштабируемая, реляционная служба баз данных, созданная для облака. В этой архитектуре он служит хранилищем данных для службы бухгалтерского учета, которая использует Entity Framework Core для взаимодействия с базой данных. Служба начальной загрузки отвечает за настройку таблиц SQL в базе данных. Затем он запускается один раз, прежде чем установить подключение к службе учета.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность

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

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

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

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

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

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

• Используйте брандмауэр веб-приложения (WAF) для защиты от распространенных уязвимостей. Используйте Azure Front Door или Шлюз приложений Azure для реализации WAF в этой архитектуре.

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

• Используйте управляемое удостоверение для удостоверений рабочей нагрузки. Управляемое удостоверение устраняет необходимость для разработчиков управлять учетными данными проверки подлинности. Например, базовая архитектура проходит проверку подлинности в SQL Server с помощью пароля в строке подключения. По возможности используйте идентификаторы Microsoft Entra для проверки подлинности в SQL Server Azure.

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

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

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

Операционное превосходство

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

Azure Monitor и Application Insights можно использовать для мониторинга приложений контейнеров. Журналы контейнеров можно просматривать, перейдя на портал в область журналов в каждом приложении контейнера, а затем выполнив следующий запрос 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, чтобы просмотреть примерно следующую карту.

Снимок экрана: карта приложения в Application Insights. Изображение содержит семь кругов, представляющих экземпляры. Имена экземпляров — виртуальные клиенты, заказ-служба, чек-gen... ion-service, virtual-worker, make-line-service, loyalty-service и accounting-service. Поток нескольких кривых линий между этими экземплярами. Изображение также содержит состояние Dapr и привязки Dapr.

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

Эффективность производительности

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

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

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

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

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

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

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

• Документация по приложениям-контейнерам
• Сравнение приложений контейнеров с другими параметрами контейнера Azure

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

• Архитектура микрослужб в AKS
• Расширенная архитектура микрослужб AKS
• Непрерывная интеграция и непрерывная доставка приложений AKS с помощью Azure Pipelines