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 de um servidor ser removido da rotação de balanceamento de carga. Uma falha de resposta significa que a Apigee não recebe nenhuma resposta de um servidor de destino. Quando isso acontece, o contador de falhas aumenta em um. Quando a Apigee recebe uma resposta de um destino, mesmo que a resposta seja um erro HTTP (como 500), isso conta como uma resposta do servidor de destino e o contador de falhas é redefinido. Para 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 de balanceamento de carga o mais rápido possível, adicione um novo elemento <ServerUnhealthyResponse> com elementos filhos <ResponseCode> à configuração do balanceador de carga. O Edge também contará as 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. Com um novo elemento nessa política, os desenvolvedores de API têm mais controle para identificar quais endereços IP avaliar.

<IgnoreTrueClientIPHeader>: opcional (o padrão é "false"). Quando você o define 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 GrowFault para tornar o gerenciamento de FaultRules mais limpo e eficiente.

• ShortFaultReason é um booleano que, quando definido como verdadeiro, 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 a ser usada por outras políticas no fluxo de proxy da API.

Agora, os limites estão sendo aplicados aos destinos hospedados. Consulte Limites para detalhes sobre os limites.

Agora é possível usar variáveis de modelo de mensagem para definir endereços IP e máscaras CIDR na política AccessControl. Por exemplo, se você quiser armazenar um endereço IP e uma máscara em um mapa de chave-valor (KVM), poderá recuperar esses valores de uma variável definida no fluxo do proxy de API. Isso permite alterar os valores de IP com mais facilidade no ambiente 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 dessa forma, supondo que os valores estejam armazenados em uma KVM, e usar 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 de APIs oferece dois papéis: administrador e usuário de monitoramento de API, conforme descrito em Acessar o monitoramento de API. Eles foram disponibilizados em dezembro de 2018.

O Edge agora adiciona o cabeçalho X-Apigee.Message-Timeout a cada solicitação. Esse cabeçalho é para uso interno do Edge. Não confie nos valores nos cabeçalhos X-Apigee.* nos proxies de API, porque esses cabeçalhos não se destinam ao uso do cliente e podem ser removidos ou alterados pela Apigee a qualquer momento.

Solucionar erros de exclusão de keystore para que a chamada de API não falhe

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

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

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

Erros 404 intermitentes em organizações específicas

O fluxo compartilhado implantado não está em execução 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.