Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In un'architettura di microservizi, un client potrebbe interagire con più di un servizio front-end. Dato questo fatto, in che modo un client conosce gli endpoint da chiamare? Cosa accade quando vengono introdotti nuovi servizi o quando viene eseguito il refactoring dei servizi esistenti? In che modo i servizi gestiscono la terminazione SSL, TLS reciproco, l'autenticazione e altri problemi? Un gateway API può aiutare a risolvere questi problemi.
Scaricare un file di Visio di questa architettura.
Che cos'è un gateway API?
Un gateway API fornisce un punto di ingresso centralizzato per la gestione delle interazioni tra client e servizi dell'applicazione. Funge da proxy inverso e indirizza le richieste dei client ai servizi appropriati. Può anche eseguire varie funzionalità trasversali, come l'autenticazione, la terminazione SSL, il TLS reciproco e la limitazione della velocità delle richieste.
Perché usare un gateway API?
Un gateway API semplifica la comunicazione, migliora le interazioni client e centralizza la gestione delle responsabilità comuni a livello di servizio. Funge da intermediario e impedisce l'esposizione diretta dei servizi dell'applicazione ai client. Senza un gateway API, i client devono comunicare direttamente con i singoli servizi dell'applicazione, che possono presentare le sfide seguenti:
codice client complesso: può comportare codice client complesso. I client devono tenere traccia di più endpoint e gestire gli errori in modo resiliente.
accoppiamento stretto: crea l'accoppiamento tra il client e il back-end. I clienti devono comprendere la scomposizione dei singoli servizi, il che complica la manutenzione dei servizi e il refactoring.
maggiore latenza: una singola operazione potrebbe richiedere chiamate a più servizi. Il risultato può essere costituito da più round trip di rete tra il client e il server, aggiungendo una latenza significativa.
la gestione ridondante dei problemi: ogni servizio pubblico deve gestire problemi come l'autenticazione, SSL e la limitazione della frequenza dei client.
Limitazioni del protocollo: i servizi devono esporre un protocollo descrittivo per i client, ad esempio HTTP o WebSocket. Questa esposizione limita le opzioni dei protocolli di comunicazione.
superficie di attacco espansa: gli endpoint pubblici aumentano la superficie di attacco potenziale e richiedono la protezione avanzata.
Come usare un gateway API
Un gateway API può essere personalizzato in base ai requisiti dell'applicazione usando modelli di progettazione specifici. Questi modelli di progettazione indirizzano le funzionalità chiave, ad esempio routing, aggregazione delle richieste e problematiche trasversali:
Instradamento del gateway. È possibile usare un gateway API come proxy inverso per instradare le richieste client a servizi applicazione diversi. Il gateway API usa il routing di livello 7 e fornisce un singolo endpoint da usare per i client. Usa il routing di API Gateway quando vuoi disaccoppiare i client dai servizi applicativi.
Aggregazione dei gateway. È possibile usare il gateway API per aggregare più richieste client in una singola richiesta. Usare questo modello quando una singola operazione richiede chiamate a più servizi dell'applicazione. Nell'aggregazione API il client invia una richiesta al gateway API. Il gateway API instrada quindi le richieste ai vari servizi necessari per le operazioni. Infine, il gateway API aggrega i risultati e li invia al client. L'aggregazione consente di ridurre l'eccessivo numero di scambi tra il client e i servizi dell'applicazione.
Offloading del gateway. È possibile usare un gateway API per fornire funzionalità trasversali, quindi i singoli servizi non devono fornirlo. Può essere utile consolidare le funzionalità trasversali in un'unica posizione, invece di rendere ogni servizio responsabile. Ecco alcuni esempi di funzionalità che è possibile delegare a un gateway API:
- Terminazione SSL
- TLS reciproco
- Autenticazione
- Elenco indirizzi IP consentiti o elenco di blocchi
- Limitazione della frequenza delle richieste del client (throttling)
- Elenco indirizzi IP consentiti o elenco di blocchi
- Limitazione dei client
- Registrazione e monitoraggio
- Memorizzazione nella cache delle risposte
- Firewall per applicazioni Web
- Compressione GZIP
- Manutenzione del contenuto statico
Opzioni del gateway API
Ecco alcune opzioni per l'implementazione di un gateway API nell'applicazione.
server proxy inverso. Nginx e HAProxy sono soluzioni open source di proxy inversi. Supportano funzionalità come il bilanciamento del carico, la terminazione SSL e il routing di livello 7. Hanno versioni gratuite e edizioni a pagamento che forniscono funzionalità aggiuntive e opzioni di supporto. Questi prodotti sono maturi con set di funzionalità avanzati, prestazioni elevate ed estendibili.
Gateway di ingresso del service mesh. Se si utilizza già un service mesh, il relativo gateway di ingresso può fungere da gateway API. Usarlo significa che il traffico nord-sud entra immediatamente nel piano dati della mesh e partecipa agli stessi mTLS, identità del carico di lavoro, criteri di autorizzazione e telemetria del traffico est-ovest. Per AKS, il componente aggiuntivo del service mesh basato su Istio è l'opzione gestita supportata e include un gateway di ingresso Istio gestito. Linkerd e Consul sono alternative non gestite.
I gateway di ingresso della mesh in genere offrono capacità inferiori rispetto ai gateway API dedicati in termini di web application firewall (WAF), gestione delle API come prodotto, trasformazione delle richieste e routing globale, quindi è opportuno affiancarli ad Application Gateway, Front Door o API Management, oppure sostituirli con questi, quando tali funzionalità sono necessarie.
gateway applicazione di Azure. Application Gateway è un servizio di bilanciamento del carico gestito. Fornisce il routing di livello 7, la terminazione SSL e un web application firewall (WAF).
Frontdoor di Azure. Frontdoor di Azure è una rete per la distribuzione di contenuti (RETE CDN). Usa punti di presenza globali e locali (PoP) per fornire accesso rapido, affidabile e sicuro al contenuto Web statico e dinamico delle applicazioni a livello globale.
Gestione API di Azure. Gestione API è una soluzione gestita per la pubblicazione di API in clienti esterni e interni. Fornisce funzionalità per gestire le API pubbliche, tra cui la limitazione della velocità, le restrizioni IP e l'autenticazione usando l'ID Microsoft Entra o altri provider di identità. La Gestione API non esegue il bilanciamento del carico, quindi è consigliabile usarla con un sistema di bilanciamento del carico, ad esempio gateway applicazione di Azure o un proxy inverso. Per altre informazioni, vedere Gestione API con gateway applicazione di Azure.
Scegli una tecnologia di API gateway
Quando si seleziona un gateway API, considerare i fattori seguenti:
Supporta tutti i requisiti. Scegliere un gateway API che supporti le funzionalità necessarie. Tutte le opzioni precedenti del gateway API supportano il routing di livello 7. Tuttavia, il supporto per altre funzionalità, ad esempio l'autenticazione, la limitazione della frequenza e la terminazione SSL, può variare. Valutare se un singolo gateway soddisfa le esigenze o se sono necessari più gateway.
Preferisci le opzioni integrate. Usa le soluzioni di gateway API e di Ingress integrate fornite dalla tua piattaforma, come App contenitore di Azure e AKS, quando soddisfano i tuoi requisiti di sicurezza e controllo. Usare un gateway personalizzato solo se le opzioni predefinite non dispongono di flessibilità necessaria. Le soluzioni personalizzate richiedono un modello di governance, ad esempio GitOps, per gestire in modo efficace il ciclo di vita.
Scegliere il modello di distribuzione corretto. Usare servizi gestiti come gateway applicazione di Azure e Gestione API di Azure per ridurre il carico operativo. Se usate proxy inversi di uso generale o bilanciatori del carico, distribuiteli in modo coerente con la vostra architettura. È possibile distribuire gateway API generici su macchine virtuali dedicate o all'interno di un cluster AKS nelle rispettive offerte di controller di ingresso. Per isolare il gateway API dal carico di lavoro, è possibile distribuirli all'esterno del cluster, ma questa distribuzione aumenta la complessità di gestione.
Gestire le modifiche. Quando si aggiornano i servizi o si aggiungono nuovi servizi, potrebbe essere necessario aggiornare le regole di routing del gateway. Implementare processi o flussi di lavoro per gestire le regole di routing quando si aggiungono o modificano servizi, certificati SSL, elenchi di indirizzi IP consentiti e configurazioni di sicurezza. Usa strumenti di Infrastructure as Code (IaC) e di automazione per semplificare la gestione del gateway API.
Passaggi successivi
Gli articoli precedenti hanno esaminato le interfacce tra microservizi e tra microservizi e applicazioni client. Queste interfacce considerano ogni servizio come un'unità opaca autonoma. Un principio fondamentale dell'architettura dei microservizi è che i servizi non devono mai esporre dettagli interni su come gestiscono i dati. Questo approccio ha implicazioni significative per mantenere l'integrità e la coerenza dei dati, che è l'oggetto dell'articolo successivo.