Che cosa sono i modelli di progettazione dei microservizi?

Questi modelli di architettura forniscono soluzioni standardizzate per le sfide quotidiane che i team di sviluppo devono affrontare durante l'implementazione di sistemi informatici distribuiti, tra cui comunicazione di servizio, coerenza dei dati, tolleranza ai guasti e scalabilità del sistema.

Molte delle esperienze digitali odierne su cui il mondo fa affidamento sono rese possibili dai modelli di progettazione dei microservizi e possono essere viste in molti casi d'uso. Ad esempio, se stai trasmettendo in streaming un programma su Netflix, stai utilizzando centinaia di servizi separati che collaborano per fornire contenuti, gestire i profili utente e suggerire cosa guardare dopo.

Allo stesso modo, Amazon coordina l'inventario, i pagamenti e le spedizioni tramite servizi distinti. Nel settore finanziario, le banche e altre istituzioni si affidano anche a modelli di progettazione dei microservizi per separare la gestione del rischio e i servizi clienti, mantenendo il denaro sicuro e accessibile.

Secondo il sondaggio IBM, Microservices in the Enterprise, 2021, l'88% delle organizzazioni riferisce che i microservizi offrono svariati benefici ai team di sviluppo, fra cui un aumento del 20-50% nella produttività degli sviluppatori grazie a una migliore organizzazione del codice, una manutenzione più semplice e cicli di implementazione più rapidi.

L'architettura dei microservizi è un metodo nativo del cloud che suddivide le applicazioni in servizi indipendenti e liberamente accoppiati che vengono distribuiti in container gestiti da piattaforme di orchestrazione come Kubernetes.

Ogni servizio opera in modo indipendente con il proprio stack tecnologico, inclusi database dedicati e modelli di gestione dei dati. La comunicazione tra i servizi avviene tramite API REST, piattaforme di event streaming, come Apache Kafka, e broker di messaggi, mentre i team progettano servizi in base a funzionalità con confini chiari chiamati contesti limitati.

Questo approccio moderno allo sviluppo software supporta la flessibilità operativa necessaria per le iniziative moderne di trasformazione digitale, come l'automazione DevOps e le pipeline CI/CD, la migrazione al cloud, la modernizzazione delle applicazioni e l'integrazione dell'intelligenza artificiale (AI).

Mentre i microservizi offrono vantaggi importanti per le applicazioni moderne, capire quando scegliere questa architettura richiede il confronto con gli approcci tradizionali.

Un'architettura monolitica costruisce un'applicazione come un'unica unità distribuibile dove tutte le funzioni aziendali sono integrate e condividono lo stesso codebase, database e ambiente di runtime. L'architettura dei microservizi suddivide un'applicazione in servizi più piccoli e indipendenti che comunicano tramite interfacce di programmazione dell'applicazione (API) ben definite, ognuna con il proprio database e ciclo di implementazione.

La differenza fondamentale tra questi metodi di progettazione è l'accoppiamento, ovvero la tenuta tra le diverse parti del sistema. I monoliti hanno un elevato accoppiamento interno ma sono semplici da implementare, mentre i microservizi hanno un accoppiamento libero tra i servizi ma requisiti di infrastruttura IT più complessi.

Gli ingegneri del software spesso scelgono un'architettura monolitica per applicazioni più piccole e semplici, come per le piccole imprese o le startup che desiderano controllare i costi e accelerare lo sviluppo. In scenari complessi che richiedono elevata scalabilità, resilienza e flessibilità (ad esempio, piattaforme di social media, applicazioni bancarie), i microservizi sono la scelta migliore.

Quando si decide quale approccio adottare, le organizzazioni devono valutare ciascuna in base ai propri requisiti specifici, tra cui le dimensioni del team, la complessità delle applicazioni, le esigenze di scalabilità e i livelli di maturità DevOps.

Scopri di più sull'architettura monolitica e su quella dei microservizi

I modelli di progettazione dei microservizi rientrano in cinque aree chiave che forniscono soluzioni testate che aiutano i team a risolvere le sfide dell'architettura distribuita:

1. Comunicazione e individuazione dei servizi
2. Gestione dei dati e delle transazioni
3. Resilienza e gestione dei guasti
4. Architettura e integrazione
5. Eventi e comunicazione

Modello di registro dei servizi

Il modello di registro dei servizi crea un elenco centrale in cui i servizi registrano i propri endpoint e il loro stato di salute, eliminando la necessità di indirizzi fissi. Quando i servizi hanno bisogno di comunicare, interrogano il registro per trovare le istanze del server disponibili. Per esempio, quando un servizio di pagamento deve contattare un servizio di inventario, controlla il registro per individuare le istanze di inventario sane.

Modello API gateway

Un modello API gateway crea un unico punto di ingresso tra i client e più microservizi di back-end. Invece che obbligare i client a effettuare chiamate separate a servizi diversi, l'API gateway riceve una richiesta, la indirizza ai microservizi appropriati e combina le risposte in un unico risultato.

Ad esempio, quando viene caricata una pagina di prodotto, il gateway può recuperare contemporaneamente i dettagli del prodotto, i prezzi, l'inventario e le recensioni da diversi servizi, per poi restituire tutte queste informazioni in un'unica risposta consolidata al client.

Modello di individuazione dei servizi

Un modello di scoperta dei servizi risolve la sfida della localizzazione reciproca dei servizi in ambienti dinamici. Man mano che i microservizi si espandono o vengono aggiornati a una nuova versione, le loro posizioni di rete cambiano costantemente. I modelli di individuazione dei servizi forniscono meccanismi automatizzati per consentire ai servizi di registrarsi e trovare altri servizi con cui devono comunicare, eliminando la necessità di indirizzi hardcoded.

Modello di database per servizio

Il modello di database per servizio garantisce che ogni microservizio possieda e gestisca il proprio database, eliminando le dipendenze condivise dei dati tra i servizi. Questo approccio impedisce l'accesso diretto ai dati tra i servizi e riduce l'accoppiamento, anche se richiede che i servizi comunichino tramite API quando hanno bisogno di informazioni da altre fonti di informazione. Ad esempio, in un sistema pianificazione delle risorse aziendali, il servizio di contabilità gestisce i dati finanziari indipendentemente dal database dei dipendenti del servizio HR.

Modello a saga

Un modello a saga gestisce le transazioni che coinvolgono più microservizi suddividendole in fasi coordinate. Ogni servizio completa la transazione locale e avvia la fase successiva della catena. Se un passaggio fallisce, il modello esegue automaticamente le azioni necessarie per annullare i passaggi precedenti. Ad esempio, durante l'elaborazione di un ordine online, se il pagamento non va a buon fine dopo la prenotazione dell'inventario, la saga rilascia automaticamente gli articoli riservati.

CQRS (modello di segregazione delle responsabilità della query di comando)

Il modello CQRS separa la modifica dei dati (comandi) dal recupero dei dati (query) utilizzando modelli dedicati per ciascuno. Questa divisione consente al sistema di ottimizzare ogni percorso in modo indipendente, riducendo al minimo i conflitti di scrittura sul lato comando e riducendo la latenza delle query lato lettura. In un sistema di e-commerce, l'operazione di effettuare un ordine utilizza il modello di comando ottimizzato per la scrittura, mentre la generazione di un report sulle vendite sfrutta il modello di query ottimizzato per la lettura.

Modello a interruttore

Il modello a interruttore impedisce che i guasti in un servizio si diffondano nell'intero sistema, monitorando le chiamate ai servizi a valle e interrompendo le richieste quando vengono rilevati i guasti. Quando un servizio non risponde, l'interruttore "scatta" e blocca ulteriori chiamate, proteggendo le risorse di sistema e prevenendo guasti a cascata.

Ad esempio, se un servizio di inventario si interrompe, l'interruttore impedisce al servizio ordini di effettuare ripetute richieste non riuscite. Ciò consente al resto del sistema di continuare a funzionare fornendo risposte di fallback ai client.

Modello a scomparti

Il modello a scomparti isola le risorse di sistema per evitare che i guasti in un'area influiscano sull'intero sistema. Come i compartimenti nello scafo di una nave, le gli scomparti separano le diverse funzioni in modo che, se una si guasta, le altre rimangano operative. Il modello limita il numero di richieste simultanee o di risorse allocate a servizi specifici.

Pattern backend for frontend (BFF)

Un modello backend-for-frontend (BFF) crea un servizio di backend dedicato su misura per ogni specifica interfaccia front-end. Poiché le app hanno requisiti diversi rispetto alle applicazioni web (ad esempio, schermi più piccoli, larghezza di banda limitata, funzionalità variabili), il BFF consente agli sviluppatori di ottimizzare ogni backend per il suo particolare front-end.

Modello di entità e aggregati

Un modello di entità e aggregazione organizza i dati correlati in unità logiche basate su concetti di progettazione basata su dominio (DDD). Un'entità rappresenta un oggetto distinto con un'identità univoca, come un account cliente identificato da un indirizzo e-mail. Un'aggregazione combina entità correlate che devono essere aggiornate insieme come una singola unità.

Ad esempio, in un sistema di e-commerce, un aggregato di ordini può includere i dettagli dell'ordine, le voci e le informazioni di spedizione, che devono rimanere sincronizzati quando si verificano modifiche.

Modello strangler

Un modello strangler aiuta a gestire il processo di refactoring di un'applicazione monolitica in un'architettura di microservizi più gestibile. I nuovi microservizi vengono gradualmente costruiti insieme al monolite esistente, assumendo lentamente il sopravvento sulle funzionalità fino a quando il vecchio sistema non viene sostituito completamente. Il nome deriva dalla metafora di come una vite (microservizi) cresce gradualmente e alla fine strangola un albero (l'applicazione) nel tempo.

Modello basato sugli eventi

Un modello basato sugli eventi consente ai microservizi di comunicare in modo asincrono pubblicando e consumando eventi anziché effettuare chiamate di servizio dirette. Quando un servizio completa un'azione, trasmette un evento che gli altri servizi interessati possono ascoltare e al quale possono rispondere di conseguenza. Questo approccio crea un collegamento libero tra i servizi, consentendo loro di operare in modo indipendente pur coordinando le proprie attività attraverso un sistema di eventi condiviso.

Modello sidecar

Un modello sidecar si riferisce alla distribuzione di un contenitore secondario (il "sidecar") insieme a un'applicazione o servizio principale all'interno dello stesso ambiente di esecuzione. Il sidecar risolve problemi trasversali (ad esempio, registrazione, monitoraggio, sicurezza, Observability), estendendo la funzionalità dell'applicazione principale senza modificarne la base di codice.

Modello di microservizi adapter

Un modello di microservizio adapter consente la comunicazione tra sistemi o interfacce incompatibili. Proprio come un adattatore da viaggio ti consente di collegare il tuo dispositivo a prese elettriche diverse, i modelli adapter vengono convertiti tra diversi formati di dati, protocolli o API. Questo modello è utile quando si integra con sistemi legacy o servizi di terze parti che utilizzano standard di comunicazione diversi.

I modelli di progettazione dei microservizi sono particolarmente utili nei settori che richiedono alta scalabilità, logica aziendale complessa e prestazioni affidabili. I principali casi d'uso includono:

• Le piattaforme di e-commerce, che si basano su modelli di progettazione di microservizi per gestire il bilanciamento del carico durante gli eventi di vendita e gestire inventario complesso su più magazzini. Inoltre coordinano le operazioni di pagamento, spedizione e servizio clienti su diversi sistemi per migliorare i risultati aziendali e migliorare l'esperienza del cliente.
• I servizi di streaming, che utilizzano modelli di microservizi per fornire contenuti a livello globale gestendo al contempo le preferenze e i consigli degli utenti, consentendo loro di gestire enormi carichi simultanei di utenti con buffering minimo ed esperienze personalizzate.
• I servizi finanziari, che implementano questi modelli per separare le operazioni di trading, gestione del rischio, autenticazione e quelle rivolte al cliente, mantenendo al contempo rigorosi standard di conformità normativa e di sicurezza richiesti dagli istituti finanziari.
• I sistemi sanitari, che utilizzano questi modelli per integrare le cartelle cliniche dei pazienti, la pianificazione degli appuntamenti e i sistemi di fatturazione, mantenendo la conformità HIPAA e connettendosi con varie API per dispositivi medici tra diversi fornitori sanitari.
• Le piattaforme di social media, che utilizzano modelli di progettazione di microservizi per scalare la messaggistica, i feed di contenuti e l'elaborazione multimediale in modo indipendente, consentendo loro di gestire miliardi di interazioni con gli utenti ogni giorno mantenendo prestazioni reattive in tutte le caratteristiche.

I modelli di progettazione dei microservizi offrono best practice per la gestione dei complessi sistemi distribuiti odierni e offrono questi benefici di ampia portata:

• Complessità ridotta: approcci standardizzati e testati alle sfide comuni portano a risultati più prevedibili, a una risoluzione dei problemi più semplice e a un più rapido onboarding del team.
• Agilità e time-to-market più rapido: i team possono sviluppare, implementare e scalare i servizi in modo indipendente, riducendo i colli di bottiglia nel coordinamento e accelerando la distribuzione delle funzionalità.
• Maggiore tolleranza ai guasti: le tecniche di isolamento impediscono che i guasti si verifichino a cascata nell'intero sistema, riducendo significativamente i tempi di inattività e migliorando l'affidabilità complessiva del sistema.
• Scalabilità e flessibilità migliorate: le organizzazioni possono allocare le risorse con precisione dove necessario e adattarsi rapidamente ai mutevoli requisiti aziendali senza importanti revisioni del sistema. I team possono sviluppare servizi in diversi linguaggi di programmazione, come Java o Python, in base a esigenze specifiche.
• Efficienza dei costi: la scalabilità mirata e l'ottimizzazione delle risorse, combinate con la capacità di scegliere stack ottimali per servizi specifici, si traducono in risultati più economici.
• Diversità tecnologica: i team possono selezionare gli strumenti e i framework migliori per i requisiti specifici di ogni servizio, portando a soluzioni più efficienti e manutenibili. Ad esempio, puoi selezionare Java Spring Boot per microservizi aziendali per database as a service (DBaaS) o Python per l'analytics.

La selezione dei modelli appropriati dipende dai requisiti specifici del sistema e dalle funzionalità organizzative. L'uso di un approccio sistematico può guidare queste decisioni architettoniche.

Inizia con l'API gateway e la scoperta dei servizi prima di implementare modelli complessi come l'event sourcing o il CQRS. Questi modelli di base stabiliscono l'infrastruttura di comunicazione necessaria per implementazioni più sofisticate.

Considera la tua esperienza con i sistemi distribuiti, la maturità operativa e le pratiche DevOps. I team nuovi ai microservizi inizialmente beneficiano di schemi più semplici, mentre i team esperti possono affrontare modelli di coordinamento più avanzati che richiedono una conoscenza operativa più approfondita.

Ogni modello introduce una complessità che il suo team deve gestire a lungo termine. Il database per servizio richiede strategie di sincronizzazione dei dati. I modelli basati su eventi richiedono un'infrastruttura di broker di messaggi. Assicurati di avere la capacità di supportare i modelli scelti.

Inizia con alcuni servizi utilizzando modelli di base, acquisisci esperienza e poi ampliali man mano che le tue competenze aumentano. Questo approccio incrementale impedisce l'overengineering e consente di apprendere dalle prime implementazioni.