Fate in modo che i microservizi non vadano più "persi": veri e propri frammenti di codice e storie di applicazioni dei gateway API

Hai mai riscontrato una situazione del genere: ci sono sempre più microservizi in azienda, ogni servizio ha la propria interfaccia e indirizzo e chiamarlo è come trovare l'uscita in un labirinto? Per un po', il servizio A deve chiamare i dati di B e per un po' C deve trovare D per verificare le autorizzazioni. Anche solo mantenere queste relazioni telefoniche è un mal di testa. Per non parlare del controllo di sicurezza. Ogni servizio non può avere il proprio set di verifica dell'identità?

Ecco perché dobbiamo parlare di gateway API.

Immagina che se l'architettura dei microservizi sia una festa vivace, il gateway API sia l'addetto alla reception alla porta. È responsabile del controllo della lista degli inviti (verifica dell'identità), della guida degli ospiti nella stanza corretta (richiesta di instradamento), del controllo del ritmo di ingresso (limitazione della corrente) e della registrazione di chi entra e chi esce (monitoraggio del registro). Senza di esso, il partito può facilmente precipitare nel caos.

Che aspetto ha nel codice?

Un semplice esempio di configurazione del routing del gateway

Supponendo che tu stia utilizzando Spring Cloud Gateway (che è abbastanza comune nell'ecosistema Java), una configurazione di routing di base potrebbe assomigliare a questa:

@Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("product_service", r -> r .path("/api/products/**") .filters(f -> f .addRequestHeader("X-Request-Source", "gateway") .circuitBreaker(config -> config .setName("productCB") .setFallbackUri("forward:/fallback/prodotto"))) .uri("lb://PRODUCT-SERVICE")) .route("order_service", r -> r .path("/api/orders/**") .uri("lb://ORDER-SERVICE")) .build(); }

Cosa fa questo codice? Dice al gateway: tutte le richieste che iniziano con /api/products/ vengono inoltrate al servizio denominato PRODUCT-SERVICE. A proposito, viene aggiunta un'intestazione della richiesta e vengono configurati gli interruttori automatici e i downgrade: nel caso in cui il servizio del prodotto non possa rispondere temporaneamente, verrà trasferito al piano di backup. L'instradamento del servizio ordini è più semplice e viene inoltrato direttamente.

Vedete, con poche righe, i chiamanti esterni non hanno bisogno di sapere quanti microservizi ci sono e in quale indirizzo IP vivono. Devono solo guardare verso il gateway.

I vantaggi sono reali

Qualcuno potrebbe chiedersi: l'aggiunta di un livello aggiuntivo renderà il sistema più lento? In effetti, c'è sempre un sovraccarico con un collegamento in più. Ma rispetto ai vantaggi che comporta, spesso ne vale la pena.

Ad esempio, la sicurezza. Invece di implementare ripetutamente la verifica JWT in ciascun servizio, lascia che sia il gateway a gestirla in modo uniforme:

# Un esempio di configurazione di un filtro gateway filtra: - nome: JwtAuthFilter args: secretKey: "your-secret-key-here" escludePaths: - "/api/public/login" - "/health"

Ora, ad eccezione delle due interfacce pubbliche di accesso e controllo dello stato, tutte le altre richieste devono prima superare la verifica del token. Quando desideri modificare le regole di verifica, devi solo cambiare questo luogo.

Un altro esempio è il monitoraggio. Quando tutto il traffico passa attraverso il gateway, improvvisamente hai un punto di osservazione ideale. Quali interfacce vengono chiamate più frequentemente? Qual è il tempo medio di risposta? Ci sono anomalie nel tasso di errore? Questi dati vengono raccolti a livello di gateway, il che è molto più conveniente che andare a ciascun servizio per recuperare i log.

C'è anche la gestione delle versioni. Quando desideri aggiornare l'API di un determinato servizio ma non puoi fare in modo che tutti i chiamanti lo modifichino immediatamente, puoi fare storie nel gateway: indirizzare il traffico a diverse versioni delle istanze del servizio in base al numero di versione nell'intestazione della richiesta. I vecchi utenti continuano a utilizzare la vecchia interfaccia, mentre i nuovi utenti apprezzano le nuove funzionalità e la transizione è fluida.

A cosa prestare attenzione nella scelta?

Esistono molte scelte di gateway API sul mercato. Come scegliere? Non penso che sia necessario perseguire le funzioni più complete. La chiave è se queste cose sono convenienti:

Innanzitutto, la perdita di prestazioni deve rientrare in un intervallo accettabile. Un buon gateway dovrebbe trovare un equilibrio tra funzionalità aggiunte e latenza introdotta. In secondo luogo, la configurazione deve essere sufficientemente flessibile. Come nell'esempio di codice riportato sopra, le regole di routing possono essere definite utilizzando la configurazione o il codice per adattarsi alle abitudini dei diversi team. In terzo luogo, le informazioni di monitoraggio devono essere dettagliate. Quando qualcosa va storto, devi essere in grado di determinare rapidamente se si tratta di un guasto del gateway o di uno dei servizi dietro di esso.

Anche la sua compatibilità con lo stack tecnologico esistente è importante. Se i tuoi microservizi sono scritti principalmente in Go, potrebbe essere più pratico scegliere un gateway che sia Go-friendly e abbia un buon supporto da parte della comunità.

Alcune considerazioni durante la distribuzione effettiva

Parlare sulla carta è in definitiva superficiale. Per usarlo effettivamente, devi pensare ad alcuni dettagli in anticipo.

Ad esempio, cosa dovrei fare se il gateway stesso diventa un singolo punto di errore? Semplice, distribuisci qualche istanza in più e aggiungi il bilanciamento del carico in primo piano. Per un altro esempio, come è possibile aggiornare la configurazione senza riavviare il servizio? Alcuni gateway supportano la configurazione degli aggiornamenti a caldo. La modifica delle regole di routing non richiede il riavvio del processo, il che è molto amichevole per i servizi online.

Anche la registrazione deve essere progettata attentamente. Quali registri deve conservare il gateway? Troppo influenzerà le prestazioni, troppo poco sarà dannoso per la risoluzione dei problemi. Di solito i metadati della richiesta e della risposta (ora, percorso, codice di stato, IP del client) sono necessari, ma per contenuti potenzialmente di grandi dimensioni come il corpo della richiesta, devi scegliere con attenzione, magari registrare solo il corpo della richiesta di un percorso specifico o campionare solo il record.

C'è anche la memorizzazione nella cache. Alcuni risultati delle richieste di query non cambieranno in un breve periodo di tempo e potranno essere memorizzati nella cache a livello gateway e restituiti direttamente per ridurre la pressione sui servizi back-end. Ma quali interfacce sono adatte per la memorizzazione nella cache e per quanto tempo dovrebbero rimanere nella cache dipendono dalle caratteristiche aziendali.

Sii onesto

L’architettura dei microservizi è come un’arma a doppio taglio. La suddivisione in piccoli servizi rende lo sviluppo e l'implementazione più flessibili, ma aumenta anche la complessità della gestione. Il gateway API è come la "reception" di questo sistema complesso. Non gestisce il core business, ma senza di esso sarà difficile che l’intero sistema funzioni correttamente.

Iniziando con poche righe di configurazione del routing e aggiungendo lentamente funzionalità di sicurezza, monitoraggio e limitazione corrente, scoprirai che questo ruolo di "receptionist" sta diventando sempre più importante. Consente ai servizi di backend di fare ciò che sanno fare meglio senza dover affrontare preoccupazioni trasversali.

Questo è ciò che dovrebbe essere un buon strumento: facile da usare, non disordinato e utile nei momenti critici. Probabilmente potrai apprezzarlo quando non dovrai più preoccuparti dei dettagli complicati delle chiamate ai servizi tutto il giorno.

Fondata nel 2005,kpowerè dedicata a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare,kpowerintegra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate.kpowerha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.