Leer en inglés

Compartir a través de

Back-ends de API Management

  • Artículo

SE APLICA A: todos los niveles de API Management

Un back-end (o back-end de API) de API Management es un servicio HTTP que implementa la API de front-end y sus operaciones.

Al importar ciertas API, API Management configura el back-end de la API automáticamente. Por ejemplo, API Management configura el servicio web back-end al importar:

API Management también admite el uso de otros recursos de Azure como back-end de API, por ejemplo:

Ventajas de los back-ends

API Management admite entidades de back-end para que pueda administrar los servicios back-end de la API. Una entidad de back-end encapsula información sobre el servicio back-end y promueve la reutilización entre API y una gobernanza mejorada.

Use back-ends para uno o varios de los siguientes elementos:

  • Autorizar las credenciales de las solicitudes al servicio back-end
  • Aproveche la funcionalidad de API Management para mantener secretos en Azure Key Vault si los valores con nombre están configurados para la autenticación de parámetros de consulta o encabezado.
  • Definir reglas de disyuntor para proteger el back-end de demasiadas solicitudes
  • Enrutar o equilibrar la carga de solicitudes a varios back-ends

Las entidades de back-end se configuran y administran en Azure Portal o mediante las API o las herramientas de Azure.

Hacer referencia al back-end mediante la directiva set-backend-service

Después de crear un entorno de back-end, puede hacer referencia a la dirección URL del back-end en las API. Use la directiva set-backend-service para dirigir una solicitud de API entrante al back-end. Si ya configuró un servicio web de back-end para una API, puede usar la directiva set-backend-service para redirigir la solicitud a una entidad de back-end en su lugar. Por ejemplo:

XML 
<policies>
    <inbound>
        <base />
        <set-backend-service backend-id="myBackend" />
    </inbound>
    [...]
<policies/>

Nota

Como alternativa, puede usar base-url. Por lo general, el formato es https://backend.com/api. No agregue una barra diagonal al final para evitar configuraciones incorrectas. Normalmente, el valor de punto de conexión de base-url y HTTP(S) en el back-end debe coincidir para habilitar una integración perfecta entre front-end y back-end. Tenga en cuenta que las instancias de API Management anexan el nombre del servicio back-end a la base-url.

Puede usar la lógica condicional con la directiva set-backend-service para cambiar el back-end efectivo en función de la ubicación, la puerta de enlace a la que se llamó u otras expresiones.

Por ejemplo, esta es una directiva para enrutar el tráfico a otro back-end en función de la puerta de enlace a la que se llamó:

XML 
<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@(context.Deployment.Gateway.Id == "factory-gateway")">
                <set-backend-service backend-id="backend-on-prem" />
            </when>
            <when condition="@(context.Deployment.Gateway.IsManaged == false)">
                <set-backend-service backend-id="self-hosted-backend" />
            </when>
            <otherwise />
        </choose>
    </inbound>
    [...]
<policies/>

Interruptor automático

API Management expone un propiedadinterruptor de circuito en el recurso backend para proteger un servicio backend de ser abrumado por demasiadas solicitudes.

  • La propiedad disyuntor define reglas para disparar el disyuntor, como el número o el porcentaje de condiciones de error durante un intervalo de tiempo definido y un intervalo de códigos de estado que indican errores.
  • Cuando el disyuntor se dispara, API Management deja de enviar solicitudes al servicio back-end durante un tiempo definido y devuelve una respuesta "503 Servicio no disponible" al cliente.
  • Después de la duración de disparo configurada, el circuito se restablece y el tráfico se reanuda hacia el back-end.

El disyuntor del back-end es una implementación del patrón de disyuntor que permite que el back-end se recupere de situaciones de sobrecarga. Aumenta las directivas generales de limitación de velocidad y limitación de simultaneidad que puede implementar para proteger la puerta de enlace de API Management y los servicios back-end.

Nota

  • Actualmente, el disyuntor de back-end no se admite en el nivel Consumo de API Management.
  • Debido a la naturaleza distribuida de la arquitectura de API Management, las reglas de recorrido del disyuntor son aproximadas. Las distintas instancias de la puerta de enlace no se sincronizan y aplicarán reglas de disyuntor en función de la información de la misma instancia.
  • Actualmente, solo se puede configurar una regla para un disyuntor back-end.

Ejemplo

Use la API de REST de API Management o una plantilla de Bicep o ARM para configurar un disyuntor en un back-end. En el ejemplo siguiente, el interruptor de circuito de myBackend en la instancia de API Management myAPIM recorridos cuando hay tres o más códigos de estado 5xx que indican errores de servidor en 1 hora.

El interruptor se restablece después de 1 hora. Si un encabezado de Retry-After está presente en la respuesta, el interruptor acepta el valor y espera el tiempo especificado antes de volver a enviar solicitudes al back-end.

Incluya un fragmento de código similar al siguiente en la plantilla de Bicep para un recurso back-end con un disyuntor:

Bicep 
resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'http'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'PT1H' 
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'  
          acceptRetryAfter: true
        }
      ]
    }
   }
 }

Grupo de carga equilibrada

API Management admite grupos de backend, cuando desea implementar varios backend para una API y solicitudes de equilibrio de carga en esos backend.

Use un grupo de back-end para escenarios como los siguientes:

  • Extienda la carga a varios back-ends, que pueden tener disyuntores de back-end individuales.
  • Cambie la carga de un conjunto de back-ends a otro para su actualización (implementación azul-verde).

Para crear un grupo de back-end, establezca la propiedad type del back-end en pool y especifique una lista de back-ends que conformen el grupo.

Nota

  • Actualmente, solo puede incluir back-ends únicos en un grupo de back-end. No se puede agregar un back-end de tipo pool a otro grupo de back-end. Puede incluir hasta 30 back-end en un grupo.
  • Debido a la naturaleza distribuida de la arquitectura de API Management, el equilibrio de carga de back-end es aproximado. Las distintas instancias de la puerta de enlace no se sincronizan y equilibrarán la carga en función de la información de la misma instancia.

Opciones de equilibrio de carga

API Management admite las siguientes opciones de equilibrio de carga para los grupos de backend:

  • Round robin: de manera predeterminada, las solicitudes se distribuyen uniformemente entre los back-end del grupo.
  • Ponderado: los pesos se asignan a los backend del grupo y las solicitudes se distribuyen entre los backend en función del peso relativo asignado a cada backend. Use esta opción para escenarios como realizar una implementación azul-verde.
  • Basado en prioridades: los backend se organizan en grupos de prioridad y las solicitudes se envían a los backend en orden de los grupos de prioridad. Dentro de un grupo de prioridad, las solicitudes se distribuyen uniformemente entre los back-end o (si se asignan) según el peso relativo asignado a cada back-end.

Nota

Los backends de los grupos de menor prioridad sólo se utilizarán cuando todos los backends de los grupos de mayor prioridad no estén disponibles porque se hayan disparado las reglas del interruptor de circuito.

Ejemplo

Use la API de REST de API Management o una plantilla de Bicep o ARM para configurar un grupo de back-end. En el ejemplo siguiente, el back-end myBackendPool en la instancia de API Management myAPIM está configurado con un grupo de back-end. Los back-end de ejemplo del grupo se denominan backend-1 y backend-2. Ambos back-end están en el grupo de prioridad más alta; dentro del grupo, back-1 tiene un peso mayor que back-end-2.

Incluya un fragmento de código similar al siguiente en la plantilla de Bicep para un recurso back-end con un grupo de carga equilibrada:

Bicep 
resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    pool: {
      services: [
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1'
          priority: 1
          weight: 3
        }
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2'
          priority: 1
          weight: 1
        }
      ]
    }
  }
}

Limitaciones

  • Para los niveles Desarrollador y Prémium, una instancia de API Management implementada en una red virtual interna puede producir errores HTTP 500 BackendConnectionFailure cuando la dirección URL del punto de conexión de la puerta de enlace y la dirección URL de back-end son la misma. Si encuentra esta limitación, siga las instrucciones del artículo Limitación de solicitudes de API Management autoencadenadas en modo de red virtual interna en el blog de nuestra comunidad tecnológica.
  • Actualmente, solo se puede configurar una regla para un disyuntor back-end.

Contenido relacionado