Partilhar via

Backends no Gerenciamento de API

  • Artigo

APLICA-SE A: Todas as camadas de gerenciamento de API

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

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

O Gerenciamento de API também dá suporte ao uso de outros recursos do Azure como um back-end de API, como:

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

Benefícios dos backends

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

Use back-ends para um ou mais dos seguintes:

  • Autorizar as credenciais de solicitações para o serviço de back-end
  • Aproveite a funcionalidade de Gerenciamento de API para manter segredos no Cofre de Chaves do Azure se os valores nomeados estiverem configurados para autenticação de cabeçalho ou parâmetro de consulta.
  • Defina regras de disjuntor para proteger seu back-end de muitas solicitações
  • Encaminhar ou balancear solicitações de balanceamento de carga para vários back-ends

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

Referência de back-end usando a política set-backend-service

Depois de criar um back-end, você pode fazer referência ao back-end em suas APIs. Use a set-backend-service política para direcionar uma solicitação de API de entrada para o back-end. Se você já configurou um serviço Web de back-end para uma API, poderá usar a set-backend-service política para 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 a lógica condicional com a set-backend-service política para alterar o back-end efetivo com base no local, gateway que foi chamado ou outras expressões.

Por exemplo, aqui está 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 a porcentagem de condições de falha durante um intervalo de tempo definido e um intervalo de códigos de status que indicam falhas.
  • Quando o disjuntor dispara, 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 para o cliente.
  • Após a duração da viagem configurada, o circuito é reiniciado e o tráfego é retomado para o back-end.

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

Nota

  • Atualmente, o disjuntor de back-end não é suportado na camada de consumo do Gerenciamento de API.
  • Devido à natureza distribuída da arquitetura de Gerenciamento de API, as regras de disparo do disjuntor são aproximadas. Instâncias diferentes do gateway não sincronizam 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 back-end.

Exemplo

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

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

Inclua um trecho semelhante ao seguinte no modelo Bicep para um recurso de back-end com um 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
        }
      ]
    }
   }
 }

Pool com balanceamento de carga

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

Use um pool de back-end para cenários como os seguintes:

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

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

Nota

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

Opções de balanceamento de carga

O Gerenciamento de API suporta as 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 pelos 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 prioridades: os back-ends são organizados em grupos prioritários e as solicitações são enviadas aos back-ends na ordem dos grupos prioritários. Dentro de um grupo prioritário, 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.

Nota

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

Exemplo

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

Inclua um trecho semelhante ao seguinte no modelo Bicep para um recurso de back-end com um pool com 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
        }
      ]
    }
  }
}

Limitações

  • Para as camadas Developer 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 são as mesmas. Se você encontrar essa limitação, siga as instruções no artigo Self-Chained API Management request limitation in internal virtual network mode no blog Tech Community.
  • Atualmente, apenas uma regra pode ser configurada para um disjuntor back-end.

Conteúdos relacionados