19.03.01 — Примечания к выпуску Apigee Edge для публичного облака

Балансировка нагрузки — больше контроля над удалением вышедших из строя серверов

При настройке балансировщика нагрузки для прокси-сервера API вы можете определить, сколько ошибок ответа произойдет, прежде чем сервер будет исключен из ротации балансировки нагрузки. Ошибка ответа означает, что Apigee не получает ответа от целевого сервера. Когда это происходит, счетчик ошибок увеличивается на единицу. Когда Apigee получает ответ от целевого сервера, даже если ответ представляет собой ошибку HTTP (например, 500), это считается ответом от целевого сервера, и счетчик ошибок сбрасывается. Чтобы гарантировать, что плохие HTTP-ответы (например, 500) также увеличивают счетчик ошибок и как можно скорее выводят неработоспособный сервер из ротации балансировки нагрузки, вы можете добавить в нагрузку новый элемент <ServerUnhealthyResponse> с дочерними элементами <ResponseCode> конфигурация балансира. Edge также будет считать ответы с этими кодами неудачными.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

Улучшения политики AccessControl

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

<IgnoreTrueClientIPHeader> : необязательно (по умолчанию — false). Если для этого параметра установлено значение true, политика игнорирует заголовок True-Client-IP и оценивает IP-адреса в заголовке X-Forwarded-For , следуя настроенному вами поведению оценки X-Forwarded-For .

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Подробную информацию можно найти в этой публикации сообщества .

В политике RaiseFault доступны два новых элемента, которые делают обработку FaultRules более чистой и эффективной.

• ShortFaultReason — это логическое значение, которое, если ему присвоено значение true, помещает имя политики в переменную error.reason.
• AssignVariable , доступный в FaultResponse, позволяет назначить ответ на ошибку переменной, которая будет использоваться другими политиками в потоке прокси-сервера API.

Ограничения теперь применяются для размещенных целей. Подробную информацию о лимитах см. в разделе « Лимиты ».

Теперь вы можете использовать переменные шаблона сообщения для установки IP-адресов и масок CIDR в политике AccessControl . Например, если вы хотите сохранить IP-адрес и маску в карте значений ключей (KVM), вы можете получить эти значения из переменной, которую вы установили в потоке прокси-сервера API. Это позволяет вам легче изменять значения IP во время выполнения без необходимости изменения конфигурации политики.

Например, вместо:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

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

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

Мониторинг API предоставляет две роли: администратор мониторинга API и пользователь мониторинга API, описанные в разделе Мониторинг API доступа . Они были доступны в декабре 2018 года.

Edge теперь добавляет заголовок X-Apigee.Message-Timeout к каждому запросу. Этот заголовок предназначен для внутреннего использования Edge. Не полагайтесь на значения в заголовках X-Apigee.* в ваших прокси-серверах API, поскольку эти заголовки не предназначены для использования клиентами и могут быть удалены или изменены Apigee в любое время.

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

x-apigee.edge.execution.sense.action всегда имеет значение null

В политике ResponseCache NIOTheread выполняется без отклонения из пула потоков.

Несколько экспортеров журналов на маршрутизаторах Apigee вызывают высокую загрузку ЦП.

Периодические ошибки 404 в определенных организациях

Развернутый общий поток не выполняется на некоторых процессорах сообщений

Это исправление будет включено в следующий выпуск Edge для частного облака.

Это исправление будет включено в следующий выпуск Edge для частного облака.

Это исправление будет включено в следующий выпуск Edge для частного облака.