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 помещает имя политики в переменную fault.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 Monitoring предоставляет две роли: администратор API Monitoring и пользователь API Monitoring, описанные в разделе Access API Monitoring . Они стали доступны в декабре 2018 года.

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

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

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

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

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

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

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

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

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

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