Эта эталонная архитектура использует Azure Integration Services для оркестрации вызовов к корпоративным серверным системам. Серверные системы могут включать в себя системы saaS, службы Azure и существующие веб-службы в вашей организации.
Архитектура
Скачайте файл Visio для этой архитектуры.
Workflow
Серверные системы. Справа на схеме показаны различные внутренние системы, развернутые или используемые предприятием. Эти системы могут включать системы SaaS, другие службы Azure или веб-службы, предоставляющие конечные точки REST или SOAP.
Azure Logic Apps. В этой архитектуре приложения логики активируются HTTP-запросами. Вы также можете создавать вложенные рабочие процессы для более сложной оркестрации. Служба Logic Apps использует соединители для интеграции с часто используемыми службами. Logic Apps предлагает сотни соединителей. Также можно создавать собственные соединители.
Служба управления Azure API. Служба управления API состоит из двух взаимосвязанных компонентов:
Шлюз API. Шлюз API принимает вызовы по протоколу HTTP и маршрутизирует их к серверным службам.
Портал разработчика. Каждый экземпляр службы управления API Azure предоставляет доступ к порталу разработчика. Этот портал позволяет разработчикам ознакомиться с документацией и примерами кода для вызова API. На портале разработчика также можно тестировать API.
Azure DNS. Azure DNS обеспечивает разрешение имен с помощью инфраструктуры Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, интерфейсов API и инструментов и оплачивать использование, как и другие службы Azure. Чтобы использовать имя личного домена, например contoso.com, создайте записи DNS, которые позволяют сопоставить это доменное имя с IP-адресом. Дополнительные сведения см. в статье о настройке личного доменного имени в службе управления API.
Идентификатор Microsoft Entra. Используйте идентификатор Microsoft Entra для проверки подлинности клиентов, которые вызывают шлюз API. Идентификатор Microsoft Entra поддерживает протокол OpenID Подключение (OIDC). Клиенты получают маркер доступа из идентификатора Microsoft Entra ID, а шлюз API проверяет маркер для авторизации запроса. Если вы используете уровень "Стандартный" или "Премиум" Управление API, идентификатор Microsoft Entra также может помочь защитить доступ к порталу разработчика.
Компоненты
- Службы Integration Services — это коллекция служб, которые можно использовать для интеграции приложений, данных и процессов.
- Logic Apps — это бессерверная платформа для создания рабочих процессов на предприятии, которая объединяет приложения, данные и службы.
- Управление API — это управляемая служба для публикации каталогов API HTTP. Его можно использовать для повышения повторного использования и обнаружения API и развертывания шлюза API на прокси-запросах API.
- Azure DNS — это служба размещения для доменов DNS.
- Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом. Корпоративные сотрудники могут использовать идентификатор Microsoft Entra для доступа к внешним и внутренним ресурсам.
Подробности сценария
Службы Integration Services — это коллекция служб, которые можно использовать для интеграции приложений, данных и процессов для вашего предприятия. Описываемая архитектура использует две из этих служб — Logic Apps (для оркестрации рабочих процессов) и управление API (для создания каталогов API).
В этой архитектуре сложные API создаются путем импорта приложений логики в качестве API. Также можно импортировать существующие веб-службы путем импорта спецификаций OpenAPI (Swagger) или импорта API SOAP из спецификаций языка WSDL.
Шлюз API помогает отделить клиентские приложения от серверной части. Например, он может изменять URL-адреса или преобразовывать запросы перед их передачей в серверную часть. Шлюз также решает многие вопросы взаимодействия, например проверку подлинности, предоставление общего доступа к ресурсам из разных источников (CORS) и кэширование ответов.
Потенциальные варианты использования
Эта архитектура достаточно для базовых сценариев интеграции, в которых рабочий процесс активируется синхронными вызовами внутренних служб. Более сложная архитектура с использованием очередей и событий основывается на этой базовой архитектуре.
Рекомендации
Ваши конкретные требования могут отличаться от показанной здесь общей архитектуры. Используйте рекомендации из этого раздела в качестве отправной точки.
Управление API
Используйте следующие уровни управления API: "Базовый", "Стандартный", "Премиум". Эти ценовые категории предлагают соглашение об уровне обслуживания для рабочей среды и поддерживают горизонтальное увеличение масштаба в пределах региона Azure. Пропускная способность службы управления API измеряется в единицах. Каждая ценовая категория имеет максимальный масштаб. Уровень "Премиум" также поддерживает горизонтальное масштабирование в нескольких регионах Azure. Выберите уровень на основе набора функций и требуемой пропускной способности. Дополнительные сведения см. в разделах о ценах на службу управления API и о емкости экземпляра службы управления API Azure.
Каждый экземпляр Azure Управление API имеет доменное имя по умолчанию, которое является поддоменомazure-api.net, напримерcontoso.azure-api.net. Стоит рассмотреть использование личного домена для своей организации.
Logic Apps
Logic Apps лучше всего работает в сценариях, не требующих малой задержки для отклика, например при выполнении асинхронных вызовов API или вызовов API средней продолжительности. Если требуется малая задержка (например, при вызове, блокирующем пользовательский интерфейс), используйте другую технологию. Например, используйте службу "Функции Azure" или веб-API, развернутый в Службе приложений Azure. Используйте службу управления API, чтобы предоставить пользователям этот API в качестве интерфейсного.
Регион
Чтобы свести к минимуму задержки в сети, разместите службы управления API и Logic Apps в одном регионе. В общем случае следует выбирать регион, расположенный как можно ближе к пользователям (или к серверным службам).
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Надежность
Надежность гарантирует, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Дополнительные сведения см. в разделе "Обзор основы надежности".
См. соглашение об уровне обслуживания для каждой службы:
- Соглашение об уровне обслуживания для службы управления API.
- Соглашение об уровне обслуживания для Logic Apps.
Если вы развертываете Управление API в двух или более регионах с уровнем "Премиум", оно может быть более высоким соглашением об уровне обслуживания. См. цены на службу управления API.
Резервные копии
Регулярно выполняйте резервное копирование конфигурации службы управления API. Резервные копии необходимо хранить в расположении или регионе Azure, который отличается от региона, где развернута служба. В зависимости от целевого времени восстановления выберите стратегию аварийного восстановления:
При аварийном восстановлении подготовьте новый экземпляр службы управления API, восстановите в него резервную копию и перенаправьте записи DNS.
Поддерживайте пассивный экземпляр службы управления API в другом регионе Azure. Регулярно восстанавливайте резервные копии в этот экземпляр, чтобы поддерживать его синхронизацию с активной службой. Чтобы восстановить службу во время события аварийного восстановления, вам нужно только повторно указать записи DNS. Этот подход приводит к дополнительным затратам, так как вы оплачиваете пассивный экземпляр, но сокращает время восстановления.
В приложениях логики для резервного копирования и восстановления мы рекомендуем использовать подход "конфигурация в виде кода". Поскольку приложения логики являются бессерверными, их можно быстро воссоздать из шаблонов Azure Resource Manager. Сохраните шаблоны в системе управления версиями и интегрируйте их со своим процессом непрерывной интеграции и непрерывного развертывания (CI/CD). При необходимости аварийного восстановления разверните шаблон в новом регионе.
При развертывании приложения логики в другом регионе обновите конфигурацию службы управления API. Можно обновить свойство API Backend (Сервер) с помощью простого скрипта PowerShell.
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
Хотя этот список рекомендаций по безопасности не является полным, в нем можно найти некоторые соображения относительно безопасности, которые применимы именно к этой архитектуре:
Служба управления API Azure имеет постоянный общедоступный IP-адрес. Доступ к конечным точкам Logic Apps следует разрешить только с IP-адреса службы управления API. Дополнительные сведения см. в разделе "Ограничение входящих IP-адресов".
Чтобы убедиться, что пользователи имеют соответствующие уровни доступа, используйте управление доступом на основе ролей Azure (Azure RBAC).
Обеспечьте безопасность общедоступных конечных точек API в службе управления API с помощью OAuth или OpenID Connect. Чтобы защитить общедоступные конечные точки API, настройте поставщик удостоверений и добавьте политику проверки JSON Web Token (JWT). Дополнительные сведения см. в статье "Защита API с помощью OAuth 2.0 с идентификатором Microsoft Entra и Управление API".
Подключитесь ко внутренним службам из службы управления API с помощью взаимных сертификатов.
Активируйте принудительное использование протокола HTTPS для службы управления API.
Хранение секретов
Ни в коем случае не помещайте пароли, ключи доступа или строки подключения в систему управления версиями. Если они необходимы, используйте соответствующие методы для развертывания и защиты этих значений.
Если для приложения логики требуются какие-либо конфиденциальные значения, которые невозможно создать с помощью соединителя, сохраните эти значения в Azure Key Vault и получите к ним доступ из шаблона Resource Manager. Используйте параметры шаблона развертывания вместе с файлами параметров для каждой среды. Дополнительные сведения см. в разделе о параметрах безопасности и входных данных в рабочем процессе.
В службе управления API управление секретами осуществляется с помощью объектов, которые называются именованными значениями или свойствами. Они надежно сохраняют значения, к которым можно получить доступ с помощью политик управления API. Дополнительные сведения см. в статье Использование именованных значений в политиках управления API Azure.
Эффективность работы
Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".
DevOps
Создайте отдельные группы ресурсов для рабочей среды, сред разработки и тестирования. Так будет проще управлять развертываниями, удалять тестовые развертывания и назначать права доступа.
При назначении ресурсов группам ресурсов учитывайте следующие факторы.
Жизненный цикл. Обычно в группу ресурсов лучше объединять ресурсы с одинаковым жизненным циклом.
Доступ. Чтобы применить политики доступа к ресурсам в группе, можно использовать управление доступом на основе ролей Azure (Azure RBAC).
Выставление счетов. Вы сможете просматривать сведенные затраты для группы ресурсов.
Ценовая категория для службы управления API. Для сред разработки и тестирования используйте ценовую категорию для разработчиков. Чтобы свести к минимуму затраты во время предварительной подготовки, разверните реплику рабочей среды, запустите тесты, а затем завершите работу.
Развертывание
Используйте шаблоны Azure Resource Manager для развертывания ресурсов Azure, следуя инфраструктуре как процесс кода (IaC). Шаблоны упрощают автоматизацию развертываний с помощью Azure DevOps Services или других решений CI/CD.
Промежуточная
Рассмотрите возможность промежуточного развертывания рабочих нагрузок, что означает развертывание на различных этапах и выполнение проверок на каждом этапе перед переходом к следующему. Если вы используете этот подход, вы можете отправлять обновления в рабочие среды строго контролируемым способом и свести к минимуму непредвиденные проблемы с развертыванием. Blue-green deployment and Canary выпуски являются рекомендуемыми стратегиями развертывания для обновления рабочих сред в реальном времени. Кроме того, рекомендуется использовать хорошую стратегию отката при сбое развертывания. Например, вы можете автоматически повторно развернуть более раннее успешное развертывание из журнала развертывания. Параметр флага --rollback-on-error в Azure CLI является хорошим примером.
Изоляция рабочих нагрузок
Разместите службу управления API и любые отдельные приложения логики в собственных шаблонах Resource Manager. При использовании отдельных шаблонов можно сохранять ресурсы в системе управления версиями. Можно развернуть шаблоны вместе или по отдельности в процессе непрерывной интеграции и непрерывного развертывания.
Версии
Каждый раз, когда вы изменяете конфигурацию приложения логики или развертываете обновление с помощью шаблона Resource Manager, Azure сохраняет копию этой версии, а также все версии, у которых есть журнал выполнения. Эти версии можно использовать для отслеживания изменений или повысить уровень версии до текущей конфигурации приложения логики. Например, можно откатить приложение логики до предыдущей версии.
Служба управления API поддерживает две разные, но взаимодополняющие концепции присвоения версий:
Версии позволяют объектам-получателям выбрать версию API в зависимости от потребностей, например версию 1, 2, бета-версию или рабочую версию.
Редакции позволяют администраторам API вносить неразрывные изменения в API и развертывать эти изменения вместе с журналом изменений для информирования потребителей API об изменениях.
Редакцию можно создать в среде разработки и развернуть в других средах с помощью шаблонов Resource Manager. Дополнительные сведения см. в статье Публикация нескольких версий API.
Редакции также можно использовать для тестирования API, прежде чем изменения будут применены и станут доступными для пользователей. Однако этот метод не рекомендуется для нагрузочного или интеграционного тестирования. Вместо этого используйте отдельную тестовую или подготовительную среду.
Диагностика и мониторинг
Вы можете использовать Azure Monitor для оперативного мониторинга в службе управления API и Logic Apps. Azure Monitor предоставляет сведения на основе метрик, настроенных для каждой службы и включенных по умолчанию. Дополнительные сведения см. в разделе:
- Мониторинг опубликованных API-интерфейсов
- Мониторинг состояния, настройка ведения журнала диагностики и включение предупреждений для Azure Logic Apps
Каждая служба также содержит следующие параметры:
Журналы Logic Apps можно передавать в Azure Log Analytics для более глубокого анализа и отображения на панелях мониторинга.
Служба управления API поддерживает настройку Azure Application Insights для мониторинга DevOps.
Служба управления API поддерживает шаблон решения Power BI для пользовательской аналитики API. Вы можете использовать этот шаблон решения для создания собственного решения аналитики. Отчеты доступны в Power BI для бизнес-пользователей.
Уровень производительности
Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".
Чтобы увеличить масштабируемость службы "Управление API", добавьте политики кэширования там, где это необходимо. Кэширование также помогает уменьшить нагрузку на внутренние службы.
Уровни службы управления API "Базовый", "Стандартный" и "Премиум" позволяют горизонтально увеличить масштаб в рамках региона Azure для увеличения доступной емкости. Чтобы проанализировать использование службы, выберите "Метрика емкости" в меню "Метрики", а затем выполните масштабирование по мере необходимости. Процесс обновления или масштабирования может занять от 15 до 45 минут.
Рекомендации по масштабированию службы "Управление API":
Изучите шаблоны трафика при масштабировании. Клиентам с более изменчивыми шаблонами трафика требуется большая емкость.
Если использование емкости постоянно превышает 66 %, это может указывать на необходимость увеличения масштаба.
Если использование емкости постоянно не превышает 20 %, это может указывать на то, что масштаб можно уменьшить.
Всегда выполняйте тестирование нагрузки службы управления API с использованием репрезентативной нагрузки перед включением в рабочую среду.
Ценовая категория "Премиум" позволяет развернуть экземпляр службы управления API в нескольких регионах Azure. Это делает Управление API допустимым для более высокого уровня обслуживания и позволяет подготавливать службы рядом с пользователями в нескольких регионах.
Бессерверная модель Logic Apps означает, что администраторам не требуется планирование масштабируемости служб. Служба автоматически масштабируется в соответствии с потребностями.
Оптимизация затрат
В общих случаях для оценки затрат используйте калькулятор цен Azure. Ниже приведены некоторые другие соображения.
Управление API
Плата взимается за все Управление API экземпляры при их запуске. Если вы увеличили масштаб, но вам не нужен такой уровень производительности все время, можно уменьшить масштаб вручную или настроить автомасштабирование.
Logic Apps
Logic Apps использует бессерверную модель. Cчета выставляются на основе действий и выполнения соединителей. Дополнительные сведения см. на странице с ценами на Logic Apps.
См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.
Следующие шаги
Связанные ресурсы
Чтобы повысить надежность и масштабируемость, используйте очереди сообщений и событий для разделения серверных систем. Эта архитектура показана в следующей статье в этой серии:
Вы также можете ознакомиться с этими статьями из Центра архитектуры Azure: