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:
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. Un gateway gestito autonomo può anche essere associato a un'area di lavoro in un'istanza di Gestione API. 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.
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
- Area di lavoro: il gateway gestito disponibile in un'area di lavoro in determinati 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 | Area di lavoro |
|---|---|---|---|---|---|
| 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 | ✔️3 | ❌ | ✔️1 | ✔️3 |
| Distribuzione in più aree | Premium | ❌ | ❌ | ✔️1 | ❌ |
| Certificati radice CA per la convalida dei certificati | ✔️ | ✔️ | ❌ | ✔️4 | ❌ |
| Certificati di dominio gestito | Developer, Basic, Standard, Premium | ❌ | ✔️ | ❌ | ❌ |
| Impostazioni di TLS | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| HTTP/2 (da client a gateway) | ✔️5 | ✔️5 | ❌ | ✔️ | ❌ |
| HTTP/2 (da gateway a back-end) | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Rilevamento delle minacce API con Defender per le API | ✔️ | ✔️ | ❌ | ❌ | ❌ |
1 Dipende dalla modalità di distribuzione del gateway, ma è responsabilità del cliente.
2 La connettività all'endpoint di configurazione del gateway self-hosted v2 richiede la risoluzione DNS del nome host dell'endpoint.
3 Due zone sono abilitate per impostazione predefinita; non configurabile.
4 I certificati radice CA per il gateway self-hosted vengono gestiti separatamente per ogni gateway
5 Il protocollo client deve essere abilitato.
API di back-end
| Supporto funzionalità | Classico | V2 | Consumo | Self-hosted | Area di lavoro |
|---|---|---|---|---|---|
| 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 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 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 | Area di lavoro |
|---|---|---|---|---|---|
| Integrazione Dapr | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Resolver GraphQL e Convalida GraphQL | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Ottieni codice di autorizzazione | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Quota e limite di frequenza | ✔️ | ✔️2 | ✔️3 | ✔️4 | ✔️ |
1 I criteri configurati che non sono supportati dal gateway self-hosted vengono ignorati durante l'esecuzione dei criteri.
2 La quota per criterio chiave non è disponibile nei livelli v2.
3 Il limite di velocità per chiave, quota per chiave e criteri di limite di token OpenAI di Azure non sono disponibili nel livello a consumo.
4 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 | Area di lavoro |
|---|---|---|---|---|---|
| Analisi di API | ✔️ | ✔️1 | ❌ | ❌ | ❌ |
| Application Insights | ✔️ | ✔️ | ✔️ | ✔️2 | ✔️ |
| Registrazione tramite Hub eventi | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Metriche in Monitoraggio di Azure | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Agente di raccolta OpenTelemetry | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Log delle richieste di Monitoraggio di Azure e Log Analytics | ✔️ | ✔️ | ❌ | ❌3 | ❌ |
| Metriche e log locali | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Traccia delle richieste | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
1 I livelli v2 supportano l'analisi basata su Monitoraggio di Azure.
2 Il gateway usa il buffer di memoria predefinito di Azure Application Insight e non offre garanzie di recapito.
3 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.
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 | Area di lavoro |
|---|---|---|---|---|---|
| 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.
Gateway dell'area di lavoro
Ridimensionare la capacità aggiungendo e rimuovendo le unità di scalabilità nel gateway dell'area di lavoro.
Contenuto correlato
Altre informazioni su:
- Gestione API in un ambiente ibrido e multicloud
- Metrica della capacità per le decisioni di ridimensionamento
- Funzionalità di osservabilità in Gestione API
- Funzionalità del gateway GenAI in Gestione API