Gateway API in Gestione API di Azure

SI APPLICA A: Tutti i livelli di Gestione API

Questo articolo fornisce informazioni sui ruoli e sulle funzionalità del componente gateway di Gestione API e confronta i gateway che è possibile distribuire.

Informazioni correlate:

• Per una panoramica di scenari, componenti e concetti di Gestione API, vedere Che cos'è Gestione API di Azure?

• Per altre informazioni sui livelli di servizio e sulle funzionalità di Gestione API, vedere:

  • Livelli di Gestione API
  • Confronto basato sulle funzionalità dei livelli di Azure API Management.

Ruolo del gateway

Il gateway di Gestione API (detto anche piano dati o runtime) è il componente del servizio responsabile del proxy delle richieste API, dell'applicazione dei criteri e della raccolta dei dati di telemetria.

In particolare, il gateway:

• Funge da facciata per i servizi back-end accettando chiamate API e instradandole ai back-end appropriati
• Verifica le chiavi API e altre credenziali, ad esempio token JWT e certificati presentati con le richieste
• Applica le quote di utilizzo e i limiti di frequenza
• Facoltativamente, trasforma le richieste e le risposte come specificato nelle istruzioni dei criteri
• Se configurato, memorizza le risposte nella cache per migliorare la latenza di risposta e ridurre al minimo il carico nei servizi back-end
• Genera log, metriche e tracce per monitoraggio, creazione di report e risoluzione dei problemi

Nota

Tutte le richieste al gateway di Gestione API, incluse quelle rifiutate dalle configurazioni dei criteri, vengono conteggiate per limiti di velocità, quote e limiti di fatturazione configurati, se applicati nel livello di servizio.

Gestito e self-hosted

Gestione API offre gateway sia gestiti che self-hosted:

• Gestito: il gateway gestito è il componente gateway predefinito distribuito in Azure per ogni istanza di Gestione API ad ogni livello di servizio. Con il gateway gestito, tutto il traffico dell'API passa attraverso Azure, indipendentemente dalla posizione in cui sono ospitati i servizi back-end che implementano le API.

  Nota

  A causa delle differenze nell'architettura del servizio sottostante, i gateway forniti nei diversi livelli di servizio Gestione API presentano alcune differenze nelle funzionalità. Per informazioni dettagliate, vedere la sezione Confronto tra funzionalità: gateway gestiti e self-hosted.

• Self-hosted: il gateway self-hosted è una versione facoltativa e in contenitori del gateway gestito predefinito disponibile in livelli di servizio selezionati. È utile negli scenari ibridi e multicloud in cui è necessario eseguire i gateway da Azure negli stessi ambienti in cui sono ospitati i servizi back-end delle API. Il gateway self-hosted consente ai clienti con infrastruttura IT ibrida di gestire le API ospitate in locale e tra cloud da un singolo servizio di Gestione API in Azure.

  • Il gateway self-hosted è inserito nel pacchetto come contenitore Docker basato su Linux e viene comunemente distribuito in Kubernetes, compreso servizio Azure Kubernetes e Kubernetes abilitato per Azure Arc.

  • Ogni gateway self-hosted è associato a una risorsa gateway in un'istanza di Gestione API basata sul cloud da cui riceve gli aggiornamenti della configurazione e comunica lo stato.

Importante

Il supporto per le immagini del contenitore del gateway self-hosted di Gestione API di Azure versione 0 e versione 1 termina il 1 ottobre 2023, insieme all'API di configurazione corrispondente v1. Consultare la guida alla migrazione per usare il gateway self-hosted v2.0.0 o versioni successive con l'API di configurazione v2. Altre informazioni nella documentazione di deprecazione

Confronto tra funzionalità: gateway gestiti e self-hosted

Le tabelle seguenti confrontano le funzionalità disponibili nei gateway di Gestione API seguenti:

• Classico : il gateway gestito disponibile nei livelli di servizio Developer, Basic, Standard e Premium (in precedenza raggruppati come livelli dedicati)
• V2 : il gateway gestito disponibile nei livelli Basic v2 e Standard v2
• Consumo : il gateway gestito disponibile nel livello A consumo
• Self-hosted : il gateway self-hosted facoltativo disponibile in selezionare i livelli di servizio

Nota

• Alcune funzionalità dei gateway gestiti e self-hosted sono supportate solo in determinati livelli di servizio o con determinati ambienti di distribuzione per i gateway self-hosted.
• Per le funzionalità attualmente supportate del gateway self-hosted, assicurarsi di aver eseguito l'aggiornamento alla versione principale più recente dell'immagine del contenitore del gateway self-hosted.
• Vedere anche limitazioni del gateway self-hosted.

Infrastruttura

Supporto funzionalità	Classico	V2	Consumo	Self-hosted
Domini personalizzati	✔️	✔️	✔️	✔️
Cache incorporata	✔️	✔️	❌	❌
Cache compatibile con Redis esterno	✔️	✔️	✔️	✔️
Inserimento della rete virtuale	Developer, Premium	❌	❌	✔️1,2
Endpoint privati in ingresso	Developer, Basic, Standard, Premium	❌	❌	❌
Integrazione della rete virtuale in uscita	❌	Standard V2	❌	❌
Zone di disponibilità	Premium	❌	❌	✔️1
Distribuzione in più aree	Premium	❌	❌	✔️1
Certificati radice CA per la convalida dei certificati	✔️	✔️	❌	✔️3
Certificati radice CA per la convalida dei certificati	✔️	✔️	❌	✔️3
Certificati di dominio gestito	Developer, Basic, Standard, Premium	❌	✔️	❌
Impostazioni di TLS	✔️	✔️	✔️	✔️
HTTP/2 (da client a gateway)	✔️4	✔️4	❌	✔️
HTTP/2 (da gateway a back-end)	❌	❌	❌	✔️
Rilevamento delle minacce API con Defender per le API	✔️	✔️	❌	❌

¹ Dipende dalla modalità di distribuzione del gateway, ma è responsabilità del cliente.
² La connettività all'endpoint di configurazione del gateway self-hosted v2 richiede la risoluzione DNS del nome host dell'endpoint.
³ I certificati radice CA per il gateway self-hosted vengono gestiti separatamente per ogni gateway
⁴ Il protocollo client deve essere abilitato.

API di back-end

Supporto funzionalità	Classico	V2	Consumo	Self-hosted
Specifica OpenAPI	✔️	✔️	✔️	✔️
Specifica WSDL	✔️	✔️	✔️	✔️
Specifica WSDL	✔️	✔️	✔️	✔️
App per la logica	✔️	✔️	✔️	✔️
Servizio app	✔️	✔️	✔️	✔️
App per le funzioni	✔️	✔️	✔️	✔️
App contenitore	✔️	✔️	✔️	✔️
Service Fabric	Developer, Premium	❌	❌	❌
GraphQL pass-through	✔️	✔️	✔️	✔️
GraphQL sintetico	✔️	✔️	✔️1	✔️1
WebSocket pass-through	✔️	✔️	❌	✔️
gRPC pass-through	❌	❌	❌	✔️
OData	✔️	✔️	✔️	✔️
OpenAI di Azure	✔️	✔️	✔️	✔️
Interruttore nel back-end	✔️	✔️	❌	✔️
Pool di back-end con bilanciamento del carico	✔️	✔️	✔️	✔️

¹ Le sottoscrizioni di GraphQL sintetico (anteprima) non sono supportate.

Criteri

I gateway gestiti e self-hosted supportano tutti i criteri disponibili nelle definizioni dei criteri con le eccezioni seguenti.

Supporto funzionalità	Classico	V2	Consumo	Self-hosted1
Integrazione Dapr	❌	❌	❌	✔️
Resolver GraphQL e Convalida GraphQL	✔️	✔️	✔️	❌
Ottieni codice di autorizzazione	✔️	✔️	✔️	❌
Quota e limite di frequenza	✔️	✔️2	✔️3	✔️4

¹ I criteri configurati che non sono supportati dal gateway self-hosted vengono ignorati durante l'esecuzione dei criteri.
² La quota per criterio chiave non è disponibile nei livelli v2.
³ Il limite di velocità per chiave e quota per i criteri chiave non è disponibile nel livello A consumo.
⁴ Il numero di limiti di frequenza in un gateway self-hosted possono essere configurati per la sincronizzazione locale (tra le istanze del gateway nei nodi del cluster), ad esempio tramite la distribuzione del grafico Helm per Kubernetes o usando i modelli di distribuzione del portale di Azure. Tuttavia, i conteggi dei limiti di frequenza non vengono sincronizzati con altre risorse del gateway configurate nell'istanza di Gestione API, incluso il gateway gestito nel cloud. Ulteriori informazioni

Monitoraggio

Per informazioni dettagliate sulle opzioni di monitoraggio, vedere Osservabilità in Gestione API di Azure.

Supporto funzionalità	Classico	V2	Consumo	Self-hosted
Analisi di API	✔️	✔️1	❌	❌
Application Insights	✔️	✔️	✔️	✔️
Registrazione tramite Hub eventi	✔️	✔️	✔️	✔️
Metriche in Monitoraggio di Azure	✔️	✔️	✔️	✔️
Agente di raccolta OpenTelemetry	❌	❌	❌	✔️
Log delle richieste di Monitoraggio di Azure e Log Analytics	✔️	✔️	❌	❌2
Metriche e log locali	❌	❌	❌	✔️
Traccia delle richieste	✔️	❌3	✔️	✔️

¹ I livelli v2 supportano l'analisi basata su Monitoraggio di Azure.
² Il gateway self-hosted attualmente non invia i log delle risorse (log di diagnostica) a Monitoraggio di Azure. Facoltativamente, inviare metriche a Monitoraggio di Azure o configurare e rendere persistenti i log in locale in cui viene distribuito il gateway self-hosted.
³ La traccia non è attualmente disponibile nei livelli v2.

Autenticazione e autorizzazione

I gateway gestiti e self-hosted supportano tutte le opzioni di autenticazione e autorizzazione API disponibili con le eccezioni seguenti.

Supporto funzionalità	Classico	V2	Consumo	Self-hosted
Gestione credenziali	✔️	✔️	✔️	❌

Velocità effettiva e ridimensionamento del gateway

Importante

La velocità effettiva è influenzata dal numero e dalla frequenza delle connessioni client simultanee, dal tipo e dal numero di criteri configurati, dalle dimensioni del payload, dalle prestazioni dell'API back-end e da altri fattori. La velocità effettiva del gateway self-hosted dipende anche dalla capacità di calcolo (CPU e memoria) dell'host in cui viene eseguita. Eseguire test di carico del gateway usando le condizioni di produzione previste per determinare con precisione la velocità effettiva stimata.

Gateway gestito

Per la velocità effettiva massima stimata del gateway nei livelli di servizio di Gestione API, vedere Prezzi di Gestione API.

Importante

I dati sulla velocità effettiva vengono presentati solo per informazioni e non devono essere basati sulla pianificazione della capacità e del budget. Per i dettagli, vedere Prezzi di Gestione API.

• Livelli classici

  • Ridimensionare la capacità del gateway aggiungendo e rimuovendo le unità di scalabilità o aggiornando il livello di servizio. Il ridimensionamento non è disponibile nel livello Developer.
  • Nei livelli Basic, Standard e Premium configurare facoltativamente scalabilità automatica di Monitoraggio di Azure.
  • Nel livello Premium aggiungere e distribuire facoltativamente la capacità del gateway in più aree.

• Livelli v2

  • Ridimensionare la capacità del gateway aggiungendo e rimuovendo le unità di scalabilità o aggiornando il livello di servizio.

• Livello A consumo

  • Le istanze di Gestione API nel livello A consumo vengono ridimensionate automaticamente in base al traffico.

Gateway self-hosted

• In ambienti come Kubernetesaggiungere più repliche gateway per gestire l'utilizzo previsto.
• Facoltativamente, configurare la scalabilità automatica per soddisfare le richieste di traffico.

Contenuto correlato

• Altre informazioni su Gestione API in un ambiente ibrido e multicloud
• Altre informazioni sull'uso della metrica di capacità per le decisioni di ridimensionamento
• Informazioni sulle funzionalità di osservabilità in Gestione API