Расширенное регулирование запросов с помощью API Management

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API

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

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

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

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

Ограничения частоты обычно используются для предотвращения коротких и интенсивных всплесков объема запросов. Например, если известно, что узким местом серверной службы является ее база данных с большим объемом вызовов, можно настроить политику rate-limit-by-key, чтобы запретить большое количество запросов.

Внимание

Из-за распределенного строения архитектуры регулирования ограничение частоты никогда не является полностью точным. Разница между настроенным и фактическим количеством допустимых запросов зависит от их объема и частоты, задержки на стороне сервера и других факторов.

Планы продаж

Квоты обычно используются для управления частотой вызовов в течение более длительного периода. Например, можно задать общее число вызовов, которые конкретный подписчик может выполнить в течение данного месяца. С целью монетизации API можно также установить разные квоты для подписок с учетом уровней. Например, для подписки уровня "Базовый" может действовать квота в 10 000 вызовов в месяц, а для уровня "Премиум" — 100 000 000 вызовов в месяц.

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

Примечание.

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

Регулирование на основе продукта

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

Регулирование количества запросов на основе настраиваемых ключей

Примечание.

Политики rate-limit-by-key и quota-by-key недоступны, если используется уровень "Потребление" службы Azure "Управление API". Политика quota-by-key в настоящее время недоступна на уровнях версии 2.

Политики rate-limit-by-key и quota-by-key позволяют более гибко управлять трафиком. С их помощью можно определять выражения для идентификации ключей, которые используются для контроля за объемом трафика. Принцип работы этих политик лучше всего демонстрирует пример.

Регулирование количества запросов по IP-адресам

Описанные ниже политики накладывают на каждый IP-адрес клиента следующие ограничения: не более 10 запросов в минуту и не более 1 000 000 вызовов и 10 000 килобайт пропускной способности в месяц.

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

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

Регулирование запросов по удостоверениям пользователя

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

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

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

Объединенные политики

Несмотря на то что политики регулирования на основе пользователей дают больше контроля, чем политики на основе подписок, их можно выгодно объединять. Регулирование с использованием ключа подписки продукта (см. разделы Limit call rate by subscription (Ограничение частоты вызовов по подписке) и Set usage quota by subscription (Задание квоты использования по подписке)) — это отличный способ получения прибыли от API, основанный на уровнях использования. Кроме того, появляется возможность более точно регулировать запросы по пользователям, не позволяя одному пользователю мешать другим.

Регулирование со стороны клиента

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

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

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

Итоги

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

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

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