Introduzione ai microservizi

Last reviewed 2024-06-26 UTC

Questa guida di riferimento è la prima di una serie di quattro parti dedicata alla progettazione, la creazione e il deployment di 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 è destinata a sviluppatori di applicazioni e architetti che progettano e implementare la migrazione per il refactoring di un'applicazione monolitica in una un'applicazione.

Applicazioni monolitiche

Un'applicazione monolitica è un'applicazione software a un solo livello in cui moduli diversi sono combinati in un unico programma. Ad esempio, se stai creando un'applicazione di e-commerce, deve avere una struttura un'architettura in linea con principi di programmazione orientata agli oggetti (OOP). Il seguente diagramma mostra un esempio di configurazione dell'applicazione di e-commerce, in cui è costituita da vari moduli. In un'applicazione monolitica, i moduli vengono definite utilizzando una combinazione di costrutti di linguaggi di programmazione (come Java pacchetti) e artefatti della build (come i file JAR Java).

Un'applicazione monolitica utilizza diversi moduli.

Figura 1. Diagramma di un'applicazione di e-commerce monolitica con diverse utilizzando una combinazione di costrutti di 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 distribuiti come un singolo eseguibile logico. Il formato effettivo dipende dal linguaggio e dal framework dell'applicazione. Ad esempio, molti modelli Java le applicazioni sono pacchettizzate come file JAR e il cui deployment viene eseguito sui server delle applicazioni come Tomcat o Jetty. Analogamente, un'applicazione Rails o Node.js è pacchettizzata come nella gerarchia delle 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 test end-to-end di un'applicazione monolitica con strumenti come Selenio.
  • Per eseguire il deployment di un'applicazione monolitica, puoi semplicemente copiare il file a un server.
  • Tutti i moduli di un'applicazione monolitica condividono memoria, spazio di risorse, così puoi usare un'unica soluzione per affrontare 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 dei 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é ogni modifica al codice influisce sull'intero sistema, devi per coordinare accuratamente i cambiamenti. 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 rieseguire il deployment l'intera applicazione al fine di aggiornarne una qualsiasi parte. Inoltre, è probabile che tu debba eseguire test manuali esaustivi dell'intero per verificare le regressioni.
  • Le applicazioni monolitiche possono essere difficili da scalare quando moduli diversi presentano requisiti delle risorse in conflitto. Ad esempio, un modulo potrebbe implementare una logica di elaborazione delle immagini che richiede un uso intensivo della CPU. Un altro modulo un database in memoria. Poiché il deployment di questi moduli viene eseguito insieme, compromessi 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 (sia nel tempo che denaro) per riscrivere un'intera applicazione in modo da utilizzare un nuovo framework, anche se è notevolmente migliore.

Applicazioni basate su microservizi

Un microservizio in genere implementa un insieme di caratteristiche distinte o funzionalità. Ogni microservizio è una mini-applicazione con una propria dell'architettura e della logica di business. Ad esempio, alcuni microservizi espongono un'API utilizzato da altri microservizi o dai client dell'applicazione, come 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 è scomposta in microservizi.

Figura 2. Diagramma di un'applicazione di e-commerce con le aree funzionali e implementato dai microservizi.

Nella Figura 2, un microservizio dedicato implementa ogni area funzionale del 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 richiamano il servizio di pagamento e altri servizi. I servizi potrebbero anche utilizzano la comunicazione asincrona, basata su messaggi. Per ulteriori informazioni che comunicano tra loro, vedi il terzo documento di questa serie, Comunicazione tra servizi in una configurazione di microservizi.

Il pattern dell'architettura dei microservizi modifica significativamente la relazione tra l'applicazione e il database. Anziché 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. In un'architettura di microservizi, ciascun servizio 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 RPC o di API 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 modo indipendente i singoli servizi. Puoi organizzare i microservizi attorno ai confini aziendali, non in base funzionalità di un prodotto. Organizzi i team per un singolo, per l'intero ciclo di vita dell'articolo assegnato la quantità di software, dallo sviluppo al test, al deployment, alla manutenzione. il monitoraggio.
  • Il processo di sviluppo di microservizi indipendente consente inoltre agli sviluppatori scrivi ogni microservizio in un linguaggio di programmazione diverso, la creazione di un polyglot. Quando utilizzi il linguaggio più efficace per ogni microservizio, puoi sviluppare un'applicazione più rapidamente e ottimizzarla per ridurre complessità del codice e aumentare prestazioni e funzionalità.
  • Quando disaccoppia le funzionalità da un monolite, puoi ottenere che i team indipendenti rilasciano il microservizio in modo indipendente. Indipendente possono aiutarti a migliorare le prestazioni dei tuoi team, la velocità e il tempo del prodotto mercato.
  • L'architettura dei microservizi consente inoltre di scalare ogni 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:

  • Implementare miglioramenti in termini di scalabilità, gestibilità, agilità dei tempi di consegna.
  • Riscrittura incrementale di una grande applicazione legacy in un linguaggio moderno e stack tecnologico 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 potresti voler 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 progettati per uno specifico le funzionalità 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 perché l'applicazione è un sistema distribuito. Gli sviluppatori devono scegliere e implementare un meccanismo di comunicazione tra i servizi. I servizi devono gestire anche guasti parziali e indisponibilità dei servizi upstream.

  • Un altro problema dei microservizi è che devi gestire tra diversi microservizi (chiamato anche transazione distribuita). 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 tra microservizi diversi, quindi devi aggiornare più database di proprietà dei diversi servizi. 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 di creazione transazioni distribuite tra servizi, si veda il terzo documento 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 di elaborazione di un ordine in un servizio di e-commerce monolitico, seleziona gli articoli, aggiungili a un carrello e procedi al 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 il 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 basata su microservizi offre inoltre punti di errore dovuti all'aumento dei point of service-to-service comunicazione. Il deployment di un'applicazione monolitica può avvenire su di un cluster di server delle applicazioni. Un'applicazione basata su microservizi potrebbe avere decine di servizi separati da creare, testare, eseguire il deployment e in più lingue e ambienti. Tutti questi servizi devono essere in cluster per failover e resilienza. Produzione di microservizi dell'applicazione richiede un'infrastruttura operativa e di monitoraggio di alta qualità.

  • La divisione dei servizi in un'architettura di microservizi consente per eseguire più funzioni contemporaneamente. Tuttavia, poiché i moduli vengono eseguiti come servizi isolati, la latenza viene introdotta nella risposta a causa di chiamate di rete tra i servizi.

  • Non tutte le applicazioni sono abbastanza grandi da poter 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 possono rallentare il tempo reale in fase di elaborazione. Pensando alla comunicazione tra i servizi in anticipo può fornire insight utili per contrassegnare chiaramente il servizio confini.

Nel decidere se l'architettura di microservizi è la migliore per la tua applicazione, tieni in considerazione i seguenti punti:

  • Le best practice relative ai microservizi richiedono database per servizio. Quando esegui i dati per la tua applicazione, controlla se i database per servizio si adattano un'applicazione.
  • Quando implementi un'architettura di microservizi, è necessario instrumentare e monitorare l'ambiente in modo da poter identificare i colli di bottiglia, rilevare prevenire guasti e supportare la diagnostica.
  • In un'architettura di microservizi, ogni servizio ha accesso separato i controlli di sicurezza. 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, di implementare la comunicazione asincrona, basata su messaggi.

Quando eseguire la migrazione di un'applicazione monolitica ai microservizi

Se esegui già correttamente un monolite, l'adozione di microservizi è di investimento significativo per il tuo team. Diversi team implementano dei microservizi in modi diversi. Ogni team di tecnici ha a ottenere risultati per quanto sono piccoli i microservizi o quanti microservizi necessaria.

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 possono aiutarti a raggiungere i tuoi obiettivi o risolvere i problemi identificati. Ad esempio, se vuoi fare lo scale up della tua applicazione più velocemente, potresti che la scalabilità automatica è una soluzione più efficiente. Se noti bug in di produzione, puoi iniziare implementando i test delle unità e l'integrazione continua (CI).

Se ritieni che l'approccio basato su microservizi sia il modo migliore per gli obiettivi, inizia estraendo un servizio dal monolite e sviluppa, test il deployment in produzione. Per ulteriori informazioni, consulta il prossimo documento serie, Esegui 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 di microservizi scompone un sistema in un insieme 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 l'implementazione di funzionalità di lavorare in parallelo, il che può accelerare il tuo sviluppo.

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

Passaggi successivi