Back-ends no Gerenciamento de API

APLICA-SE A: todas as camadas do Gerenciamento de API

Um back-end (ou back-end de API) no Gerenciamento de API é um serviço HTTP que implementa a API de front-end e suas operações.

Ao importar determinadas APIs, o Gerenciamento de API configura o back-end de API automaticamente. Por exemplo, o Gerenciamento de API configura o serviço Web de backend ao importar:

• Uma especificação de OpenAPI.
• Uma API SOAP.
• Recursos do Azure, como um Aplicativo de Funções do Azure ou um Aplicativo Lógico disparado por HTTP.

O Gerenciamento de API também dá suporte para o uso de outros recursos do Azure como back-end de API. Por exemplo:

• Um cluster do Service Fabric.
• Um serviço personalizado.

Benefícios dos back-ends

O Gerenciamento de API dá suporte a entidades de back-end para que você possa gerenciar os serviços de back-end da sua API. Uma entidade de back-end encapsula informações sobre o serviço de back-end, promovendo a reutilização entre APIs e uma governança aprimorada.

Use back-ends para um ou mais dos seguintes recursos:

• Autorizar as credenciais de solicitações para o serviço de back-end
• Aproveite a funcionalidade do Gerenciamento de API para manter os segredos no Azure Key Vault se os valores nomeados estiverem configurados para autenticação de parâmetros de consulta ou cabeçalhos.
• Definir regras de disjuntor para proteger seu back-end contra o excesso de solicitações
• Encaminhar ou fazer o balanceamento de carga de solicitações para vários back-ends

Configure e gerencie essas entidades de back-end no portal do Azure ou no uso de APIs ou ferramentas do Azure.

Mencione o back-end que estiver usando a política set-backend-service

Depois de criar um back-end, você pode fazer referência ao back-end nas APIs. Use a política set-backend-service para direcionar para o back-end uma solicitação de API sendo recebida. Se já tiver configurado um serviço web de back-end para uma API, você poderá usar a política set-backend-service para, em vez disso, redirecionar a solicitação para uma entidade de back-end. Por exemplo:

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

Você pode usar uma lógica condicional com a política set-backend-service para alterar o back-end efetivo com base na localização, no gateway que foi chamado ou em outras expressões.

Por exemplo, aqui temos uma política para rotear o tráfego para outro back-end com base no gateway que foi chamado:

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

Disjuntor

O Gerenciamento de API expõe uma propriedade de disjuntor no recurso de back-end para proteger um serviço de back-end de ser sobrecarregado por muitas solicitações.

• A propriedade do disjuntor define regras para acionar o disjuntor, como o número ou porcentagem de condições de falha durante um intervalo de tempo definido e uma faixa de códigos de status que indicam falhas.
• Quando o disjuntor é acionado, o Gerenciamento de API para de enviar solicitações para o serviço de back-end por um tempo definido e retorna uma resposta 503 Serviço Indisponível ao cliente.
• Após a duração do disparo configurada, o circuito é redefinido e o tráfego é retomado para o back-end.

O disjuntor de back-end é uma implementação do padrão de disjuntor para permitir que o back-end se recupere de situações de sobrecarga. Ele aumenta as políticas gerais de limitação de taxa e de limitação de simultaneidade que você pode implementar para proteger o gateway do Gerenciamento de API e seus serviços de back-end.

Observação

• Atualmente, não há suporte para disjuntores de back-end no nível Consumo do Gerenciamento de API.
• Devido à natureza distribuída da arquitetura do Gerenciamento de API, as regras de desarme de disjuntor são aproximadas. Instâncias diferentes do gateway não são sincronizadas e aplicarão regras de disjuntor com base nas informações da mesma instância.
• Atualmente, apenas uma regra pode ser configurada para um disjuntor de back-end.

Exemplo

Use a API REST do Gerenciamento de API ou um modelo do ARM ou do Bicep para configurar um disjuntor em um back-end. No exemplo a seguir, o disjuntor em myBackend na instância do Gerenciamento de API myAPIM é acionado quando há três ou mais códigos de status 5xx indicando erros de servidor em 1 hora.

O disjuntor é redefinido após 1 hora. Se um cabeçalho Retry-After estiver presente na resposta, o disjuntor aceitará o valor e aguardará o tempo especificado antes de enviar solicitações para o back-end novamente.

Bicep

Inclua um snippet de código semelhante ao seguinte no modelo do Bicep para um recurso de back-end com disjuntor:

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

ARM

Inclua um snippet de código JSON semelhante ao seguinte no modelo do ARM para um recurso de back-end com disjuntor:

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "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
        }
      ]
    }
  }
}

Pool com balanceamento de carga

O Gerenciamento de API dá suporte a pools de back-end, quando você deseja implementar vários back-ends em uma API e solicitações de balanceamento de carga nesses back-ends.

Use um pool de back-end para cenários como o seguinte:

• Distribua a carga para vários back-ends, que podem ter disjuntores de back-end individuais.
• Migre a carga de um conjunto de back-ends para outro para fins de atualização (implantação azul-verde).

Para criar um pool de back-end, defina a propriedade type do back-end como pool e especifique uma lista dos back-ends que compõem o pool.

Observação

• Atualmente, você só pode incluir back-ends individuais em um pool de back-end. Você não pode adicionar um back-end do tipo pool a um outro pool de back-end. Você pode incluir até 30 back-ends em um pool.
• Devido à natureza distribuída da arquitetura do Gerenciamento de API, o balanceamento de carga de back-end é aproximado. Instâncias diferentes do gateway não são sincronizadas e farão o balanceamento de carga com base nas informações da mesma instância.

Opções de balanceamento de carga

O Gerenciamento de API dá suporte às seguintes opções de balanceamento de carga para pools de back-end:

• Round-robin: por padrão, as solicitações são distribuídas uniformemente entre os back-ends no pool.
• Ponderado: os pesos são atribuídos aos back-ends no pool e as solicitações são distribuídas entre os back-ends com base no peso relativo atribuído a cada back-end. Use essa opção para cenários como a realização de uma implantação azul-verde.
• Baseado em prioridade: os back-ends são organizados em grupos de prioridade e as solicitações são enviadas aos back-ends por ordem dos grupos de prioridade. Dentro de um grupo de prioridade, as solicitações são distribuídas uniformemente entre os back-ends ou (se atribuídas) de acordo com o peso relativo atribuído a cada back-end.

Observação

Os back-ends em grupos de prioridade mais baixa só serão utilizados quando todos os back-ends em grupos de prioridade mais alta não estiverem disponíveis porque as regras do disjuntor foram acionadas.

Exemplo

Use a API REST do Gerenciamento de API ou um modelo do ARM ou do Bicep para configurar um pool de back-end. No exemplo a seguir, o back-end myBackendPool na instância do Gerenciamento de API myAPIM está configurado com um pool de back-end. Os exemplos de back-end no pool são denominados backend-1 e backend-2. Ambos os back-ends estão no grupo de prioridade mais alta; dentro do grupo, backend-1 tem um peso maior do que backend-2.

Bicep

Inclua um snippet de código semelhante ao seguinte no seu modelo do Bicep para um recurso de back-end com um pool submetido ao balanceamento de carga:

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

ARM

Inclua um trecho de código JSON semelhante ao seguinte no seu modelo do ARM para um recurso de back-end com um pool submetido ao balanceamento de carga.

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "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"    
        }
      ]
    }
  }
}

Limitações

• Para as camadas de Desenvolvedor e Premium, uma instância de Gerenciamento de API implantada em uma rede virtual interna pode gerar erros HTTP 500 BackendConnectionFailure quando a URL do ponto de extremidade do gateway e a URL do back-end forem iguais. Se você se deparar com essa limitação, siga as instruções no artigo Limitação de solicitação de Gerenciamento de API de encadeamento automático no modo de rede virtual interna no blog da Tech Community.
• Atualmente, apenas uma regra pode ser configurada para um disjuntor de back-end.

Conteúdo relacionado

• Blog: Usar o disjuntor do Gerenciamento de API do Azure e o balanceamento de carga com o Serviço OpenAI do Azure
• Configure um Back-end do Service Fabric usando o portal do Azure.