Architettura dei microservizi - Introduzione

Microservice è una metodologia di sviluppo di applicazioni basata sui servizi. In questa metodologia, le grandi applicazioni saranno suddivise in unità di servizio indipendenti più piccole. Il microservizio è il processo di implementazione dell'architettura SOA (Service-oriented Architecture) dividendo l'intera applicazione come un insieme di servizi interconnessi, dove ogni servizio servirà solo una esigenza aziendale.

Il concetto di diventare micro

In un'architettura orientata ai servizi, interi pacchetti software saranno suddivisi in piccole unità aziendali interconnesse. Ciascuna di queste piccole unità aziendali comunicherà tra loro utilizzando protocolli diversi per fornire al cliente affari di successo. La domanda è: in che modo l'architettura dei microservizi (MSA) differisce dalla SOA? In una parola, SOA è un modello di progettazione e Microservice è una metodologia di implementazione per implementare SOA o possiamo dire che Microservice è un tipo di SOA.

Di seguito sono riportate alcune regole da tenere presenti durante lo sviluppo di un'applicazione orientata ai microservizi.

• Independent - Ogni microservizio dovrebbe essere distribuibile in modo indipendente.

• Coupling - Tutti i microservizi dovrebbero essere liberamente accoppiati tra loro in modo che le modifiche in uno non influiscano sull'altro.

• Business Goal - Ciascuna unità di servizio dell'intera applicazione deve essere la più piccola e in grado di fornire uno specifico obiettivo aziendale.

Consideriamo un esempio di portale di shopping online per comprendere in profondità il microservizio. Ora, suddividiamo l'intero portale di e-commerce in piccole unità aziendali come la gestione degli utenti, la gestione degli ordini, il check-in, la gestione dei pagamenti, la gestione delle consegne, ecc. Un ordine riuscito deve procedere attraverso tutti questi moduli entro un tempo specifico telaio. Di seguito è riportata l'immagine consolidata di diverse unità aziendali associate a un sistema di commercio elettronico.

Ciascuno di questi moduli aziendali dovrebbe avere la propria logica aziendale e le proprie parti interessate. Comunicano con altri software di fornitori di terze parti per alcune esigenze specifiche e anche tra loro. Ad esempio, la gestione degli ordini può comunicare con la gestione degli utenti per ottenere informazioni sugli utenti.

Ora, considerando che stai gestendo un portale di acquisti online con tutte queste unità aziendali menzionate in precedenza, hai bisogno di un'applicazione a livello aziendale composta da diversi livelli come front-end, back-end, database, ecc. Se la tua applicazione non è ridimensionata e completamente sviluppato in un unico file war, verrà chiamato come una tipica applicazione monolitica. Secondo IBM, una tipica applicazione monolitica dovrebbe possedere internamente la seguente struttura del modulo in cui solo un endpoint o un'applicazione sarà responsabile della gestione di tutte le richieste dell'utente.

Nell'immagine sopra, puoi vedere diversi moduli come Database per l'archiviazione di diversi utenti e dati aziendali. Sul front-end, abbiamo un dispositivo diverso in cui di solito rendiamo i dati utente o aziendali da utilizzare. Nel mezzo, abbiamo un pacchetto che può essere un file EAR o WAR distribuibile che accetta la richiesta da parte degli utenti, la elabora con l'aiuto delle risorse e la restituisce agli utenti. Tutto andrà bene fino a quando le aziende non richiederanno modifiche nell'esempio precedente.

Considera i seguenti scenari in cui devi modificare la tua applicazione in base alle esigenze aziendali.

La business unit necessita di alcune modifiche nel modulo "Cerca". Quindi, è necessario modificare l'intero processo di ricerca e ridistribuire l'applicazione. In tal caso, stai ridistribuendo le tue altre unità senza alcuna modifica.

Ora di nuovo la tua business unit necessita di alcune modifiche nel modulo "Check out" per includere l'opzione "wallet". Ora devi cambiare il tuo modulo "Check out" e ridistribuire lo stesso nel server. Nota, stai ridistribuendo i diversi moduli dei tuoi pacchetti software, mentre non abbiamo apportato alcuna modifica. Qui arriva il concetto di architettura orientata ai servizi più specifico per l'architettura Microservice. Possiamo sviluppare la nostra applicazione monolitica in modo tale che ogni singolo modulo del software si comporti come un'unità indipendente, in grado di gestire un singolo compito aziendale in modo indipendente.

Considera il seguente esempio.

Nell'architettura sopra, non stiamo creando alcun file per le orecchie con un servizio end-to-end compatto. Invece, stiamo dividendo diverse parti del software esponendole come un servizio. Qualsiasi parte del software può facilmente comunicare tra loro utilizzando i rispettivi servizi. È così che il microservizio gioca un ruolo importante nelle moderne applicazioni web.

Confrontiamo il nostro esempio di carrello degli acquisti nella riga di microservizio. Possiamo suddividere il nostro carrello degli acquisti nei diversi moduli come "Cerca", "Filtro", "Checkout", "Carrello", "Consiglio", ecc. Se vogliamo creare un portale del carrello, dobbiamo creare il moduli sopra menzionati in modo tale che possano connettersi tra loro per darti una buona esperienza di acquisto 24 ore su 24, 7 giorni su 7.

Vantaggi e svantaggi

Di seguito sono riportati alcuni punti sui vantaggi dell'utilizzo del microservizio invece di utilizzare un'applicazione monolitica.

Vantaggi

• Small in size- Microservices è un'implementazione del modello di progettazione SOA. Si consiglia di mantenere il servizio il più possibile. Fondamentalmente, un servizio non dovrebbe svolgere più di un'attività aziendale, quindi sarà ovviamente di piccole dimensioni e di facile manutenzione rispetto a qualsiasi altra applicazione monolitica.

• Focused- Come accennato in precedenza, ogni microservizio è progettato per fornire solo un'attività aziendale. Durante la progettazione di un microservizio, l'architetto dovrebbe preoccuparsi del punto focale del servizio, che è il suo deliverable. Per definizione, un microservizio dovrebbe essere di natura full stack e dovrebbe essere impegnato a fornire una sola proprietà aziendale.

• Autonomous- Ogni microservizio dovrebbe essere un'unità aziendale autonoma dell'intera applicazione. Pertanto, l'applicazione diventa più liberamente accoppiata, il che aiuta a ridurre i costi di manutenzione.

• Technology heterogeneity- Microservice supporta diverse tecnologie per comunicare tra loro in un'unica business unit, il che aiuta gli sviluppatori a utilizzare la tecnologia corretta nel posto giusto. Implementando un sistema eterogeneo, si può ottenere la massima sicurezza, velocità e un sistema scalabile.

• Resilience- La resilienza è una proprietà dell'isolamento di un'unità software. Il microservizio segue un alto livello di resilienza nella metodologia di costruzione, quindi ogni volta che un'unità fallisce non ha alcun impatto sull'intera azienda. La resilienza è un'altra proprietà che implementa un sistema altamente scalabile e meno accoppiato.

• Ease of deployment- Poiché l'intera applicazione è suddivisa in piccole unità, ogni componente dovrebbe essere di natura stack completa. Tutti possono essere implementati in qualsiasi ambiente molto facilmente con una minore complessità temporale a differenza di altre applicazioni monolitiche dello stesso tipo.

Di seguito sono riportati alcuni punti sugli svantaggi dell'architettura dei microservizi.

Svantaggi

• Distributed system- A causa dell'eterogeneità tecnica, verranno utilizzate tecnologie diverse per sviluppare parti diverse di un microservizio. Per supportare questo grande software distribuito eterogeneo è necessaria una vasta gamma di professionisti qualificati. Pertanto, la distribuzione e l'eterogeneità rappresentano uno svantaggio numero uno dell'utilizzo del microservizio.

• Cost - Il microservizio è costoso, poiché è necessario mantenere uno spazio server diverso per attività aziendali diverse.

• Enterprise readiness- L'architettura dei microservizi può essere considerata come un conglomerato di diverse tecnologie, poiché la tecnologia si evolve giorno per giorno. Pertanto, è abbastanza difficile rendere un'azienda di applicazioni di microservizi pronta per il confronto con il modello di sviluppo software convenzionale.

Microservizio su SOA

La tabella seguente elenca alcune funzionalità di SOA e Microservice, evidenziando l'importanza dell'utilizzo di microservice su SOA.