Изменить

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

Cлужба управления Azure API
Azure Monitor
Служба приложений Azure

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

Архитектура

Диаграмма архитектуры

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

Рабочий процесс

  1. Существующее локальное веб-приложение продолжает напрямую использовать существующие локальные веб-службы.
  2. Вызовы существующего веб-приложения к существующим службам HTTP остаются неизменными. Для корпоративной сети эти вызовы являются внутренними.
  3. Исходящие вызовы выполняются из Azure в существующие внутренние службы:
  4. Новый API:
    • Отображается только через экземпляр Управление API, который предоставляет фасад API. Новый API не обращается напрямую.
    • Разрабатывается и публикуется в качестве веб-API Azure PaaS.
    • Настроено (с помощью параметров для функции веб-приложения службы приложение Azure) принимать только виртуальный IP-адрес Управление API.
    • Размещается в веб-приложения с включенным безопасным транспортом (HTTPS или SSL).
    • Включена авторизация, предоставляемая службой приложение Azure с помощью идентификатора Microsoft Entra и OAuth 2.
  5. Новое веб-приложение на основе браузера зависит от экземпляра Azure Управление API для существующего HTTP-API и нового API.

Экземпляр Управление API настроен для сопоставления устаревших служб HTTP с новым контрактом API. В этой конфигурации новый веб-интерфейс не знает об интеграции с набором устаревших служб или API и новых API.

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

Компоненты

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

  • Если организация планирует полностью переместить свою инфраструктуру в Azure, включая виртуальные машины, в которых размещаются устаревшие приложения, Управление API по-прежнему является отличным вариантом, так как он может выступать в качестве фасада для любой адресной конечной точки HTTP.

  • Если организация решила сохранить существующие конечные точки закрытыми и не предоставлять их публично, Управление API экземпляр организации может быть связан с виртуальной сетью Azure:

  • Организация может хранить Управление API экземпляра в закрытом режиме, развертывая его в внутреннем режиме. Затем организация может использовать развертывание с Шлюз приложений Azure для включения общедоступного доступа для некоторых API, а другие остаются внутренними. Дополнительные сведения см. в разделе Интеграция Управления API и внутренней виртуальной сети со Шлюзом приложений.

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

    Локальный шлюз — это контейнерное развертывание шлюза Управление API, который подключается к Azure в исходящем сокете. Первое необходимое условие заключается в том, что локальные шлюзы не могут быть развернуты без родительского ресурса в Azure, который несет дополнительную плату. Во-вторых, требуется уровень "Премиум" Управление API.

Примечание.

Общие сведения о подключении Управление API к виртуальной сети см. в этой статье.

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

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

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

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

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

Члены команды управления не хотят модернизировать ненужно. Они также хотят сохранить контроль над областью и затратами. Для этого они решили сохранить существующие службы SOAP HTTP. Они также намерены свести к минимуму изменения в существующем пользовательском интерфейсе. Они могут использовать Azure Управление API для решения многих требований и ограничений проекта.

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

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

Этот сценарий можно использовать для:

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

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

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

Доступность и масштабируемость

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

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

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

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

Примечание.

Уровень разработчика можно использовать для оценки функций Управление API. Не используйте его для рабочей среды.

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

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

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

Кроме того, в существующем Azure Resource Manager вы можете выбрать шаблон быстрого запуска, который будет соответствовать вашему конкретному варианту использования.

Соавторы

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

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

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

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

Документация по продукту:

Обучайте модули: