Публикация внутренних API для внешних пользователей

В этом сценарии организация консолидирует несколько API во внутренней среде с помощью службы "Управление API Azure", которая развернута в виртуальной сети.

Архитектура

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

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

Поток данных

Путь потока данных выглядит следующим образом:

1. Разработчики проверяют код в репозитории GitHub, подключенном к агенту конвейера CI/CD, установленному на виртуальной машине Azure.
2. Агент отправляет сборку в приложение API, размещенное в среде ASE балансировки нагрузки.
3. Управление API Azure использует предыдущие API через заголовки HOST, указанные в политике Управление API.
4. Управление API использует DNS-имя Среда службы приложений для всех API.
5. Шлюз приложений предоставляет портал разработчика и API Управление API.
6. Azure Частная зона DNS используется для внутреннего маршрутизации трафика между ASE, Управление API и Шлюз приложений.
7. Внешние пользователи используют предоставленный портал разработчика для использования API через общедоступный IP-адрес Шлюз приложений.

Компоненты

• Виртуальная сеть Azure позволяет ресурсам Azure безопасно взаимодействовать друг с другом, с Интернетом и локальными сетями.
• Частная зона DNS Azure позволяет разрешать доменные имена в виртуальной сети без необходимости добавлять пользовательское решение DNS.
• Управление API Azure помогает организациям публиковать API для внешних пользователей, партнеров и собственных разработчиков, давая им возможность использовать свои данные и услуги.
• Шлюз приложений — это подсистема балансировки нагрузки веб-трафика, которая помогает управлять трафиком в веб-приложениях.
• Среда службы приложений Azure с внутренней подсистемой балансировки нагрузки— это компонент Службы приложений Azure, предоставляющий полностью изолированную и выделенную среду для безопасного выполнения приложений Службы приложений в большом масштабе.
• Azure DevOps — это служба для управления жизненным циклом разработки, которая включает в себя функции для планирования проектов и управления ими, управления кодом, выполнения сборки и выпуска.
• Application Insights — это расширяемая служба управления производительностью приложений (APM) для веб-разработчиков на нескольких платформах.
• Azure Cosmos DB — это глобально распределенная многомодельная служба базы данных Майкрософт.

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

• В сценарии Azure lift-and-shift, развернутом в виртуальной сети Azure, к внутренним серверам можно обращаться напрямую посредством частных IP-адресов.
• При использовании локальных ресурсов экземпляр Управление API может получить доступ к внутренней службе в частном порядке через VPN-шлюз Azure и VPN-подключение типа "сеть — сеть" (IPSec) или ExpressRoute, выполняя гибридный сценарий Azure и локальной среды.
• Вместо службы DNS на основе Azure можно использовать существующие поставщики DNS или поставщики DNS с открытым кодом.
• Внутренние интерфейсы API, развернутые вне Azure, по-прежнему могут быть полезны, так как их можно предоставлять через службу "Управление API".

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

В этом сценарии организация размещает несколько API с помощью среды службы приложение Azure (ASE) и хотят консолидировать эти API с помощью Azure Управление API (APIM), развернутого в виртуальная сеть. Внутренний экземпляр Управления API также может быть предоставлен внешним пользователям для использования всех возможностей этих API. Это внешнее воздействие можно достичь с помощью Шлюз приложений Azure переадресации запросов во внутреннюю службу Управление API, которая, в свою очередь, использует API, развернутые в ASE.

• Веб-API размещаются посредством защищенного протокола HTTPS, и они будут использовать TLS-сертификат.
• Шлюз приложений также настраивается для работы через порт 443 для обработки защищенных и надежных исходящих вызовов.
• Служба "Управление API" настраивается для использования личных доменов с помощью TLS-сертификатов.
• Ознакомьтесь с предлагаемой конфигурацией сети для сред Службы приложений.
• Необходимо явно упомянуть порт 3443, позволяющий Управлению API выполнять операции управления с помощью портала Azure или PowerShell.
• Используйте политики в APIM, чтобы добавить заголовок HOST для API, размещенного в ASE. Это гарантирует, что подсистема балансировки нагрузки ASE будет правильно перенаправлять запросы.
• Управление API принимает DNS-запись ASE для всех приложений, размещенных в среде Службы приложений. Добавьте политику APIM, чтобы явно задать заголовок HOST, чтобы разрешить подсистеме балансировки нагрузки ASE различать приложения в Среда службы приложений.
• Рассмотрим интеграцию управления API Azure в Azure Application Insights, которая также отображает метрики через Azure Monitor.
• Если вы используете конвейеры CI/CD для развертывания внутренних API, рассмотрите возможность создания собственного размещенного агента на виртуальной машине в виртуальная сеть.

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

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

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

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

Надежность

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

Availability

Вы можете развернуть службу Azure Управление API в качестве развертывания с несколькими регионами для повышения доступности, а также сократить задержки. Эта функция доступна только в режиме "Премиум". Служба "Управление API" в этом конкретном сценарии использует интерфейсы API из сред Службы приложений. ApiM можно также использовать для API, размещенных во внутренней локальной инфраструктуре.

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

Устойчивость

Хотя этот пример сценария больше рассказывает о конфигурации, API, размещенные на Среда службы приложений, должны быть достаточно устойчивыми для обработки ошибок в запросах, которые в конечном итоге управляются службой Управление API и Шлюз приложений. Рассмотрим алгоритмы повторных попыток и автоматического выключения в структуре API. Общее руководство по проектированию устойчивых решений см. в разделе Проектирование устойчивых приложений для Azure.

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

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

Так как предыдущий пример сценария размещен полностью в внутренней сети, Управление API и ASE уже развернуты в защищенной инфраструктуре (виртуальная сеть Azure). Вы можете интегрировать Шлюз приложений с Microsoft Defender для облака, чтобы обеспечить простой способ предотвращения, обнаружения и реагирования на угрозы в среде. Общие рекомендации по разработке безопасных решений см. в разделе Документация по системе безопасности Azure.

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

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

Для службы управления API предлагаются четыре уровня: "Разработка", "Базовый", Стандартный" и "Премиум". Подробное руководство по различиям этих уровней можно найти на странице Цены на управление API.

Клиенты могут масштабировать управление API путем добавления и удаления единиц. Мощность единиц зависит от их уровня.

Чтобы просмотреть прогнозируемые затраты и настроить потребности развертывания, вы можете изменить количество единиц масштабирования и экземпляров службы приложений в Калькуляторе цен Azure.

Аналогичным образом можно найти рекомендации по ценам на Среда службы приложений.

Вы можете настроить Шлюз приложений цены в зависимости от требуемого уровня и ресурсов.

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

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

Масштабируемость

Вы можете масштабировать экземпляры Управление API в зависимости от ряда факторов, таких как число и скорость одновременных подключений, тип и количество настроенных политик, размеров запросов и ответов, а также задержки серверной части в API. Параметры масштабирования экземпляров доступны в уровнях "Базовый", "Стандартный" и "Премиум", но привязаны к верхнему масштабу на уровнях "Базовый" и "Стандартный". Экземпляры называются единицами, и их можно масштабировать до двух единиц на уровне "Базовый", до четырех единиц на уровне "Стандартный" и до любого количества единиц на уровне "Премиум". Параметры автомасштабирования также доступны для включения горизонтального увеличения масштаба на основе правил.

Среда службы приложений предназначены для масштабирования с ограничениями на основе ценовой категории. Приложения, размещенные в Среда службы приложений, можно настроить для горизонтального масштабирования (количество экземпляров) или увеличения масштаба (размера экземпляра) в зависимости от требований приложения.

Автомасштабирование Шлюза приложений Azure доступно в составе SKU, обеспечивающего избыточность между зонами, во всех глобальных регионах Azure. Ознакомьтесь с предварительной версией функции, чтобы узнать об автомасштабировании шлюза приложений.

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

Предварительные требования и предположения

1. Необходимо приобрести имя личного домена.
2. Вам нужен СЕРТИФИКАТ TLS (мы использовали подстановочный сертификат из службы сертификатов Azure) для использования одного для всех наших пользовательских доменов. Вы также можете приобрести самозаверяющий сертификат для сценариев тестирования разработки.
3. Это конкретное развертывание использует доменное имя contoso.org и сертификат TLS подстановочного знака для домена.
4. В развертывании используются имена ресурсов и адресные пространства, упомянутые в разделе "Развертывание". Можно настроить имена ресурсов и адресные пространства.

Развертывание и компоновка элементов

Необходимо дополнительно настроить компоненты, развернутые с помощью предыдущего шаблона Resource Manager следующим образом:

1. Виртуальная сеть со следующими параметрами:

   • Имя: ase-internal-vnet
   • Диапазон адресов для виртуальной сети: 10.0.0.0/16
   • Четыре подсети
     • backendSubnet для службы DNS: 10.0.0.0/24
     • apimsubnet для внутренней службы "Управление API": 10.0.1.0/28
     • asesubnet для ILB ASE: 10.0.2.0/24
     • Подсеть виртуальной сети для тестовых виртуальных машин и виртуальной машины внутреннего размещенного агента DevOps: 10.0.3.0/24

2. Служба "Частная зона DNS" (общедоступная предварительная версия), так как для добавления службы DNS требуется, чтобы виртуальная сеть была пустой.

   • Дополнительные сведения см. в руководстве по развертыванию.

3. Среда Службы приложений с внутренней подсистемой балансировки нагрузки (ILB): aseinternal (DNS: aseinternal.contoso.org). После завершения развертывания передайте групповой сертификат для ILB.

4. План Службы приложений с ASE в качестве расположения.

5. Приложение API (Служба приложений для простоты) — (URL:https://srasprest.contoso.org) — srasprest ASP.NET веб-API на основе модели-представления (MVC). После развертывания настройте:

   • Веб-приложение для использования сертификата TLS
   • Application Insights для предыдущих приложений: api-insights
   • Создайте службу Azure Cosmos DB для веб-API, размещенных внутри виртуальной сети: noderestapidb
   • создайте записи DNS в созданной Частной зоне DNS;
   • Azure Pipelines можно использовать для настройки агентов в Виртуальные машины для развертывания кода веб-приложения в внутренней сети.
   • для внутреннего тестирования приложения API создайте тестовую виртуальную машину в подсети виртуальной сети.

6. Создайте службу Управление API:apim-internal

7. Настройте эту службу для подключения к внутренней виртуальной сети в подсети: apimsubnet. После завершения развертывания выполните следующие дополнительные действия.

   • Настройка пользовательских доменов для служб APIM с помощью TLS
     • Портал API (api.contoso.org)
     • Портал разработки (portal.contoso.org)
     • в разделе APIs настройте приложения ASE с помощью добавленной политики DNS-имен ASE для заголовка HOST;
     • Используйте предыдущую созданную тестовую виртуальную машину для тестирования внутренней службы Управление API на виртуальная сеть

   Примечание.

   Тестирование APIM-интерфейсов из портал Azure не будет работать, так как api.contoso.org не может быть открыто разрешено.*

8. Настройте Шлюз приложений для доступа к службе API: apim-gateway через порт 80. Добавьте сертификаты TLS в Шлюз приложений и соответствующие пробы работоспособности и параметры HTTP. Также настройте правила и прослушиватели для использования TLS-сертификата.

После успешного завершения предыдущих шагов настройте записи DNS в записях api.contoso.org CNAME веб-регистратора и portal.contoso.org с общедоступным DNS-именем Шлюз приложений: ase-appgtwy.westus.cloudapp.azure.com Убедитесь, что вы можете получить доступ к порталу разработки из общедоступной версии и проверить API-интерфейсы служб APIM с помощью портал Azure.

Соавторы

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

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

• Срикант Сарва | Старший инженер клиента

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

• Шон Kupfer | Технический писатель

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

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

• Учебник. Импорт и публикация первого API
• Руководство по создавать и публиковать продукт;
• Руководство по Публикация нескольких версий API

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

Перенос веб-приложения с помощью Azure Управление API