Back-end in Gestione API

  • Articolo

SI APPLICA A: Tutti i livelli di Gestione API

Un back-end (o back-end dell'API) in Gestione API è un servizio HTTP che implementa l'API front-end e le relative operazioni.

Quando si importano determinate API, Gestione API configura automaticamente il back-end dell'API. Gestione API, ad esempio, configura il servizio Web back-end durante l'importazione:

Gestione API supporta anche l'uso di altre risorse di Azure come back-end API, ad esempio:

Vantaggi dei back-end

Gestione API supporta le entità back-end in modo da poter gestire i servizi back-end dell'API. Un'entità back-end incapsula informazioni sul servizio back-end, promuovendo la riutilizzabilità tra le API e una governance migliorata.

Usare i back-end per uno o più degli elementi seguenti:

  • Autorizzare le credenziali delle richieste al servizio back-end
  • Sfruttare Gestione API funzionalità per gestire i segreti in Azure Key Vault se i valori denominati sono configurati per l'autenticazione dei parametri di intestazione o query.
  • Definire le regole dell'interruttore per proteggere il back-end da troppe richieste
  • Instradare o bilanciare il carico delle richieste a più back-end

Configurare e gestire le entità back-end nella portale di Azure o usando API o strumenti di Azure.

Fare riferimento al backend utilizzando il criterio set-backend-service

Dopo aver creato un back-end, è possibile fare riferimento al back-end nelle API. Usare i set-backend-service criteri per indirizzare una richiesta API in ingresso al back-end. Se è già stato configurato un servizio Web back-end per un'API, è possibile usare i set-backend-service criteri per reindirizzare la richiesta a un'entità back-end. Ad esempio:

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

È possibile usare la logica condizionale con il criterio set-backend-service per modificare il back-end effettivo in base alla posizione, al gateway che è stato chiamato o ad altre espressioni.

Ad esempio, di seguito viene riportato un criterio per instradare il traffico a un altro back-end in base al gateway che è stato chiamato:

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

Interruttore (anteprima)

A partire dall'anteprima dell'API versione 2023-03-01, Gestione API presenta una proprietà interruttore nella risorsa back-end al fine di proteggere un servizio back-end dal sovraccarico di un numero eccessivo di richieste.

  • La proprietà interruttore definisce le regole per l'attivazione dell'interruttore, come il numero o la percentuale di condizioni di guasto durante un intervallo di tempo definito e una gamma di codici di stato che indicano i guasti.
  • Quando l'interruttore viene attivato, Gestione API interrompe l'invio di richieste al servizio back-end per un periodo di tempo definito e restituisce al client una risposta 503 Servizio non disponibile.
  • Una volta trascorso il tempo di attivazione configurato, il circuito viene ripristinato e il traffico riprende verso il back-end.

L'interruttore back-end è un'implementazione del modello di interruttore per consentire al back-end di eseguire il ripristino da situazioni di overload. Aumenta i criteri generali di limitazione della frequenza e limitazione della concorrenza che è possibile implementare per proteggere il gateway di Gestione API e i servizi back-end.

Nota

  • Attualmente, l'interruttore back-end non è supportato nel livello A consumo di Gestione API.
  • A causa della natura distribuita dell'architettura di Gestione API, le regole di interruzione del circuito sono approssimative. Le diverse istanze del gateway non sono sincronizzate e applicano regole di interruzione del circuito in base alle informazioni sulla stessa istanza.

Esempio

Usare l'API REST di Gestione API o un modello Bicep o ARM per configurare un interruttore in un back-end. Nell'esempio seguente, l'interruttore in myBackend nell'istanza di Gestione API myAPIM viene attivato quando sono presenti tre o più codici di stato 5xx che indicano errori del server in un giorno. L'interruttore viene ripristinato dopo un'ora.

Includere un frammento di codice simile al seguente nel modello Bicep per una risorsa back-end con un interruttore:

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 con carico bilanciato (anteprima)

A partire dall'anteprima dell'API versione 2023-05-01, Gestione API supporta pool di back-end, quando si vogliono implementare più back-end per un'API e bilanciare il carico delle richieste in tali back-end. Attualmente, il pool di back-end supporta il bilanciamento del carico round robin.

Usare un pool di back-end per scenari come i seguenti:

  • Distribuire il carico in più back-end, che possono avere singoli interruttori di back-end.
  • Spostare il carico da un set di back-end a un altro per l'aggiornamento (distribuzione blu-verde).

Per creare un pool di back-end, impostare la proprietà type del back-end su pool e specificare un elenco di back-end che costituiscono il pool.

Nota

  • Attualmente, è possibile includere solo singoli back-end in un pool di back-end. Non è possibile aggiungere un back-end di tipo pool a un altro pool di back-end.
  • A causa della natura distribuita dell'architettura di Gestione API, il bilanciamento del carico di back-end è approssimativo. Le diverse istanze del gateway non vengono sincronizzate e il carico verrà bilanciato in base alle informazioni sulla stessa istanza.

Esempio

Usare l'API REST di Gestione API o un modello Bicep o ARM per configurare un pool di back-end. Nell'esempio seguente il back-end myBackendPool nell'istanza di Gestione API myAPIM è configurato con un pool di back-end. I back-end di esempio nel pool sono denominati backend-1 e backend-2.

Includere un frammento di codice simile al seguente nel modello Bicep per una risorsa back-end con un pool con carico bilanciato:

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

Limitazione

Per i livelli Developer e Premium, un'istanza di Gestione API distribuita in una rete virtuale interna può generare errori HTTP 500 BackendConnectionFailure quando l'URL dell'endpoint del gateway e l'URL di back-end sono uguali. Se si verifica questa limitazione, seguire le istruzioni riportate nell'articolo Limitazione delle richieste di Gestione API concatenate automaticamente in modalità rete virtuale interna nel blog della community tecnica.

Contenuto correlato