Back-ends no Gerenciamento de API

  • Artigo

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:

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

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 (versão prévia)

A partir da versão prévia da API 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 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.

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 no myBackend na instância do Gerenciamento de API myAPIM é desarmado quando existem três ou mais códigos de status 5xx indicando erros de servidor em um dia. O disjuntor é redefinido após uma hora.

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-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 (versão prévia)

A partir da versão prévia 2023-05-01 da API, o Gerenciamento de API dá suporte a pools de back-end para quando você quiser implementar vários back-ends para uma API e para solicitações de balanceamento de carga nesses back-ends. Atualmente, o pool de back-end dá suporte ao balanceamento de carga em turnos.

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

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.

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

Conteúdo relacionado