microservice

Architettura a Microservizi

Il Pattern dell'architettura microservice  è un'architettura che struttura un'applicazione come una raccolta di servizi liberamente accoppiati, che implementano funzionalità di business. L'architettura dei microservizi consente la consegna / distribuzione continua di applicazioni complesse e di grandi dimensioni. Consente inoltre a un'organizzazione di evolvere il proprio stack tecnologico.

Quando si crea un progetto Web, genralmente, un buon punto di partenza è il modello ad architettura monolitica, che è il pattern tradizionale ed è una buona scelta per molte applicazioni. Tuttavia, presenta numerose limitazioni e problemi quando il progetto previsto deve andare su larga scala, oppure quando si vuole modificare spesso e integrando nuove tecnologie rapidamente, per questa tipologia di applicazioni un modello più idoneo è appunto quello a microservice.

VANTAGGI DEI MICROSERVIZI
Consente la consegna e l'implementazione continue di applicazioni grandi e complesse.
Migliore testabilità: i servizi sono più piccoli e più veloci da testare
Migliore dispiegabilità: i servizi possono essere implementati in modo indipendente.
Ti consente di organizzare lo sforzo di sviluppo su più team. Ogni team è responsabile di uno o più singoli servizi.
Ogni team può sviluppare, distribuire e scalare i propri servizi indipendentemente da tutti gli altri team.
Ogni microservizio è relativamente piccolo.
Più facile da comprendere per uno sviluppatore.Rende gli sviluppatori più produttivi.
L'applicazione si avvia più velocemente, per cui si accelerano le distribuzioni.
Migliore isolamento dei guasti. Ad esempio, se c'è una perdita di memoria in un servizio, solo quel servizio sarà interessato. Gli altri servizi continueranno a gestire le richieste. In confronto, un componente anomalo di un'architettura monolitica può far cadere l'intero sistema.
Elimina qualsiasi impegno a lungo termine per uno stack tecnologico. Quando sviluppi un nuovo servizio puoi scegliere un nuovo stack tecnologico. Allo stesso modo, quando si apportano modifiche importanti a un servizio esistente è possibile riscriverlo utilizzando un nuovo stack tecnologico.

SVANTAGGI DEI MICROSERVIZI
Gli sviluppatori devono affrontare la complessità aggiuntiva della creazione di un sistema distribuito.
Gli strumenti di sviluppo / IDE sono orientati alla creazione di applicazioni monolitiche e non forniscono un supporto esplicito per lo sviluppo di applicazioni distribuite.
Il test è più difficile. Gli sviluppatori devono implementare il meccanismo di comunicazione tra servizi.
Complessità di distribuzione. Nella produzione, vi è anche la complessità operativa dell'implementazione e della gestione di un sistema costituito da molti tipi di servizi diversi. Aumento del consumo di memoria. L'architettura microservice sostituisce N istanze di applicazioni monolitiche con istanze di servizi NxM. Se ogni servizio viene eseguito con la propria macchina virtuale (o equivalente), che di solito è necessario per isolare le istanze, allora c'è un sovraccarico di M volte di più runtime della macchina virtuale. Inoltre, se ogni servizio viene eseguito sulla propria VM (ad esempio, l'istanza EC2), come nel caso di Netflix, il sovraccarico è ancora più elevato.

Problemi
Ci sono molti problemi che devi affrontare.
Quando utilizzare l'architettura microservice? Una sfida con l'utilizzo di questo approccio è decidere quando ha senso utilizzarlo.
Quando sviluppi la prima versione di un'applicazione, spesso non hai i problemi che questo approccio risolve. Inoltre, l'utilizzo di un'architettura elaborata e distribuita rallenterà lo sviluppo. Questo può essere un grosso problema per le startup la cui più grande sfida è spesso il modo di evolvere rapidamente il modello di business e l'applicazione.
L'utilizzo della divisione su asse Y (cioè sulla funzionalità dei servizi) potrebbe rendere molto più difficile l'iterazione rapida. In seguito, tuttavia, quando la sfida è come ridimensionare ed è necessario utilizzare la scomposizione funzionale, le dipendenze intricate potrebbero rendere difficile la decomposizione dell'applicazione monolitica in un insieme di servizi.

Come decomporre l'applicazione in servizi?
Un'altra sfida è decidere come suddividere il sistema in microservizi.
Questa è davvero un'arte, ma ci sono una serie di strategie che possono aiutare:
Decomponi per capacità aziendale e definisce servizi corrispondenti alle capacità aziendali.
Decomponi dal sottodominio di design gestito dal dominio.
Decomponi in base ai servizi responsabili di determinate azioni. Per esempio. un servizio di spedizione responsabile della spedizione degli ordini completi.
Decomponi in base a nomi o risorse definendo un servizio responsabile di tutte le operazioni su entità / risorse di un determinato tipo. per esempio. un servizio account responsabile della gestione degli account utente.
Idealmente, ogni servizio dovrebbe avere solo un piccolo insieme di responsabilità. (Zio) Bob Martin parla della progettazione di classi utilizzando il Principio di Responsabilità Unica (SRP). L'SRP definisce una responsabilità di una classe come una ragione per cambiare e afferma che una classe dovrebbe avere solo una ragione per cambiare. Ha senso applicare l'SRP anche al servizio di progettazione. Un'altra analogia che aiuta nella progettazione del servizio è la progettazione delle utility Unix. Unix fornisce un gran numero di utility come grep, cat e find. Ogni utility fa esattamente una cosa,  e può essere combinata con altre utility usando uno script di shell per eseguire compiti complessi.

Come mantenere la coerenza dei dati?
Per garantire un accoppiamento lento, ogni servizio ha il proprio database. Mantenere la coerenza dei dati tra i servizi è una sfida perché 2 transazioni di commit / distribuzione di fase non sono un'opzione per molte applicazioni. Un'applicazione deve invece utilizzare il modello Saga. Un servizio pubblica un evento quando i suoi dati cambiano. Altri servizi consumano quell'evento e aggiornano i loro dati. Esistono diversi modi per aggiornare in modo affidabile i dati e gli eventi di pubblicazione, inclusi Event Sourcing e Transaction Log Tailing.
Come implementare le query? Un'altra sfida è l'implementazione di query che devono recuperare i dati di proprietà di più servizi. I pattern di composizione e comando della rispondenza delle query (CQRS) dell'API.

Esistono molti modelli correlati al modello dei microservizi. L'architettura monolitica è un'alternativa all'architettura dei microservizi. Gli altri pattern risolvono i problemi che incontrerai quando applichi l'architettura microservice.  

La maggior parte dei siti Web su larga scala come Netflix, Amazon e eBay si sono evoluti da un'architettura monolitica a un'architettura di microservizi. Netflix, che è un servizio di streaming video molto popolare che è responsabile fino al 30% del traffico Internet, ha un'architettura orientata ai servizi su larga scala. Gestiscono oltre un miliardo di chiamate al giorno per le loro API di streaming video da oltre 800 diversi tipi di dispositivi. Ogni chiamata API invia una media di sei chiamate ai servizi di back-end. Amazon.com aveva in origine un'architettura a due livelli. Per scalare hanno migrato verso un'architettura orientata al servizio composta da centinaia di servizi di backend. Diverse applicazioni chiamano questi servizi incluse le applicazioni che implementano il sito Web Amazon.com e l'API del servizio Web.
L'applicazione del sito web Amazon.com chiama 100-150 servizi per ottenere i dati utilizzati per costruire una pagina web.
Cube Scale

Il sito di aste ebay.com si è evoluto da un'architettura monolitica a un'architettura orientata ai servizi. Il livello dell'applicazione è costituito da più applicazioni indipendenti. Ogni applicazione implementa la logica aziendale per un'area di funzione specifica come l'acquisto o la vendita. Ogni applicazione utilizza le suddivisioni dell'asse X(replicare molteplici copie identiche dell’applicazione dietro un bilanciatore del carico) e alcune applicazioni come la ricerca utilizzano le suddivisioni dell'asse Z(dove ciascun server esegue una copia identica del codice con la differenza che ogni server è responsabile per solo un sottoinsieme dei dati). Ebay.com applica anche una combinazione di ridimensionamento in stile X, Y e Z al livello del database. Esistono numerosi altri esempi di aziende che utilizzano l'architettura microservice.