Политика SpikeArrest

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Политика защиты от всплесков трафика (Spike Arrest) защищает от резких скачков трафика с помощью элемента <Rate> . Этот элемент ограничивает количество запросов, обрабатываемых API-прокси и отправляемых на бэкэнд, предотвращая задержки в работе и простои.

<SpikeArrest> элемент

Определяет политику ареста с применением шипов.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <DisplayName>display_name</DisplayName>
  <Properties/>
  <Identifier ref="flow_variable"/>
  <MessageWeight ref="flow_variable"/>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
  <DisplayName>Spike Arrest-1</DisplayName>
  <Properties/>
  <Identifier ref="request.header.some-header-name"/>
  <MessageWeight ref="request.header.weight"/>
  <Rate>30ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Этот элемент имеет следующие атрибуты, общие для всех политик:

Примеры

Следующие примеры демонстрируют некоторые способы применения политики «Задержание за нарушение правил дорожного движения»:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate ref="request.header.runtime_rate" />
</SpikeArrest>

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

ссылка на дочерний элемент

В этом разделе описываются дочерние элементы <SpikeArrest> .

<DisplayName>

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

Элемент <DisplayName> является общим для всех политик.

Элемент <DisplayName> использует следующий синтаксис:

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

Элемент <DisplayName> не имеет атрибутов или дочерних элементов.

<Identifier>

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

Используйте в сочетании с элементом <MessageWeight> для более точного контроля над ограничением количества запросов.

Если оставить элемент <Identifier> пустым, для всех запросов к этому API-прокси будет применяться одно ограничение скорости.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Identifier ref="flow_variable"/>
</SpikeArrest>
        

<SpikeArrest name="Spike-Arrest-1">
  <Identifier ref="developer.id"/>
  <Rate>42pm</Rate/>
</SpikeArrest>

В следующей таблице описаны атрибуты <Identifier> >:

Этот элемент также обсуждается в следующем сообщении сообщества Apigee: Идентификатор квоты в рамках различных политик .

<MessageWeight>

Задает вес, определенный для каждого сообщения. Вес сообщения изменяет влияние отдельного запроса на расчет коэффициента предотвращения всплесков активности. Вес сообщения может быть любой переменной потока, такой как заголовок HTTP, параметр запроса, параметр формы или содержимое тела сообщения. Вы также можете использовать пользовательские переменные с помощью политики JavaScript или политики AssignMessage .

Используйте совместно с <Identifier> для дальнейшего ограничения количества запросов от конкретных клиентов или приложений.

Например, если пороговое значение Spike Arrest <Rate> равно 10pm , и приложение отправляет запросы с весом 2 , то от этого клиента разрешено отправлять только пять сообщений в минуту, поскольку каждый запрос засчитывается как 2.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <MessageWeight ref="flow_variable"/>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

В следующей таблице описаны атрибуты <MessageWeight> :

<Rate>

Этот элемент задает частоту ограничения пиковых нагрузок (или всплесков) трафика, устанавливая количество разрешенных запросов в минуту или в секунду. Вы также можете использовать этот элемент совместно с <Identifier> и <MessageWeight> для плавного регулирования трафика во время выполнения, принимая значения от клиента.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

В следующей таблице описаны атрибуты <Rate> :

<Rate ref="request.header.custom_rate">1pm</Rate>

<UseEffectiveCount>

Распределяет количество остановок всплесков активности между обработчиками сообщений (MP) при использовании групп автоматического масштабирования.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest name='Spike-Arrest-1'>
  <Rate>40ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Элемент <UseEffectiveCount> является необязательным. Если этот элемент отсутствует в вашей политике предотвращения резкого увеличения количества нарушений, значение по умолчанию будет false

В следующей таблице описаны атрибуты элемента <UseEffectiveCount> :

Эффект параметра <UseEffectiveCount> зависит от его значения:

• true : Предел частоты скачков активности MP равен <Rate> , деленному на текущее количество MP в одном и том же модуле. Совокупный лимит равен значению <Rate> . При динамическом добавлении (или удалении) MP их индивидуальные пределы частоты скачков активности будут увеличиваться (или уменьшаться), но совокупный лимит останется неизменным.
• false : Предел частоты скачков для каждого MP — это просто значение его <Rate> . Совокупный лимит — это сумма скоростей всех MP. При добавлении (или удалении) MP их индивидуальные пределы частоты скачков остаются неизменными, но совокупный лимит увеличивается (или уменьшается).

Политика SpikeArrest использует алгоритм « токенового ведра », который сглаживает всплески трафика, разделяя указанный вами лимит скорости на более мелкие интервалы. Недостатком этого подхода является то, что множество легитимных запросов, поступающих в течение короткого промежутка времени, могут быть отклонены.

Например, предположим, вы задали частоту 30 запросов в минуту (30 запросов в минуту). В ходе тестирования вы можете подумать, что сможете отправить 30 запросов за 1 секунду, если они поступят в течение минуты. Но политика не обеспечивает соблюдение этого параметра. Если подумать, 30 запросов за 1 секунду в некоторых средах могут считаться небольшим всплеском.

• Поминутные тарифы сглаживаются, и все запросы разрешаются с интервалом в несколько секунд .
  

  Например, время 30 вечера сглаживается следующим образом:
  60 секунд (1 минута) / 30 вечера = 2-секундные интервалы, или 1 запрос разрешен каждые 2 секунды. Второй запрос в течение 2 секунд будет отклонен. Также 31-й запрос в течение минуты будет отклонен.

• Посекундные запросы сглаживаются и преобразуются в полные запросы, разрешенные с интервалами в миллисекунды .

  Например, значение 10 пс сглаживается следующим образом:
  1000 миллисекунд (1 секунда) / 10 пс = 100-миллисекундные интервалы, или 1 запрос разрешен каждые 100 миллисекунд. Второй запрос в течение 100 мс завершится неудачей. Также 11-й запрос в течение секунды завершится неудачей.

В следующей таблице показано влияние параметра <UseEffectiveCount> на эффективный лимит скорости каждого MP:

В этом примере обратите внимание, что когда количество MP уменьшается с 4 до 2, и <UseEffectiveCount> равно false , эффективная ставка на MP остается неизменной (10). Но когда <UseEffectiveCount> равно true , эффективная ставка на MP увеличивается с 10 до 20 при уменьшении количества MP с 4 до 2.

Переменные потока

При выполнении политики Spike Arrest заполняется следующая переменная потока:

Для получения более подробной информации см. справочник по переменным потока .

Ссылка на ошибку

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

Ошибки выполнения

Эти ошибки могут возникать при выполнении политики.

Ошибки развертывания

Эти ошибки могут возникнуть при развертывании прокси-сервера, содержащего эту политику.

Переменные неисправности

Эти переменные устанавливаются при возникновении ошибки во время выполнения. Дополнительные сведения см. в разделе Что нужно знать об ошибках политики .

Пример ответа об ошибке

Ниже показан пример ответа об ошибке:

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.SpikeArrestViolation"
      },
      "faultstring":"Spike arrest violation. Allowed rate : 10ps"
   }
}

Пример правила неисправности

Ниже показан пример правила для обработки ошибки SpikeArrestViolation :

<FaultRules>
    <FaultRule name="Spike Arrest Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
        </Step>
        <Condition>ratelimit.Spike-Arrest-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

Текущий код состояния HTTP, указывающий на превышение лимита запросов, установленного политикой квотирования или предотвращения всплесков активности, — 429 (Слишком много запросов). Чтобы изменить код состояния HTTP на 500 (Внутренняя ошибка сервера), установите свойство features.isHTTPStatusTooManyRequestEnabled в значение false , используя API обновления свойств организации .

Например:

curl -u email:password -X POST -H "Content-type:application/xml" http://api.enterprise.apigee.com/v1/organizations/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
        . . .
    </Properties>
</Organization>"

Схемы

Каждый тип политики определяется XML-схемой ( .xsd ). Для справки, схемы политик доступны на GitHub.

Связанные темы

• Политика квот : Политика квот, ограничивающая трафик на отдельных клиентах.
• Ограничение скорости для обзора ограничений скорости
• Сравнение политики квотирования и политики предотвращения резкого увеличения количества сообщений о нарушениях.
• Рабочие примеры API-прокси