Condividi tramite

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 per consentire la gestione dei servizi back-end dell'API. Un'entità back-end incapsula informazioni sul servizio back-end, promuovendo la riutilizzabilità tra le API e migliorando la governance.

Usare i back-end per uno o più delle attività seguenti:

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

Configurare e gestire le entità back-end nel portale di Azure oppure 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 il criterio set-backend-service per indirizzare una richiesta API in ingresso al back-end. Se è già stato configurato un servizio Web back-end per un'API, è possibile usare il criterio set-backend-service 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 automatico

Gestione API espone una proprietà interruttore nella risorsa back-end per evitare che un servizio back-end venga sovraccaricato da 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.
  • Attualmente, è possibile configurare una sola regola per un interruttore back-end.

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 myAPIM di Gestione API viene attivato quando nell'arco di un'ora vengono restituiti tre o più codici di stato 5xx che indicano errori del server.

L'interruttore viene ripristinato dopo un'ora. Se nella risposta è presente un'intestazione Retry-After, l'interruttore accetta il valore e attende il tempo specificato prima di inviare nuovamente le richieste al back-end.

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-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 con bilanciamento del carico

Gestione API supporta pool di back-end, quando si vogliono implementare più back-end per un'API e bilanciare il carico delle richieste tra tali back-end.

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. È possibile includere fino a 30 back-end in un pool.
  • 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.

Opzioni di bilanciamento del carico

Gestione API supporta le opzioni di bilanciamento del carico seguenti per i pool back-end:

  • Round robin: per impostazione predefinita, le richieste vengono distribuite uniformemente tra i back-end del pool.
  • Ponderato: ai back-end del pool vengono assegnati pesi e le richieste vengono distribuite tra i back-end in base al peso relativo assegnato a ogni back-end. Usare questa opzione per scenari come l'esecuzione di una distribuzione blu-verde.
  • Basato su priorità: i back-end vengono organizzati in gruppi di priorità e le richieste vengono inviate ai back-end in ordine di gruppi di priorità. All'interno di un gruppo di priorità, le richieste vengono distribuite uniformemente tra i back-end o, se previsto, in base al peso relativo assegnato a ogni back-end.

Nota

I back-end nei gruppi con priorità più bassa verranno usati solo quando tutti i back-end in gruppi con priorità più alta non sono disponibili perché le regole dell'interruttore vengono bloccate.

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. Entrambi i back-end si trovano nel gruppo con priorità più alta. All'interno del gruppo, backend-1 ha un peso maggiore di 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-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
        }
      ]
    }
  }
}

Limiti

Contenuto correlato