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:

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

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

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

Disyuntor (versión preliminar)

A partir de la versión preliminar 2023-03-01 de la API, API Management expone una propiedad disyuntor en el recurso back-end para proteger un servicio back-end de la sobrecarga debido a 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.

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 disyuntor de myBackend en la instancia de API Management myAPIM realiza viajes cuando hay tres o más códigos de estado 5xx que indican errores de servidor en un día. El disyuntor se restablece al cabo de una hora.

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

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

Grupo de carga equilibrada (versión preliminar)

A partir de la versión preliminar 2023-05-01 de la API, API Management admite grupos de back-end, cuando desea implementar varios back-ends para una API y solicitudes de equilibrio de carga en esos back-ends. Actualmente, el grupo de back-end admite el equilibrio de carga round robin.

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

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.

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:

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-05-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    protocol: 'http'
    url: 'https://example.com'
    pool: {
      services: [
        {
          id: '/backends/backend-1'
        }
        {
          id: '/backends/backend-2'
        }
      ]
    }
  }
}

Limitación

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.

Contenido relacionado