Эта эталонная архитектура использует Azure Integration Services для оркестрации вызовов к корпоративным серверным системам. Серверные системы могут включать в себя системы saaS, службы Azure и существующие веб-службы в вашей организации.
Архитектура
Скачайте файл Visio для этой архитектуры.
Рабочий процесс
приложения. Приложение — это клиент, который вызывает шлюз API после проверки подлинности с помощью Microsoft Entra. Приложение может быть веб-приложением, мобильным приложением или любым другим клиентом, который может выполнять HTTP-запросы.
Идентификатор Microsoft Entra. Используется для проверки подлинности клиентского приложения. Клиентское приложение получает маркер доступа из идентификатора Microsoft Entra и включает его в запрос к шлюзу API.
Служба управления Azure API. Служба управления API состоит из двух взаимосвязанных компонентов:
Шлюз API. Шлюз API принимает HTTP-вызов из клиентского приложения, проверяет маркер из идентификатора Microsoft Entra и перенаправляет запрос в серверную службу. Шлюз API также может преобразовывать запросы и ответы, а также кэшировать ответы.
Портал разработчика. портал разработчика используется разработчиками для обнаружения и взаимодействия с API. Портал разработчика можно настроить для соответствия фирменной символики вашей организации.
Azure Logic Apps. Приложения логики используются для оркестрации вызовов внутренних служб. Приложения логики могут быть активированы различными событиями и могут вызывать различные службы. В этом решении Logic Apps используется для вызова внутренних служб и обеспечения простого подключения через соединители снижения необходимости пользовательского кода.
серверные службы. Серверные службы могут быть любой службой или бизнес-приложением, например базой данных, веб-службой или приложением SaaS. Серверные службы можно размещать в Azure или локально.
Компоненты
-
Службы Integration Services — это коллекция служб, которые можно использовать для интеграции приложений, данных и процессов. В этом решении используются две из этих служб: Logic Apps и управление API. Logic Apps используется для упрощения интеграции на основе сообщений между системами и упрощения подключения к соединителям. Управление API используется для предоставления фасада для внутренних служб, что позволяет клиентам взаимодействовать с согласованным интерфейсом.
- Logic Apps — это бессерверная платформа для создания рабочих процессов на предприятии, которая объединяет приложения, данные и службы. В этом решении Logic Apps используется для оркестрации вызовов внутренних служб и обеспечения простого подключения через соединители, снижая потребность в пользовательском коде.
- Управление API — это управляемая служба для публикации каталогов API HTTP. Его можно использовать для повышения повторного использования и обнаружения API и развертывания шлюза API на прокси-запросах API. В этом решении управление API предоставляет дополнительные возможности, такие как ограничение скорости, проверка подлинности и кэширование внутренних служб. Кроме того, управление API предоставляет портал разработчика для клиентов для обнаружения и взаимодействия с API.
- Azure DNS — это служба размещения для доменов DNS. Azure DNS размещает общедоступные записи DNS для службы управления API. Это позволяет клиентам разрешать DNS-имя в IP-адрес службы управления API.
- Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом. Корпоративные сотрудники могут использовать идентификатор Microsoft Entra для доступа к внешним и внутренним ресурсам. Здесь идентификатор Entra используется для защиты службы управления API с помощью OAuth 2.0 и портала разработчика с помощью Entra B2C.
Подробности сценария
Службы Integration Services — это коллекция служб, которые можно использовать для интеграции приложений, данных и процессов для вашего предприятия. Описываемая архитектура использует две из этих служб — Logic Apps (для оркестрации рабочих процессов) и управление API (для создания каталогов API).
В этой архитектуре сложные API создаются путем импорта приложений логики в качестве API. Также можно импортировать существующие веб-службы путем импорта спецификаций OpenAPI (Swagger) или импорта API SOAP из спецификаций языка WSDL.
Шлюз API помогает отделить клиентские приложения от серверной части. Например, он может изменять URL-адреса или преобразовывать запросы перед их передачей в серверную часть. Шлюз также решает многие вопросы взаимодействия, например проверку подлинности, предоставление общего доступа к ресурсам из разных источников (CORS) и кэширование ответов.
Потенциальные варианты использования
Эта архитектура достаточно для базовых сценариев интеграции, в которых рабочий процесс активируется синхронными вызовами внутренних служб. Более сложная архитектура с использованием очередей и событий основывается на этой базовой архитектуре.
Рекомендации
Ваши конкретные требования могут отличаться от показанной здесь общей архитектуры. Используйте рекомендации из этого раздела в качестве отправной точки.
Управление API
Используйте следующие уровни управления API: "Базовый", "Стандартный", "Премиум". Эти уровни предлагают соглашение об уровне обслуживания рабочей среды (SLA) и поддерживает горизонтальное масштабирование в пределах региона Azure. Пропускная способность службы управления API измеряется в единицах. Каждая ценовая категория имеет максимальный масштаб. Уровень "Премиум" также поддерживает горизонтальное масштабирование в нескольких регионах Azure. Выберите уровень на основе набора функций и требуемой пропускной способности. Дополнительные сведения см. в разделах о ценах на службу управления API и о емкости экземпляра службы управления API Azure.
Для этого решения не рекомендуется использовать уровень потребления управления API, так как он не поддерживает портал разработчика, который требуется для этой архитектуры. Уровень разработчика предназначен специально для непроизводственных сред и не рекомендуется для рабочих нагрузок. Матрица признаков, включающая различия между уровнями, можно найти здесь.
Каждый экземпляр 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 в двух или более регионах с уровнем "Премиум", оно может быть более высоким соглашением об уровне обслуживания. См. цены на службу управления 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 Logic Apps подробные инструкции.
В службе управления API управление секретами осуществляется с помощью объектов, которые называются именованными значениями или свойствами. Они надежно сохраняют значения, к которым можно получить доступ с помощью политик управления API. Дополнительные сведения см. в статье Использование именованных значений в политиках управления API Azure.
Оптимизация затрат
Оптимизация затрат заключается в том, чтобы подумать о способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке конструктора дляоптимизации затрат.
В общих случаях для оценки затрат используйте калькулятор цен Azure. Ниже приведены некоторые другие соображения.
Управление API
Плата взимается за все Управление API экземпляры при их запуске. Если вы увеличили масштаб, но вам не нужен такой уровень производительности все время, можно уменьшить масштаб вручную или настроить автомасштабирование.
Logic Apps
Logic Apps использует бессерверную модель. Cчета выставляются на основе действий и выполнения соединителей. Дополнительные сведения см. на странице с ценами на Logic Apps.
См. сведения о затратах на платформу Microsoft 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: