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

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

Al configurar un balanceador de cargas para un proxy de API, puedes determinar la cantidad de las fallas ocurren antes de que se quite un servidor de la rotación del balanceo de cargas. Error de respuesta significa que Apigee no recibe ninguna respuesta del servidor de destino. Cuando esto sucede, la falla del contador se incrementa en uno. Cuando Apigee recibe una respuesta de un objetivo, incluso si es un error de HTTP (como 500) que cuenta como una respuesta del servidor de destino, y se restablece el contador de fallas. Para ayudar a garantizar que las respuestas HTTP incorrectas (como 500) aumentar el contador de fallas para quitar un servidor en mal estado de la rotación del balanceo de cargas tan pronto como sea posible, puedes agregar un nuevo elemento <ServerUnhealthyResponse> con <ResponseCode> elementos secundarios en la configuración del balanceador de cargas. Edge también registrará como errores las respuestas con esos códigos.

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

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

<IgnoreTrueClientIPHeader>: Opcional (el valor predeterminado es falso). Si la estableces como verdadera, la política ignorará el encabezado True-Client-IP y evalúa direcciones IP en el encabezado X-Forwarded-For, después del X-Forwarded-Para el comportamiento de evaluación que configuraste.

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

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

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

Ahora se están aplicando los límites a los destinos alojados. Consulta Límites para obtener información detallada sobre los límites.

Ahora puedes usar variables de plantilla de mensajes para configurar direcciones IP y máscaras CIDR en la Política de AccessControl. Por ejemplo, si quieres almacenar un dirección IP y 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 la 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 están almacenados en un KVM, y 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 API proporciona dos roles: Administrador de supervisión de API y Usuario de supervisión de API, como se describe en Acceso a la supervisión de la API. Esta función estuvo disponible en diciembre de 2018.

Edge ahora agrega el encabezado X-Apigee.Message-Timeout a cada solicitud. Este encabezado es para uso interno de Edge. No confíe en los valores de los encabezados X-Apigee.* en los proxies de su API ya que estos encabezados no están destinados a los clientes y los puede quitar o cambiar en cualquier momento.

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

x-apigee.edge.execution.sense.action siempre se configura como nulo

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

Varios exportadores de registros en routers de Apigee provocan un alto uso 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.