Gateway API e proxy inverso

Per gestire l'architettura del microservizio, viene spesso utilizzato insieme a un proxy inverso (come nginx o apache httpd) e per l'implementazione incrociata viene utilizzato il modello di gateway API . A volte il proxy inverso fa il lavoro del gateway API.
Sarà bello vedere chiare differenze tra questi due approcci. Sembra che il potenziale vantaggio dell'utilizzo del gateway API sia il richiamo di più microservizi e l'aggregazione dei risultati. Tutte le altre responsabilità del gateway API possono essere implementate utilizzando Reverse Proxy, ad esempio:

• Autenticazione (può essere eseguita utilizzando gli script LUA nginx);
• Sicurezza dei trasporti. Essa stessa attività proxy inverso;
• Bilancio del carico
• ....

Quindi sulla base di questo ci sono diverse domande:

1. Ha senso utilizzare contemporaneamente il gateway API e il proxy inverso (come richiesta di esempio-> gateway API-> proxy inverso (nginx) -> concrete mictoservice)? In quali casi?
2. Quali sono le altre differenze che possono essere implementate utilizzando il gateway API e non possono essere implementate dal proxy inverso e viceversa?

È più facile pensarci se ti rendi conto che non si escludono a vicenda. Pensa a un gateway API come a un'implementazione del proxy inverso di tipo specifico.

Per quanto riguarda le tue domande, non è raro vedere entrambi usati insieme in cui il gateway API viene trattato come un livello applicazione che si trova dietro un proxy inverso per il bilanciamento del carico e il controllo dello stato. Un esempio potrebbe essere qualcosa di simile a un'architettura sandwich WAF in quanto il tuo Web Application Firewall / API Gateway è integrato da livelli di proxy inverso, uno per il WAF stesso e l'altro per i singoli microservizi con cui parla.

Per quanto riguarda le differenze, sono molto simili. È solo nomenclatura. Man mano che si esegue una configurazione di base del proxy inverso e si inizia a utilizzare più elementi come autenticazione, limitazione della velocità, aggiornamenti dinamici della configurazione e rilevamento dei servizi, è più probabile che le persone lo chiamino gateway API.

Credo che API Gateway sia un proxy inverso che può essere configurato dinamicamente tramite API e potenzialmente tramite interfaccia utente, mentre il proxy inverso tradizionale (come Nginx, HAProxy o Apache) è configurato tramite file di configurazione e deve essere riavviato quando la configurazione cambia. Pertanto, API Gateway dovrebbe essere utilizzato quando le regole di routing o altre configurazioni cambiano spesso. Alle tue domande:

1. Ha senso fintanto che ogni componente in questa sequenza serve al suo scopo.
2. Le differenze non sono nell'elenco delle funzionalità ma nel modo in cui vengono applicate le modifiche alla configurazione.

Inoltre, API Gateway viene spesso fornito sotto forma di SAAS, come Apigee o Tyk, ad esempio.

Inoltre, ecco il mio tutorial su come creare un semplice gateway API con Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Spero che sia d'aiuto.

I gateway API di solito funzionano come un costrutto L7.

I gateway API forniscono funzionalità aggiuntive rispetto a un semplice proxy inverso. Se consideri alcuni dei portali disponibili, possono fornire:

• Gestione completa del ciclo di vita delle API inclusa la documentazione
• un portale che può essere utilizzato come fonte di verità per varie applicazioni client e in cui è possibile fornire governance del cliente, limitazione della velocità ecc.
• instradamento a diverse versioni dell'API comprese le versioni canary / beta
• rilevare modelli di utilizzo, registrare app, recuperare le credenziali del client ecc.

Tuttavia, con l'avvento delle mesh di servizi come Istio, Console molte delle funzionalità dei gateway API saranno incluse nelle mesh.