19.03.01: Notas de la versión de Apigee Edge para nube pública

Balanceo de cargas: Más control para quitar servidores con errores

Cuando configuras un balanceador de cargas para un proxy de API, puedes determinar cuántos errores de respuesta ocurren antes de que se quite un servidor de la rotación del balanceo de cargas. Un error de respuesta significa que Apigee no recibe ninguna respuesta de un servidor de destino. Cuando esto sucede, el contador de fallas suma una. Cuando Apigee recibe una respuesta de un destino, incluso si la respuesta es un error de HTTP (como 500), se cuenta como una respuesta del servidor de destino y el contador de fallas se restablece. Para ayudar a garantizar que las respuestas HTTP incorrectas (como 500) también aumenten el recuento del contador de fallas a fin de eliminar un servidor en mal estado de la rotación del balanceo de cargas lo antes posible, puedes agregar un nuevo elemento <ServerUnhealthyResponse> con elementos secundarios <ResponseCode> a la configuración de tu balanceador de cargas. Edge también contará las respuestas con esos códigos como fallas.

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

Mejoras en la política AccessControl

La política AccessControl determina qué direcciones IP pueden realizar llamadas a un proxy de API. Un nuevo elemento en esa política brinda a los desarrolladores de APIs más control para identificar qué direcciones IP evaluar.

<IgnoreTrueClientIPHeader>: Opcional (el valor predeterminado es falso). Cuando se establece esto como verdadero, la política ignora el encabezado True-Client-IP y evalúa las direcciones IP en el encabezado X-Forwarded-For, con el comportamiento de evaluación X-Forwarded-For que hayas configurado.

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

Para obtener más información, consulta esta publicación de la Comunidad.

Hay dos elementos nuevos disponibles en la política RaiseFault para que el control de FaultRules sea más limpio y potente.

• ShortFaultReason es un valor booleano que, cuando se establece en verdadero, coloca el nombre de la política en la variable fault.reason.
• AssignVariable, disponible en FaultResponse, te permite asignar la respuesta de error a una variable para que la usen otras políticas en el flujo del proxy de API.

Ahora se aplican límites a los destinos alojados. Consulta Límites para obtener más detalles.

Ahora puedes usar variables de plantillas de mensajes para establecer direcciones IP y máscaras de CIDR en la política de AccessControl. Por ejemplo, si deseas almacenar una dirección IP y una máscara en un mapa de clave-valor (KVM), puedes recuperar esos valores de una variable que establezcas en el flujo del proxy de API. Esto te permite cambiar los valores de IP con mayor facilidad en el tiempo de ejecución sin tener que cambiar la configuración de tu política.

Por ejemplo, en lugar de hacer lo siguiente:

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

Podrías configurar la política de esta manera, suponiendo que los valores se almacenan en un KVM y que usas la política KeyValueMapOperations para recuperar los valores y asignarlos a las variables que se muestran aquí:

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

La supervisión de la API proporciona dos roles: Administrador de supervisión de la API y Usuario de supervisión de la API, que se describen en Accede a la supervisión de la API. Estas se pusieron a disposición en diciembre de 2018.

Ahora, Edge agrega el encabezado X-Apigee.Message-Timeout a cada solicitud. Edge usa este encabezado de forma interna. No confíes en los valores de los encabezados X-Apigee.* en tus proxies de API, ya que estos encabezados no están destinados para el uso del cliente y Apigee los puede quitar o cambiar en cualquier momento.

Controla los errores de eliminación del almacén de claves para que no falle la llamada a la API

x-apigee.edge.execution.sense.action siempre se establece en nulo

En la política ResponseCache, NIOTheread se ejecuta sin rechazo del grupo de subprocesos

Varios exportadores de registros en los routers de Apigee causan un uso elevado de la CPU

Errores 404 intermitentes en organizaciones específicas

El flujo compartido implementado no se ejecuta en algunos procesadores de mensajes

Esta corrección se incluirá en la próxima versión de Edge para la nube privada.

Esta corrección se incluirá en la próxima versión de Edge para la nube privada.

Esta corrección se incluirá en la próxima versión de Edge para la nube privada.