Introduzione ai microservizi

Last reviewed 2024-06-26 UTC

Questa guida di riferimento è la prima di una serie in quattro parti sulla progettazione, sulla creazione e sull'implementazione dei microservizi. Questa serie descrive i vari di un'architettura di microservizi. La serie include informazioni su i vantaggi e gli svantaggi del pattern dell'architettura di microservizi e applicarla.

  1. Introduzione ai microservizi (questo documento)
  2. Eseguire il refactoring di un monolite in microservizi
  3. Comunicazione tra servizi in una configurazione di microservizi
  4. Tracciamento distribuito in un'applicazione di microservizi

Questa serie è rivolta a sviluppatori e architetti di applicazioni che progettano e implementano la migrazione per eseguire il refactoring di un'applicazione monolitica in un'applicazione di microservizi.

Applicazioni monolitiche

Un'applicazione monolitica è un'applicazione software a un livello in cui diversi moduli sono combinati in un unico programma. Ad esempio, se stai sviluppando un'applicazione di e-commerce, questa dovrebbe avere un'architettura modulare in linea con i principi della programmazione orientata agli oggetti (OOP). Il seguente diagramma mostra un esempio di configurazione di un'applicazione di e-commerce, in cui l'applicazione è composta da vari moduli. In un'applicazione monolitica, i moduli vengono definiti utilizzando una combinazione di costrutti del linguaggio di programmazione (come i pacchetti Java) e elementi di build (come i file JAR Java).

Un'applicazione monolitica utilizza diversi moduli.

Figura 1. Diagramma di un'applicazione di e-commerce monolitica con diversi moduli che utilizzano una combinazione di costrutti del linguaggio di programmazione.

Nella figura 1, diversi moduli dell'applicazione di e-commerce corrispondono logica di business per la gestione di pagamento, consegna e ordini. Tutti questi moduli vengono pacchettizzati e implementati come un singolo file eseguibile logico. Il formato effettivo dipende dal linguaggio e dal framework dell'applicazione. Ad esempio, molte applicazioni Java vengono pacchettizzate come file JAR e implementate su server di applicazioni come Tomcat o Jetty. Analogamente, un'applicazione Rails o Node.js viene pacchettizzata come una gerarchia di directory.

Vantaggi del monolite

L'architettura monolitica è una soluzione convenzionale per la creazione di applicazioni. Di seguito sono riportati alcuni vantaggi dell'adozione di un design monolitico per il tuo applicazione:

  • Puoi implementare i test end-to-end di un'applicazione monolitica utilizzando strumenti come Selenium.
  • Per eseguire il deployment di un'applicazione monolitica, puoi semplicemente copiare l'applicazione pacchettizzata su un server.
  • Tutti i moduli di un'applicazione monolitica condividono memoria, spazio e risorse, quindi puoi utilizzare una singola soluzione per risolvere problemi trasversali come logging, memorizzazione nella cache e sicurezza.
  • L'approccio monolitico può offrire vantaggi in termini di prestazioni, possono chiamarsi direttamente. Al contrario, i microservizi richiedono una chiamata di rete per comunicare tra loro.

Sfide del monolite

I monoliti complessi spesso diventano sempre più difficili da creare, eseguire il debug e ragionare informazioni. A un certo punto, i problemi superano i vantaggi.

  • In genere le applicazioni crescono con il passare del tempo. Può diventare complicato di implementare modifiche in un'applicazione grande e complessa che ha moduli accoppiati. Poiché qualsiasi modifica al codice interessa l'intero sistema, devi coordinare attentamente le modifiche. Il coordinamento dei cambiamenti rende di sviluppo e test molto più a lungo rispetto a un microservizio diverse applicazioni.
  • Può essere complicato ottenere integrazione e deployment continui (CI/CD) con un monolite di grandi dimensioni. Questa complessità è dovuta al fatto che devi eseguire nuovamente il deployment dell'intera applicazione per aggiornarne una parte. Inoltre, è probabile che tu debba eseguire test manuali approfonditi dell'intera applicazione per verificare la presenza di regressioni.
  • Le applicazioni monolitiche possono essere difficili da scalare quando moduli diversi presentano requisiti delle risorse in conflitto. Ad esempio, un modulo potrebbe implementare la logica di elaborazione delle immagini che richiede un'elevata potenza di calcolo della CPU. Un altro modulo potrebbe essere un database in memoria. Poiché questi moduli vengono implementati insieme, devi fare un compromesso sulla scelta dell'hardware.
  • Poiché tutti i moduli vengono eseguiti nello stesso processo, esiste un bug in qualsiasi modulo, come una fuga di memoria, possono potenzialmente danneggiare l'intero sistema.
  • Le applicazioni monolitiche aggiungono complessità quando si vogliono adottare nuove e i linguaggi di programmazione. Ad esempio, è costoso (in termini di tempo e denaro) riscrivere un'intera applicazione per utilizzare un nuovo framework, anche se questo è notevolmente migliore.

Applicazioni basate su microservizi

Un microservizio in genere implementa un insieme di funzionalità o caratteristiche distinte. Ogni microservizio è una mini-applicazione con una propria dell'architettura e della logica di business. Ad esempio, alcuni microservizi espongono un'API impiegata da altri microservizi o dai client dell'applicazione, come le integrazioni di terze parti con gateway di pagamento e logistica.

La Figura 1 mostra un'applicazione di e-commerce monolitica con diversi moduli. La il seguente diagramma mostra una possibile scomposizione dell'applicazione di e-commerce in microservizi:

Un'applicazione monolitica viene scomposta in microservizi.

Figura 2. Diagramma di un'applicazione di e-commerce con aree funzionali implementate da microservizi.

Nella figura 2, un microservizio dedicato implementa ogni area funzionale dell'applicazione di e-commerce. Ciascun servizio di backend potrebbe esporre un'API e servizi e utilizzare le API fornite da altri servizi. Ad esempio, per eseguire il rendering delle pagine web, i servizi UI invocano il servizio di pagamento e altri servizi. I servizi potrebbero anche utilizzare comunicazioni asincrone basate su messaggi. Per ulteriori informazioni su come i servizi comunicano tra loro, consulta il terzo documento di questa serie, Comunicazione tra servizi in una configurazione di microservizi.

Il pattern di architettura di microservizi modifica in modo significativo il rapporto tra l'applicazione e il database. Invece di condividere un singolo database con altri servizi, consigliamo che ogni servizio abbia il proprio database soddisfa al meglio le sue esigenze. Se hai un database per ogni servizio, garantire il basso accoppiamento tra i servizi perché tutte le richieste di dati passano l'API del servizio e non direttamente tramite il database condiviso. Le seguenti mostra un pattern di architettura di microservizi in cui ogni servizio ha il suo tuo database:

Ogni microservizio ha il proprio database.

Figura 3. Ogni servizio in un'architettura di microservizi ha il proprio database.

Nella figura 3, il servizio degli ordini nell'applicazione di e-commerce funziona bene utilizzando un database orientato ai documenti con funzionalità di ricerca in tempo reale. Il metodo di pagamento e di distribuzione dei carichi di lavoro si basano atomicità, coerenza, isolamento, durabilità (ACID) le garanzie di un database relazionale.

Vantaggi dei microservizi

Il pattern di architettura dei microservizi risolve il problema della complessità descritti nei precedenti Sfide Monolith . Un'architettura di microservizi offre i seguenti vantaggi:

  • Sebbene la funzionalità totale rimanga invariata, puoi usare i microservizi suddividere l'applicazione in blocchi o servizi gestibili. Ogni servizio ha un confine ben definito sotto forma di API RPC o basata su messaggi. Pertanto, i singoli servizi possono essere più veloce da sviluppare e più facile da capire e gestire.
  • I team autonomi possono sviluppare in maniera indipendente i singoli servizi. Puoi organizzare i microservizi in base ai confini aziendali, non alle funzionalità tecniche di un prodotto. Organizza i tuoi team in modo che abbiano una singola responsabilità indipendente per l'intero ciclo di vita del software assegnato, dallo sviluppo al test, dal deployment alla manutenzione e al monitoraggio.
  • Il processo di sviluppo dei microservizi indipendenti consente inoltre agli sviluppatori di scrivere ogni microservizio in un linguaggio di programmazione diverso, creando un'applicazione poliglotta. Se utilizzi il linguaggio più efficace per ogni microservizio, puoi sviluppare un'applicazione più rapidamente e ottimizzarla per ridurre la complessità del codice e aumentare le prestazioni e le funzionalità.
  • Quando disaccoppia le funzionalità da un monolite, puoi ottenere che i team indipendenti rilasciano il microservizio in modo indipendente. Indipendente cicli di rilascio e di release può aiutare a migliorare la velocità e il tempo del prodotto mercato.
  • L'architettura di microservizi ti consente inoltre di scalare ciascun servizio in modo indipendente. Puoi eseguire il deployment del numero di istanze di ogni servizio ne soddisfano i vincoli di capacità e disponibilità. Puoi utilizzare anche l'hardware più adatto ai requisiti delle risorse di un servizio. Quando scalare i servizi in modo indipendente, aumenti la disponibilità e l'affidabilità dell'intero sistema.

Di seguito sono riportati alcuni casi specifici in cui può essere utile esegui la migrazione da un monolite a un'architettura di microservizi:

  • Implementazione di miglioramenti in termini di scalabilità, gestibilità, agilità o velocità di implementazione.
  • Riscrivere in modo incrementale una grande applicazione precedente in un linguaggio e uno stack tecnologico moderni per soddisfare le nuove esigenze aziendali.
  • Estrazione di applicazioni aziendali o servizi trasversali in modo da poterli riutilizzare in più canali. Esempi di servizi che è consigliabile riutilizzare includono servizi di pagamento, servizi di accesso servizi di crittografia, servizi di ricerca voli, servizi di profili clienti e di notifica.
  • Adozione di un linguaggio o framework appositamente progettato per una funzionalità specifica di un monolite esistente.

Sfide dei microservizi

Rispetto ai monoliti, i microservizi presentano alcune sfide, tra cui seguenti:

  • Una delle principali sfide dei microservizi è la complessità causata dal fatto che l'applicazione è un sistema distribuito. Gli sviluppatori devono scegliere e implementare un meccanismo di comunicazione tra i servizi. I servizi devono anche gestire errori parziali e l'interruzione del servizio dei servizi a monte.

  • Un'altra sfida dei microservizi è che devi gestire le transazioni su diversi microservizi (chiamate anche transazioni distribuite). Operazioni aziendali che aggiornano più elementi sono abbastanza comuni e di solito vengono applicate in un atomico in cui vengono applicate tutte le operazioni o si verificano errori. Quando racchiudi più operazioni in un'unica transazione di database, atomicità.

    In un'applicazione basata su microservizi, le operazioni aziendali potrebbero essere distribuite su diversi microservizi, quindi devi aggiornare più database di proprietà di servizi diversi. In caso di errore, è fondamentale monitorare l'esito negativo o il successo delle chiamate ai diversi microservizi del rollback. Lo scenario peggiore può comportare un'incoerenza di dati tra i servizi quando non si è verificato il rollback dello stato dovuto a errori in modo corretto. Per informazioni sulle varie metodologie per configurare le transazioni distribuite tra i servizi, consulta il terzo documento di questa serie, Comunicazione tra servizi in una configurazione di microservizi.

  • Il test completo delle applicazioni basate su microservizi complesso rispetto al test di un'applicazione monolitica. Ad esempio, per testare la funzionalità di elaborazione di un ordine in un servizio di e-commerce monolitico, seleziona gli articoli, aggiungili a un carrello e poi effettua il pagamento. Per testare lo stesso flusso in un'architettura basata su microservizi, offre vari servizi, frontend, ordine e pagamento: chiamati a vicenda per completare l'esecuzione del test.

  • Il deployment di un'applicazione basata su microservizi è più complesso rispetto al deployment di un'applicazione monolitica. Un'applicazione basata su microservizi in genere è costituito da molti servizi, ognuno dei quali ha più istanze di runtime. Devi inoltre implementare un meccanismo di Service Discovery che consenta per scoprire le posizioni degli altri servizi di cui ha bisogno comunicare.

  • Un'architettura di microservizi aumenta l'overhead delle operazioni perché e i servizi per i quali monitorare e inviare avvisi. L'architettura di microservizi presenta inoltre più punti di errore a causa dell'aumento dei punti di comunicazione tra servizi. Un'applicazione monolitica potrebbe essere implementata in un piccolo cluster di server delle applicazioni. Un'applicazione basata su microservizi potrebbe avere decine di servizi separati da creare, testare, eseguire e distribuire, potenzialmente in più linguaggi ed ambienti. Tutti questi servizi devono essere raggruppati in cluster per il failover e la resilienza. Produzione di microservizi dell'applicazione richiede un'infrastruttura operativa e di monitoraggio di alta qualità.

  • La suddivisione dei servizi in un'architettura di microservizi consente all'applicazione di eseguire più funzioni contemporaneamente. Tuttavia, poiché i moduli vengono eseguiti come servizi isolati, viene introdotta una latenza nel tempo di risposta a causa delle chiamate di rete tra i servizi.

  • Non tutte le applicazioni sono abbastanza grandi da essere suddivise in microservizi. Inoltre, alcune applicazioni richiedono una stretta integrazione tra i componenti, ad esempio Ad esempio, le applicazioni che devono elaborare flussi rapidi di dati in tempo reale. Eventuali livelli aggiuntivi di comunicazione tra i servizi potrebbero rallentare l'elaborazione in tempo reale. Pensare in anticipo alla comunicazione tra i servizi può fornire informazioni utili per contrassegnare chiaramente i confini dei servizi.

Quando decidi se l'architettura di microservizi è la scelta migliore per la tua applicazione, prendi in considerazione i seguenti punti:

  • Le best practice relative ai microservizi richiedono database per servizio. Quando esegui la modellazione dei dati per la tua applicazione, controlla se i database per servizio sono adatti alla tua applicazione.
  • Quando implementi un'architettura di microservizi, devi eseguire l'instrumentazione e monitorare l'ambiente in modo da poter identificare i colli di bottiglia, rilevare e prevenire gli errori e supportare la diagnostica.
  • In un'architettura di microservizi, ogni servizio ha controlli di accesso distinti. Per garantire la sicurezza, devi proteggere l'accesso a ogni sia all'interno dell'ambiente che da applicazioni esterne, e al consumo delle sue API.
  • La comunicazione sincrona tra i servizi in genere riduce la disponibilità di un'applicazione. Ad esempio, se il servizio di ordini un'applicazione di ecommerce richiama in modo sincrono altri servizi a monte e se se questi servizi non sono disponibili, non è possibile creare un ordine. Pertanto, ti consigliamo di implementare una comunicazione asincrona basata su messaggi.

Quando eseguire la migrazione di un'applicazione monolitica ai microservizi

Se stai già utilizzando un monolite, l'adozione dei microservizi comporta un costo di investimento significativo per il tuo team. Diversi team implementano dei microservizi in modi diversi. Ogni team di ingegneria ha risultati unici per quanto riguarda le dimensioni dei microservizi o il numero di microservizi di cui ha bisogno.

Per determinare se i microservizi sono l'approccio migliore per la tua applicazione, e identificare gli obiettivi commerciali o i punti critici da risolvere. Potrebbero esserci modi più semplici per raggiungere i tuoi obiettivi o risolvere i problemi che hai identificato. Ad esempio, se vuoi aumentare la scalabilità della tua applicazione più velocemente, potresti scoprire che la scalabilità automatica è una soluzione più efficiente. Se riscontri bug in produzione, puoi iniziare implementando i test di unità e l'integrazione continua.

Se ritieni che l'approccio basato su microservizi sia il modo migliore per gli obiettivi, inizia estraendo un servizio dal monolite e svilupperà, testerà e il deployment in produzione. Per ulteriori informazioni, consulta il documento successivo di questa serie, Eseguire il refactoring di un monolite in microservizi. Dopo aver estratto correttamente un servizio e averlo in esecuzione in avviare l'estrazione del servizio successivo e continuare ad apprendere da ogni ciclo di lancio di Android.

Il pattern di architettura dei microservizi suddivide un sistema in un insieme di servizi di cui è possibile eseguire il deployment in modo indipendente. Quando sviluppi un'applicazione monolitica, è necessario coordinare team di grandi dimensioni, il che può causare un rallentamento dello sviluppo del software. Quando implementi un'architettura di microservizi, consenti a team piccoli e autonomi di lavorare in parallelo, il che può accelerare lo sviluppo.

Nel prossimo documento di questa serie, Eseguire il refactoring di un monolito in microservizi, scoprirai varie strategie per eseguire il refactoring di un'applicazione monolitica in microservizi.

Passaggi successivi