01/03/19 - Notas de lançamento do Apigee Edge para nuvem pública

Balanceamento de carga: mais controle para remover servidores com falha

Ao configurar um balanceador de carga para um proxy de API, é possível determinar quantas falhas de resposta ocorrem antes que um servidor seja removido do ciclo de balanceamento de carga. Uma falha na resposta significa que a Apigee não recebe resposta de um servidor de destino. Quando isso acontece, o contador de falhas é incrementado em um. Quando a Apigee recebe uma resposta de um destino, mesmo que ela seja um erro HTTP (como 500), isso é contabilizado como uma resposta do servidor de destino e o contador de falha é redefinido. Para ajudar a garantir que respostas HTTP inválidas (como 500) também incrementem o contador de falhas para tirar um servidor não íntegro da rotação do balanceamento de carga o quanto antes, adicione um novo elemento <ServerUnhealthyResponse> com elementos filhos <ResponseCode> à configuração do balanceador de carga. O Edge também vai contar respostas com esses códigos como falhas.

<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>
  
  

Melhorias na política AccessControl

A política AccessControl determina quais endereços IP podem fazer chamadas para um proxy de API. Um novo elemento nessa política dá aos desenvolvedores de API mais controle para identificar quais endereços IP avaliar.

<IgnoreTrueClientIPHeader>: opcional (o padrão é "false"). Quando isso é definido como verdadeiro, a política ignora o cabeçalho True-Client-IP e avalia os endereços IP no cabeçalho X-Forwarded-For, seguindo o comportamento de avaliação X-Forwarded-For configurado.

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

Para mais detalhes, consulte esta postagem na comunidade.

Dois novos elementos estão disponíveis na política RaiseFault para tornar o processamento de FaultRules mais limpo e eficiente.

• ShortFaultReason é um booleano que, quando definido como "true", coloca o nome da política na variável fault.reason.
• AssignVariable, disponível no FaultResponse, permite atribuir a resposta de falha a uma variável para ser usada por outras políticas no fluxo de proxy de API.

Os limites agora estão sendo aplicados aos destinos hospedados. Consulte Limites para mais detalhes.

Agora é possível usar variáveis de modelo de mensagem para definir endereços IP e máscaras de CIDR na política AccessControl. Por exemplo, se você quiser armazenar um endereço IP e uma máscara em um mapa de valores-chave (KVM), recupere esses valores de uma variável definida no fluxo do proxy de API. Isso permite mudar os valores de IP com mais facilidade no tempo de execução sem precisar alterar a configuração da política.

Por exemplo, em vez de:

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

É possível configurar a política assim, supondo que os valores estejam armazenados em um KVM e que você use a política KeyValueMapOperations para recuperar os valores e atribuí-los às variáveis mostradas aqui:

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

O monitoramento da API oferece dois papéis: administrador e usuário do monitoramento da API, descritos em Acessar o monitoramento da API. Elas foram disponibilizadas em dezembro de 2018.

O Edge agora adiciona o cabeçalho X-Apigee.Message-Timeout a cada solicitação. Este cabeçalho é para uso interno do Edge. Não confie nos valores nos cabeçalhos X-Apigee.* nos seus proxies de API, já que eles não são destinados ao uso do cliente e podem ser removidos ou alterados pela Apigee a qualquer momento.

Trate os erros de exclusão do keystore para que a chamada de API não falhe

x-apigee.edge.execution.sense.action é sempre definido como nulo

Na política ResponseCache, o NIOTheread está sendo executado sem rejeição do pool de linhas de execução

Vários exportadores de registros em roteadores da Apigee causam alto uso da CPU

Erros 404 intermitentes em organizações específicas

O fluxo compartilhado implantado não está sendo executado em alguns processadores de mensagens

Essa correção será incluída na próxima versão do Edge para nuvem privada.

Essa correção será incluída na próxima versão do Edge para nuvem privada.

Essa correção será incluída na próxima versão do Edge para nuvem privada.