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 de um proxy de API, é possível determinar que ocorrem antes de um servidor ser removido da rotação de balanceamento de carga. Falha na resposta significa que a Apigee não recebe resposta de um servidor de destino. Quando isso acontece, a falha o contador aumenta em um. Quando a Apigee recebe uma resposta de um destino, mesmo que o resposta for um erro HTTP (por exemplo, 500), que conta como uma resposta do servidor de destino, e o contador de falhas será redefinido. Para ajudar a garantir que respostas HTTP inválidas (como 500) também incremente o contador de falhas para tirar um servidor não íntegro da rotação do balanceamento de carga como assim que possível, adicione um novo elemento <ServerUnhealthyResponse> com elementos filhos <ResponseCode> à configuração do balanceador de carga. O Edge também 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 na identificação de qual IP e endereços a serem avaliados.

<IgnoreTrueClientIPHeader>: opcional (o padrão é "false"). Se ela for definida como verdadeira, a política vai ignorar o cabeçalho True-Client-IP e avalia os endereços IP no cabeçalho X-Forwarded-For, seguindo o O comportamento de avaliação "X-Forwarded-For" que você configurou.

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

Para mais detalhes, consulte nesta postagem na Comunidade.

Dois novos elementos estão disponíveis na política liftFault para criar FaultRules. mais limpa 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 com falha a uma variável que será usada por outras políticas no fluxo do proxy de API.

Os limites agora estão sendo aplicados para os destinos hospedados. Acesse Limites para mais detalhes.

Agora você pode usar variáveis de modelo de mensagem para definir endereços IP e máscaras CIDR no Política AccessControl. Por exemplo, se você quiser armazenar um endereço IP e máscara em um mapa de chave-valor (KVM), é possível recuperar esses valores de uma variável definida no fluxo do proxy de API. Isso permite que você altere os valores de IP com mais facilidade durante a 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>
     

Você poderia configurar a política assim, presumindo que os valores estão armazenados em uma KVM, e usar a política KeyValueMapOperations para recuperar os valores e atribuí-los ao das variáveis mostradas aqui:

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

A API Monitoring fornece dois papéis: Administrador da API Monitoring e Usuário da API Monitoring, descritos em Monitoramento da API de acesso. Elas foram disponibilizadas em dezembro de 2018.

Agora, o Edge adiciona o cabeçalho X-Apigee.Message-Timeout a cada solicitação. Este cabeçalho é para uso interno do Edge. Não dependa dos valores nos cabeçalhos X-Apigee.* nos proxies da API pois esses cabeçalhos não são destinados ao uso do cliente e podem ser removidos ou alterados pela Apigee a qualquer momento.

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

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

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

Vários exportadores de registros em roteadores 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.