APIM объединяет подход политики регулирования - PullRequest
Новая
       25

APIM объединяет подход политики регулирования

0 голосов
/ 09 декабря 2018

В APIM в настоящее время мы имеем регулирование уровня ключа подписки продукта.Но очевидно, что если у нас есть несколько API в одном продукте, один API может использовать больше квоты, чем ожидалось, и помешать другим использовать приложение.Так что в соответствии с документацией MS (https://docs.microsoft.com/en-us/azure/api-management/api-management-sample-flexible-throttling) мы можем использовать комбинированные политики.

Вопрос в том подходе, можем ли мы использовать, как показано ниже, 

API-1 300 calls per 60 seconds where product subscription key =123
API-2 200 calls per 60 seconds where product subscription key =123
API-3 200 calls per 60 seconds where product subscription key =123

Если так, чтоможет быть общим числом вызовов для ключа подписки продукта - если это имеет смысл.

Я использовал следующий подход, чтобы использовать объединенные политики. Но это не нравится. 

<rate-limit-by-key calls="50" renewal-period="60" counter-key="@(&quot;somevalue&quot; + context.Request.Headers.GetValueOrDefault(&quot;Ocp-Apim-Subscription-Key&quot;))" />
<rate-limit calls="10" renewal-period="30">  
    <api name="AddressSearch API dev" calls="5" renewal-period="30" />  
        <operation name="Search_GetAddressSuggestions" calls="3" renewal-period="30" />
</rate-limit>

Ответы [ 3 ]

0 голосов
/ 11 декабря 2018

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

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

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

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

<rate-limit calls="0" renewal-period="0">  
    <api name="API-1" calls="100" renewal-period="60" />  
    <api name="API-2" calls="200" renewal-period="60" />  
    <api name="API-3" calls="300" renewal-period="60" />  
</rate-limit>
0 голосов
/ 19 декабря 2018

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

<choose>
<when condition="@(context.Operation.Id.Equals("End point name1"))">
<rate-limit-by-key calls="40" renewal-period="30" counter-key="@(context.Api.Name + context.Operation.Name + context.Request.Headers.GetValueOrDefault("Ocp-Apim-Subscription-Key"))" />
</when>
<when condition="@(context.Operation.Id.Equals("End point name2"))">
<rate-limit-by-key calls="20" renewal-period="30" counter-key="@(context.Api.Name + context.Operation.Name + context.Request.Headers.GetValueOrDefault("Ocp-Apim-Subscription-Key"))" />
</when>
<otherwise>
<rate-limit-by-key calls="15" renewal-period="30" counter-key="@(context.Api.Name + context.Operation.Name + context.Request.Headers.GetValueOrDefault("Ocp-Apim-Subscription-Key"))" />
</otherwise>
</choose>

Надеюсь, это поможет.

0 голосов
/ 10 декабря 2018

Просто для подтверждения - вы устанавливаете три политики регулирования на уровне API на основе ключа подписки:

API-1: 300 calls per 60 seconds API-2: 200 calls per 60 seconds API-3: 200 calls per 60 seconds

В этом случае, если это ваши единственные API,максимальное количество запросов на ключ подписки в течение 60 секунд составляет: 300 + 200 + 200 = 700.

Если у вас есть больше API, они не будут регулироваться, если вы не укажете политику для них.

...