In un'architettura di microservizi, un client potrebbe interagire con più servizi front-end. In questo caso, come determina gli endpoint da chiamare? Che cosa accade in caso di introduzione di nuovi servizi o di refactoring dei servizi esistenti? Come vengono gestiti dai servizi la terminazione SSL, l'autenticazione e altri aspetti? Un gateway API consente di risolvere queste problematiche.
Scaricare un file di Visio di questa architettura.
Informazioni sui gateway API
Un gateway API si trova tra i client e i servizi. e funge da proxy inverso, indirizzando le richieste dai client ai servizi. Può anche eseguire varie attività trasversali come l'autenticazione, la terminazione SSL e la limitazione della frequenza. Se non si distribuisce un gateway, i client devono inviare le richieste direttamente ai servizi front-end. L'esposizione diretta dei servizi ai client, tuttavia, presenta alcuni potenziali problemi:
- Può determinare codice client complesso. Il client deve tenere traccia di più endpoint e gestire gli errori in modo resiliente.
- Crea un accoppiamento tra client e back-end. Il client deve sapere come vengono scomposti i singoli servizi. Ciò rende più difficile la gestione dei client e anche l'esecuzione del refactoring dei servizi.
- Una singola operazione potrebbe richiedere chiamate a più servizi. Ciò può comportare più round trip di rete tra il client e il server, aumentando notevolmente la latenza.
- Ogni servizio rivolto al pubblico deve gestire problemi come autenticazione, SSL e limitazione della frequenza dei client.
- I servizi devono esporre un protocollo descrittivo per il client, ad esempio HTTP o WebSocket. Questo limita la scelta dei protocolli di comunicazione.
- I servizi con endpoint pubblici sono una potenziale superficie di attacco e necessitano di protezione avanzata.
Un gateway consente di risolvere questi problemi disaccoppiando i client dai servizi. I gateway possono eseguire diverse funzioni e potrebbero non essere tutte necessarie. Le funzioni possono essere raggruppate negli schemi progettuali seguenti:
Routing del gateway. Usare il gateway come proxy inverso per indirizzare le richieste a uno o più servizi back-end, con routing di livello 7. Il gateway offre un singolo endpoint per i client e consente di separare i client dai servizi.
Aggregazione tramite il gateway. Usare il gateway per aggregare più richieste singole in un'unica richiesta. Questo schema si applica quando per una singola operazione sono necessarie chiamate a più servizi back-end. Il client invia una richiesta al gateway, che recapita le richieste ai vari servizi back-end e quindi aggrega i risultati e li invia al client. Questo consente di ridurre la quantità di comunicazioni tra client e back-end.
Offload al gateway. usare il gateway per eseguire l'offload delle funzionalità dai singoli servizi al gateway, soprattutto per aspetti trasversali. Può essere utile per consolidare tali funzioni in un'unica posizione anziché affidarne l'implementazione a ogni servizio, Ciò vale soprattutto per le funzionalità che richiedono competenze specializzate per implementare correttamente, ad esempio l'autenticazione e l'autorizzazione.
Ecco alcuni esempi di funzionalità di cui si può eseguire l'offload a un gateway:
- Terminazione SSL
- Authentication
- Elenco indirizzi IP consentiti o elenco di blocchi
- Limitazione della frequenza client (limitazione richieste)
- Registrazione e monitoraggio
- Memorizzazione nella cache delle risposte
- Web application firewall
- Compressione GZIP
- Manutenzione del contenuto statico
Scelta di una tecnologia gateway
Di seguito sono riportate alcune opzioni per l'implementazione di un gateway API nell'applicazione.
Server proxy inverso. Nginx e HAProxy sono server proxy inversi che supportano funzionalità come bilanciamento del carico, SSL e routing di livello 7. Entrambi sono prodotti open source gratuiti, con edizioni a pagamento che offrono funzionalità aggiuntive e opzioni di supporto. Sia Nginx che HAProxy sono prodotti avanzati con ampi set di funzionalità e prestazioni elevate. Possono essere estesi con moduli di terze parti o scrivendo script personalizzati in Lua. Nginx supporta anche un modulo di scripting basato su JavaScript denominato NGINX JavaScript. Questo modulo è stato formalmente denominato nginScript.
Controller di ingresso per rete mesh di servizi. Se si usa una mesh di servizi, ad esempio Linkerd o Istio, prendere in considerazione le funzionalità fornite dal controller di ingresso per tale mesh di servizi. Il controller di ingresso Istio, ad esempio, supporta il routing di livello 7, i reindirizzamenti HTTP, la ripetizione dei tentativi e altre funzionalità.
Gateway applicazione di Azure. Il gateway applicazione è un servizio di bilanciamento del carico gestito che può eseguire il routing di livello 7 e la terminazione SSL. Offre anche un Web application firewall (WAF).
Frontdoor di Azure è il cloud moderno di Microsoft rete per la distribuzione di contenuti (rete CDN) che offre accesso rapido, affidabile e sicuro tra gli utenti e il contenuto Web statico e dinamico delle applicazioni in tutto il mondo. Frontdoor di Azure offre i contenuti usando la rete perimetrale globale di Microsoft con centinaia di punti di presenza globali e locali distribuiti in tutto il mondo vicino agli utenti finali aziendali e consumer.
Gestione API di Azure. Gestione API è una soluzione chiavi in mano per la pubblicazione di API per clienti interni ed esterni. Fornisce funzionalità utili per la gestione di un'API pubblica, tra cui la limitazione della frequenza, le restrizioni IP e l'autenticazione usando l'ID Microsoft Entra o altri provider di identità. Gestione API non esegue alcun bilanciamento del carico e dovrà quindi essere usato insieme a un servizio di bilanciamento del carico come il gateway applicazione o un proxy inverso. Per informazioni sull'uso di Gestione API con gateway applicazione, vedere Integrare Gestione API in una rete virtuale interna con gateway applicazione.
Nella scelta di una tecnologia gateway, considerare quanto segue:
Funzionalità. Tutte le opzioni elencate sopra supportano il routing di livello 7, ma il supporto per altre funzionalità può variare. È possibile distribuire più gateway in base alle funzionalità necessarie.
Distribuzione. Il gateway applicazione e Gestione API di Azure sono servizi gestiti. Nginx e HAProxy vengono in genere eseguiti in contenitori all'interno del cluster, ma possono essere anche distribuiti in VM dedicate all'esterno. Questo consente di isolare il gateway dal resto del carico di lavoro, ma determina un maggiore sovraccarico di gestione.
Gestione. Quando vengono aggiornati i servizi o vengono aggiunti nuovi servizi, potrebbe essere necessario aggiornare le regole di routing del gateway. Considerare come verrà gestito questo processo. Considerazioni simili si applicano alla gestione di certificati SSL, elenchi di indirizzi IP consentiti e altri aspetti della configurazione.
Distribuzione di Nginx o HAProxy in Kubernetes
È possibile distribuire Nginx o HAProxy in Kubernetes come ReplicaSet o DaemonSet che specifica l'immagine del contenitore di Nginx o HAProxy. Usare un oggetto ConfigMap per archiviare il file di configurazione per il proxy e montare ConfigMap come volume. Creare un servizio di tipo LoadBalancer per esporre il gateway tramite un'istanza di Azure Load Balancer.
In alternativa, creare un controller di ingresso. Un controller di ingresso è una risorsa Kubernetes che distribuisce un servizio di bilanciamento del carico o un server proxy inverso. Sono disponibili diverse implementazioni, che includono Nginx e HAProxy. Una risorsa separata denominata ingresso definisce le impostazioni per il controller di ingresso, come le regole di routing e i certificati TLS. In questo modo, non è necessario gestire file di configurazione complessi specifici di una determinata tecnologia server proxy.
Dato che il gateway è un potenziale collo di bottiglia o singolo punto di guasto nel sistema, distribuire sempre almeno due repliche per garantire disponibilità elevata. A seconda del carico, potrebbe essere necessario aumentare il numero di istanze delle repliche.
Valutare anche la possibilità di eseguire il gateway in un set di nodi dedicato nel cluster. Questo approccio offre i vantaggi seguenti:
Isolamento. Tutto il traffico in ingresso è indirizzato a un set fisso di nodi, che può essere isolato dai servizi back-end.
Configurazione stabile. Se il gateway non è configurato correttamente, l'intera applicazione non sarà disponibile.
Prestazioni. Per motivi di prestazioni può essere opportuno usare una specifica configurazione di VM per il gateway.
Passaggi successivi
Gli articoli precedenti hanno esaminato le interfacce tra microservizi o tra microservizi e applicazioni client. Per impostazione predefinita, queste interfacce considerano ogni servizio come una scatola opaca. In particolare, i microservizi non devono mai esporre dettagli di implementazione su come gestiscono i dati. Ciò ha implicazioni per l'integrità dei dati e la coerenza dei dati, illustrati nell'articolo successivo.