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

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

Архитектура

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

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

Поток данных

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

1. Разработчики проверка в коде в репозиторий GitHub, подключенный к агенту конвейера CI/CD, установленному на виртуальной машине Azure.
2. Агент отправляет сборку в приложение API, размещенное в ASE с внутренним балансировщиком нагрузки.
3. Azure Управление API использует предыдущие 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.

надежность;

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

Доступность

Вы можете развернуть службу Azure Управление API как развертывание с несколькими регионами, чтобы повысить доступность, а также уменьшить задержки. Эта функция доступна только в режиме Premium. Служба "Управление 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), чтобы использовать его для всех наших личных доменов. Вы также можете приобрести самозаверяющий сертификат для сценариев Dev Test.
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 (для простоты — Службы приложений) srasprest (URL-адрес: https://srasprest.contoso.org) — веб-API ASP.NET на основе 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 на виртуальная сеть

   Примечание

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

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

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

Соавторы

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

Основной автор:

• Срикант Сарва | Старший инженер по работе с клиентами

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

• Шон Купфер | Технический модуль записи

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

Дальнейшие действия

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

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

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