Поделиться через

Использование Azure Управление API в мультитенантном решении

  • Статья

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

Примечание.

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

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

Модели изоляции

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

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

Фактор Общий экземпляр с серверной частью одного клиента Общий экземпляр с общим мультитенантным серверным сервером Экземпляр для каждого клиента
Количество поддерживаемых клиентов Много Почти несвязанный По одному для каждого экземпляра
Себестоимость Lower Lower Выше
Сложность развертывания Низкий: один экземпляр для управления для каждой метки Низкий: один экземпляр для управления для каждой метки Высокий уровень: управление несколькими экземплярами
Сложность конфигурации маршрутизации Выше Lower Lower
Чувствительность к шумным-соседным проблемам Да Да Нет
Сетевая изоляция на уровне клиента No No Да
Пример сценария Пользовательские доменные имена для каждого клиента Крупное мультитенантное решение с общим уровнем приложений Метки развертывания для конкретного клиента

Модели изоляции общего экземпляра

Обычно используется общий доступ к экземпляру Управление API между несколькими клиентами, что помогает снизить затраты и сложность развертывания и управления. Сведения о том, как предоставить общий доступ к экземпляру Управление API, зависят от назначения клиентов приложениям API серверной части.

Однотенантное серверное приложение

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

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

Общее мультитенантное серверное приложение

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

Экземпляр для каждого клиента

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

Совет

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

При развертывании экземпляра Управление API необходимо учитывать ограничения службы, включая все ограничения, которые могут применяться к количеству экземпляров Управление API в подписке Или регионе Azure.

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

функции Управление API, поддерживающие мультитенантность

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

Определение клиентов в входящих запросах

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

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

Кроме того, можно определить клиента с помощью других методов. Ниже приведены некоторые примеры подходов, которые выполняются в пользовательской политике, которую вы определяете:

  • Используйте пользовательский компонент URL-адреса, например поддомен, путь или строку запроса. Например, в URL-адресе https://api.contoso.com/tenant1/productsможно извлечь первую часть пути tenant1и рассматривать его как идентификатор клиента. Аналогичным образом, учитывая входящий URL-адресhttps://tenant1.contoso.com/products, можно извлечь поддомен. tenant1 Чтобы использовать этот подход, попробуйте проанализировать путь или строку запроса из Context.Request.Url свойства.

  • Используйте заголовок запроса. Например, клиентские приложения могут добавлять в запросы пользовательский TenantID заголовок. Чтобы использовать этот подход, рассмотрите возможность чтения из Context.Request.Headers коллекции.

  • Извлечение утверждений из веб-токена JSON (JWT). Например, у вас может быть настраиваемое tenantId утверждение в JWT, выданном поставщиком удостоверений. Чтобы использовать этот подход, используйте политику validate-jwt и задайте output-token-variable-name свойство, чтобы определение политики могли считывать значения из маркера.

  • Динамические поиск идентификаторов клиента. Во время обработки запроса можно взаимодействовать с внешней базой данных или службой. С помощью этого подхода можно создать пользовательскую логику сопоставления клиентов для сопоставления идентификатора логического клиента с определенным URL-адресом или получить дополнительные сведения о клиенте. Чтобы использовать этот подход, используйте политику отправки запросов .

    Этот подход, скорее всего, увеличит задержку запросов. Чтобы устранить этот эффект, рекомендуется использовать кэширование для уменьшения количества вызовов внешнего API. Для реализации подхода кэширования можно использовать политики кэша-store-value и cache-lookup-value . Не забудьте сделать кэш недействительным при каждом добавлении, удалении или перемещении клиента, влияющего на внутренний поиск.

Именованные значения

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

Предупреждение

В мультитенантном решении важно быть осторожным при установке именованных значений. Если параметры зависят от клиентов, обязательно включите идентификатор клиента в имя. Например, можно использовать шаблон, например tenantId-key:value после подтверждения, что tenantId подходит для запроса.

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

Проверка подлинности входящих запросов

Запросы API, сделанные в шлюзе Управление API, обычно должны проходить проверку подлинности. Управление API предоставляет несколько методов проверки подлинности входящих запросов к шлюзу, включая OAuth 2.0 и сертификаты клиента. Рассмотрим типы учетных данных, которые следует поддерживать, и где они должны быть проверены. Например, рассмотрим, должна ли проверка выполняться в Управление API, в внутренних приложениях или в обоих местах.

Дополнительные сведения см. в статье "Проверка подлинности и авторизация в API" в Azure Управление API.

Примечание.

Если вы используете ключ подписки или ключ API, рекомендуется также использовать другой метод проверки подлинности.

Ключ подписки не является сильной формой проверки подлинности, но это полезно для других сценариев, таких как отслеживание использования API отдельного клиента.

Маршрутизация на внутренние части для конкретного клиента

При использовании Управление API в качестве общего компонента может потребоваться перенаправить входящие запросы API на разные серверные серверы для конкретного клиента. Эти серверные части могут находиться в разных метках развертывания или могут быть разными приложениями в пределах одной метки. Чтобы настроить маршрутизацию в определении политики, используйте политику set-backend-service . Необходимо указать новый базовый URL-адрес, на который должен быть перенаправлен запрос.

Ответы кэша или другие данные

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

Используйте политики кэша-store-value и cache-lookup-value для реализации подхода кэширования.

Предупреждение

В мультитенантном решении важно быть осторожным при настройке ключей кэша. Если кэшированные данные могут отличаться между клиентами, убедитесь, что идентификатор клиента включен в ключ кэша.

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

Личные домены

Используйте Управление API для настройки собственных пользовательских доменов для шлюза API и портала разработчика. В некоторых уровнях можно настроить домены подстановочных знаков или несколько полных доменных имен (FQDN).

Вы также можете использовать Управление API вместе со службой, такой как Azure Front Door. В этой конфигурации Azure Front Door часто обрабатывает пользовательские домены и сертификаты TLS и взаимодействует с Управление API с помощью одного доменного имени. Если исходный URL-адрес клиента содержит сведения о клиенте, которые необходимо отправить в экземпляр Управление API для последующей обработки, попробуйте использовать X-Forwarded-Host заголовок запроса или использовать правила Azure Front Door для передачи информации в качестве заголовка HTTP.

Ограничения скорости

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

Используйте Управление API для применения ограничений скорости для конкретного клиента. Если вы используете подписки для конкретного клиента, рекомендуется использовать политику квоты для применения квоты для каждой подписки. Кроме того, рекомендуется использовать политику квот по ключу для принудительного применения квот с помощью любого другого ключа ограничения скорости, например идентификатор клиента, полученный из URL-адреса запроса или JWT.

Монетизация

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

Управление емкостью

Экземпляр Управление API поддерживает определенный объем емкости, который представляет ресурсы, доступные для обработки запросов. При использовании сложных политик или развертывании дополнительных API в экземпляре используется больше емкости. Емкость экземпляра можно управлять несколькими способами, например приобретением дополнительных единиц. Вы также можете динамически масштабировать емкость экземпляра.

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

Дополнительные сведения о масштабировании Управление API см. в статье Об обновлении и масштабировании экземпляра Azure Управление API.

Развертывания в нескольких регионах

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

Однако если вам нужны полностью изолированные экземпляры Управление API, можно также развернуть независимые Управление API ресурсы в разных регионах. Этот подход разделяет плоскость управления для каждого экземпляра Управление API.

Соавторы

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

Основные авторы:

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

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

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

Ознакомьтесь с архитектурными подходами к интеграции в мультитенантных решениях.