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. Подробнее о доступе к API Monitoring… Они стали доступны в декабре 2018 года.

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

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

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

В правилах ResponseCache поток NIOThread выполняется без отклонения со стороны пула потоков

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

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

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

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

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

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