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 (pré-visualização)

A partir da visualização da API versão 2023-03-01, 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.

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 um dia. O disjuntor é reiniciado após uma hora.

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

Pool com balanceamento de carga (visualização)

A partir da visualização da versão 2023-05-01 da API, 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. Atualmente, o pool de back-end suporta balanceamento de carga round-robin.

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

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.

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

Limitação

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.

Conteúdos relacionados

  • Configure um back-end do Service Fabric usando o portal do Azure.