В этом сценарии компания электронной коммерции в сфере путешествий перенесла устаревшее веб-приложение с помощью Управления API Azure. Новый пользовательский интерфейс будет размещен как платформа как приложение paaS в Azure, и он будет зависеть от существующих и новых API HTTP. Эти API будут отправляться с более разработанным набором интерфейсов, что позволит повысить производительность, упростить интеграцию и будущую расширяемость.
Архитектура
Скачайте файл Visio этой архитектуры.
Рабочий процесс
- Существующее локальное веб-приложение продолжает напрямую использовать существующие локальные веб-службы.
- Вызовы существующего веб-приложения к существующим службам HTTP остаются неизменными. Для корпоративной сети эти вызовы являются внутренними.
- Исходящие вызовы выполняются из Azure в существующие внутренние службы:
- Команда безопасности позволяет трафику из экземпляра Управление API передаваться через корпоративный брандмауэр в существующие локальные службы с помощью безопасного транспорта (HTTPS или SSL).
- Команда операций разрешает входящий вызовы к службам только из экземпляра Управление API. Он соответствует этому требованию, добавив IP-адрес экземпляра Управление API в список разрешений в периметре корпоративной сети.
- Новый модуль настраивается в локальном конвейере запросов для служб HTTP (для действия только с подключениями, поступающими извне). Конвейер проверяет сертификат, который Управление API предоставляет.
- Новый API:
- Отображается только через экземпляр Управление API, который предоставляет фасад API. Новый API не обращается напрямую.
- Разрабатывается и публикуется в качестве веб-API Azure PaaS.
- Настроен (с помощью параметров для функции веб-приложения службы приложение Azure) принимать только виртуальный IP-адрес Управление API (VIP).
- Размещается в веб-приложения с включенным безопасным транспортом (HTTPS или SSL).
- Включена авторизация, предоставляемая службой приложение Azure через идентификатор Microsoft Entra ID и Open Authorization (OAuth) 2.
- Новое веб-приложение на основе браузера зависит от экземпляра Azure Управление API для существующего HTTP-API и нового API.
- Компания по электронной коммерции теперь может направлять некоторых пользователей в новый пользовательский интерфейс (для предварительной версии или тестирования), сохраняя старый пользовательский интерфейс и существующие функциональные возможности параллельно.
Экземпляр Управление API настроен для сопоставления устаревших служб HTTP с новым контрактом API. В этой конфигурации новый веб-интерфейс не знает об интеграции с набором устаревших служб или API и новых API.
В будущем команда проекта постепенно добавит новым API-интерфейсам функциональность и удалит исходные службы. Команда будет обрабатывать эти изменения в Управление API конфигурации, оставляя интерфейсный пользовательский интерфейс не затронутым и избегая повторной разработки.
Компоненты
- Azure Управление API абстрагирует внутренние API, а также добавляет кросс-режущие функции и обнаружение для разработчиков и приложений. В этом сценарии можно использовать Управление API в качестве фасада нового клиентского приложения для согласованного использования и использования современных стандартов. Так как Управление API фасады как существующих, так и новых API, разработчики могут модернизировать устаревшие серверные части за фасадом Управление API в итеративном режиме и с минимальными до нуля влияния на новую интерфейсную разработку.
- служба приложение Azure — это служба платформы как услуга (PaaS) для размещения веб-сайтов, которая предоставляет такие функции, как безопасность, балансировка нагрузки, автомасштабирование и автоматическое управление. приложение Azure Служба — отличный выбор для новых API, разработанных для этого решения, так как он обеспечивает гибкое размещение по ключу, что позволяет команде DevOps сосредоточиться на предоставлении функций.
Альтернативные варианты
Если организация планирует полностью переместить свою инфраструктуру в Azure, включая виртуальные машины, в которых размещаются устаревшие приложения, Управление API по-прежнему является отличным вариантом, так как он может выступать в качестве фасада для любой адресной конечной точки HTTP.
Если организация решила сохранить существующие конечные точки закрытыми и не предоставлять их публично, Управление API экземпляр организации может быть связан с azure виртуальная сеть:
- Если Управление API связана с виртуальной сетью Azure, организация может напрямую обращаться к внутренней службе через частные IP-адреса.
- В локальном сценарии экземпляр Управление API может приватно обратиться к внутренней службе через VPN-подключение Azure VPN-шлюз и VPN-подключение типа "сеть — сеть" (IPSec) или Azure ExpressRoute. Затем этот сценарий станет гибридной средой Azure и локальной средой.
Организация может хранить Управление API экземпляра в закрытом режиме, развертывая его в внутреннем режиме. Затем организация может использовать развертывание с Шлюз приложений Azure для включения общедоступного доступа для некоторых API, а другие остаются внутренними. Дополнительные сведения см. в разделе Интеграция Управления API и внутренней виртуальной сети со Шлюзом приложений.
Организация может решить разместить свои API-интерфейсы в локальной среде. Одной из причин этого изменения может быть то, что организация не могла переместить подчиненные зависимости базы данных, которые находятся в области этого проекта в облако. Если это так, организация по-прежнему может воспользоваться преимуществами Управление API локально с помощью локально размещенного шлюза.
Локальный шлюз — это контейнерное развертывание шлюза Управление API, который подключается к Azure в исходящем сокете. Первое необходимое условие заключается в том, что локальные шлюзы не могут быть развернуты без родительского ресурса в Azure, который несет дополнительную плату. Во-вторых, требуется уровень "Премиум" Управление API.
Подробности сценария
Компания электронной коммерции в индустрии путешествий модернизирует свой устаревший стек программного обеспечения на основе браузера. Хотя существующий стек в основном монолитный, некоторые службы HTTP на основе SOAP существуют из недавнего проекта. Компания рассматривает возможность создания дополнительных потоков доходов для монетизации некоторых внутренних интеллектуальной собственности, которые она разработала.
Цели проекта включают в себя устранение технического долга, улучшение текущего обслуживания и ускорение разработки функций с меньшим количеством ошибок регрессии. Во избежание риска проект будет использовать итеративный процесс, а некоторые шаги будут выполняться параллельно:
- Команда разработчиков модернизирует серверную часть приложения, которая состоит из реляционных баз данных, размещенных на виртуальных машинах.
- Внутренняя команда разработчиков создаст бизнес-функцию, которая будет предоставляться через новые API по протоколу HTTP.
- Команда по разработке контрактов создаст новый пользовательский интерфейс на основе браузера, который будет размещен в Azure.
Новые возможности приложения будут доставлены поэтапно. Эти функции постепенно заменят существующую функциональность пользовательского интерфейса клиента или сервера на основе браузера (размещенную локально), которая теперь управляет бизнесом электронной коммерции компании.
Члены команды управления не хотят модернизировать ненужно. Они также хотят сохранить контроль над областью и затратами. Для этого они решили сохранить существующие службы SOAP HTTP. Они также намерены свести к минимуму изменения в существующем пользовательском интерфейсе. Они могут использовать Azure Управление API для решения многих требований и ограничений проекта.
Потенциальные варианты использования
Этот сценарий выделяет модернизацию устаревших стеков программного обеспечения на основе браузера.
Этот сценарий можно использовать для:
- Узнайте, как ваш бизнес может воспользоваться экосистемой Azure.
- Планирование миграции служб в Azure.
- Узнайте, как переход к Azure влияет на существующие API.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые помогают улучшить качество рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Надежность
Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см . в контрольном списке проверки конструктора для обеспечения надежности.
- Рассмотрите возможность развертывания экземпляра Azure Управление API с включенными зонами доступности. Параметр развертывания Управление API в зонах доступности доступен только на уровне служб "Премиум".
- Зоны доступности можно использовать вместе с дополнительными экземплярами шлюза, развернутыми в разных регионах. Это повышает доступность службы, если один регион переходит в автономный режим. Развертывание с несколькими регионами также доступно только на уровне служб "Премиум".
- Рассмотрим интеграцию управления API Azure в Azure Application Insights, которая также отображает метрики через Azure Monitor. Например, метрика емкости может использоваться для определения общей нагрузки на ресурс Управление API и наличия дополнительных единиц масштабирования. Отслеживание емкости ресурсов и работоспособности повышает надежность.
- Убедитесь, что подчиненные зависимости, например серверные службы, на которых размещаются ИНТЕРФЕЙСы API, которые Управление API фасадов, также устойчивы.
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см . в контрольном списке проверки конструктора для оптимизации затрат.
Управление API предлагается на четырех уровнях: Разработчик, Базовый, Стандартный и Премиум. Подробные рекомендации по различиям в этих уровнях см. в руководстве по ценам azure Управление API.
Вы можете масштабировать Управление API, добавив и удалив единицы. Мощность единиц зависит от их уровня.
Примечание.
Уровень разработчика можно использовать для оценки функций Управление API. Не используйте его для рабочей среды.
Чтобы просмотреть прогнозируемые затраты и настроить требования к развертыванию, можно изменить количество единиц масштабирования и Служба приложений экземпляров в калькуляторе цен Azure.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Бен Гимблетт | Старший инженер клиента
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Документация по продукту:
Обучайте модули:
- Изучение службы приложение Azure
- Развертывание веб-сайта в Azure с помощью службы приложение Azure
- Защита API в Azure Управление API