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.
diagramma 
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 attività di taglio incrociato, ad esempio l'autenticazione, la terminazione SSL, tls reciproco e la limitazione della frequenza.
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 client devono comprendere la scomposizione dei singoli servizi, complicando la manutenzione del servizio 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 protocolli di comunicazione opzioni.
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:
routing 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. Usare il routing del gateway API quando si vogliono separare i client dai servizi dell'applicazione.
l'aggregazione 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 la chattiness tra il client e i servizi dell'applicazione.
offload 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 eseguire l'offload in un gateway API:
- Terminazione SSL
- TLS reciproco
- Autenticazione
- Elenco indirizzi IP consentiti o elenco di blocchi
- Limitazione della frequenza client (limitazione)
- Registrazione e monitoraggio
- Memorizzazione nella cache delle risposte
- Web application firewall
- 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 offerte proxy inverso open source. 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.
controller di ingresso mesh del servizio. Se si usa una mesh di servizi, valutare le funzionalità del controller di ingresso specifiche per tale mesh di servizi. Verificare la presenza di componenti aggiuntivi supportati dal servizio Azure Kubernetes, ad esempio Istio e Open Service Mesh. Cercare progetti open source di terze parti, ad esempio Linkerd o Consul Connect. Ad esempio, il controller di ingresso Istio supporta il routing di livello 7, i reindirizzamenti HTTP, i tentativi e altre funzionalità.
gateway applicazione di Azure. Il gateway applicazione è 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à. Gestione API non esegue alcun bilanciamento del carico, quindi è consigliabile usarlo con un servizio di bilanciamento del carico, ad esempio il gateway applicazione di Azure o un proxy inverso. Per informazioni, vedere Gestione API con il gateway applicazione di Azure.
Scegliere una tecnologia gateway API
Quando si seleziona un gateway API, considerare i fattori seguenti:
Supportare 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.
Preferisce le offerte predefinite. Usare soluzioni di ingresso e gateway API predefinite fornite dalla piattaforma, ad esempio App Azure Container e servizio Azure Kubernetes, ogni volta che soddisfano i 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 il gateway applicazione di Azure e Gestione API di Azure per ridurre il sovraccarico operativo. Se si usano proxy inversi o servizi di bilanciamento del carico per utilizzo generico, distribuirli in modo da allinearli all'architettura. È possibile distribuire gateway API per utilizzo generico in macchine virtuali dedicate o all'interno di un cluster del servizio Azure Kubernetes nelle offerte 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. Usare gli strumenti di infrastruttura come codice e 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.