Antipatrón: balancear carga con un único servidor de destino donde el valor MaxFailures es distinto de cero

Estás consultando la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.

La configuración de TargetEndpoint define la forma en que Apigee se conecta a un servicio o una API de backend. Envía las solicitudes y recibe las respuestas del servicio de backend. El servicio de backend puede ser un servidor HTTP/HTTPS o NodeJS.

El servicio de backend de TargetEndpoint se puede invocar de una de las siguientes formas:

  • URL directa a un servidor HTTP o HTTPS
  • Configuración de TargetServer

Del mismo modo, la política ServiceCallout se puede usar para llamar a cualquier servicio externo desde el flujo del proxy de API. Esta política permite definir URLs de destino HTTP o HTTPS directamente en la política o mediante una configuración de TargetServer.

Configuración de TargetServer

La configuración de TargetServer desacopla las URLs de endpoint concretas de las configuraciones de TargetEndpoint o de las políticas Service Callout. Se hace referencia a un TargetServer por su nombre en lugar de por la URL en TargetEndpoint. La configuración de TargetServer tendrá el nombre de host del servicio de backend, el número de puerto y otros detalles.

A continuación, se muestra un ejemplo de configuración de TargetServer:

<TargetServer name="target1">
  <Host>www.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

TargetServer te permite tener configuraciones diferentes para cada entorno. Una política TargetEndpoint o Service Callout se puede configurar con uno o varios TargetServers con nombre mediante un LoadBalancer. La compatibilidad integrada con el balanceo de carga mejora la disponibilidad de las APIs y la conmutación por error entre las instancias de servidor de backend configuradas.

A continuación, se muestra un ejemplo de configuración de TargetEndpoint que usa TargetServers:

<TargetEndpoint name="default">
    <HTTPTargetConnection>>
      <LoadBalancer>
        <Server name="target1"/>
        <Server name="target2"/>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures

La configuración MaxFailures especifica el número máximo de errores de solicitud al servidor de destino tras el cual se marcará como inactivo y se eliminará de la rotación para todas las solicitudes posteriores.

Ejemplo de configuración con MaxFailures especificado:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
        <Server name="target2"/>
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

En el ejemplo anterior, si se producen cinco errores consecutivos en las solicitudes de "target1", se eliminará "target1" de la rotación y todas las solicitudes posteriores se enviarán solo a target2.

Antipatrón

No se recomienda tener un único TargetServer en una configuración LoadBalancer de la política TargetEndpoint o Service Callout con MaxFailures asignado a un valor distinto de cero, ya que puede tener consecuencias negativas.

Considere la siguiente configuración de ejemplo, que tiene un único TargetServer llamado "target1" con MaxFailures definido en 5 (un valor distinto de cero): 

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

Si las solicitudes al TargetServer "target1" fallan cinco veces (el número especificado en MaxFailures), el TargetServer se elimina de la rotación. Como no hay otros TargetServers a los que conmutar por error, se producirá un error 503 Service Unavailable en todas las solicitudes posteriores al proxy de API que tenga esta configuración.

Aunque el TargetServer "target1" vuelva a su estado normal y pueda enviar respuestas correctas, las solicitudes al proxy de API seguirán devolviendo errores 503. Esto se debe a que Apigee no vuelve a poner automáticamente el TargetServer en rotación, aunque el destino vuelva a estar activo. Para solucionar este problema, el proxy de API debe volver a implementarse para que Apigee vuelva a poner el TargetServer en rotación.

Si se usa la misma configuración en la política Service Callout, las solicitudes a la API recibirán un error 500 después de que las solicitudes a TargetServer "target1" fallen 5 veces.

Impacto

Si se usa un único TargetServer en una configuración LoadBalancer de TargetEndpoint o de una política de llamada de servicio con MaxFailures definido en un valor distinto de cero, se produce lo siguiente:

  • Las solicitudes a la API fallan continuamente con errores 503 o 500 (después de que las solicitudes fallen un número de veces igual a MaxFailures) hasta que se vuelve a implementar el proxy de API.
  • La interrupción es más larga, ya que es complicado y puede llevar más tiempo diagnosticar la causa de este problema (sin conocimiento previo sobre este antipatrón).

Práctica recomendada

  1. Tener más de un TargetServer en la configuración de LoadBalancer para conseguir una mayor disponibilidad.

  2. Define siempre un monitor de estado cuando MaxFailures se defina con un valor distinto de cero. Un servidor de destino se retirará de la rotación cuando el número de errores alcance el valor especificado en MaxFailures. HealthMonitor se asegura de que TargetServer vuelva a estar en rotación en cuanto el servidor de destino vuelva a estar disponible, por lo que no es necesario volver a implementar el proxy.

    Para asegurarse de que la comprobación de estado se realiza en el mismo número de puerto que usa Apigee para conectarse a los servidores de destino, Apigee recomienda que omita el elemento secundario <Port> de <TCPMonitor>, a menos que sea diferente del puerto de TargetServer. De forma predeterminada, <Port> es el mismo que el puerto TargetServer.

    Configuración de ejemplo con HealthMonitor:

    <TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>RoundRobin</Algorithm>
      <Server name="target1" />
      <Server name="target2" />
      <MaxFailures>5</MaxFailures>
    </LoadBalancer>
    <Path>/test</Path>
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <TCPMonitor>
        <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

  3. Si hay alguna restricción que solo permita un TargetServer y no se usa HealthMonitor, no especifiques MaxFailures en la configuración de LoadBalancer.

    El valor predeterminado de MaxFailures es 0. Esto significa que Apigee siempre intenta conectarse al destino de cada solicitud y nunca elimina el servidor de destino de la rotación.

Más información