Ciao, Habr. Proprio ora, OTUS ha aperto le iscrizioni per un nuovo ciclo di corsi. In vista dell'inizio del corso, voglio condividere con voi il mio articolo originale.
Introduzione
La scelta dello stile architettonico è una delle decisioni tecniche fondamentali nella costruzione di un sistema informatico. In questa serie di articoli, propongo di analizzare gli stili architettonici più popolari per la costruzione delle applicazioni e rispondere alla domanda su quale stile architettonico sia il più preferibile in ciascun caso. Nel corso dell'esposizione cercherò di tracciare il filo logico che spiega lo sviluppo degli stili architettonici dai monoliti ai microservizi.
Un po' di storia
Se provate a chiedere agli sviluppatori: «A cosa servono i microservizi?», otterrete risposte molto diverse. Sentirete che i microservizi migliorano la scalabilità, semplificano la comprensione del codice, migliorano la resilienza, a volte si sente dire che permettono di «ripulire il codice». Rivolgiamoci alla storia per capire quale obiettivo ha perseguito l'emergere dei microservizi.
In breve, i microservizi, come li intendiamo oggi, sono emersi nel seguente modo: nel 2011, James Lewis, analizzando il lavoro di diverse aziende, ha notato l'emergere di un nuovo paradigma «micro-app», che ha ottimizzato l'SOA in termini di accelerazione del deployment dei servizi. Poco dopo, nel 2012, durante un summit architettonico, il paradigma è stato rinominato in microservizio. Pertanto, l'obiettivo iniziale dell'implementazione dei microservizi era il miglioramento del famigerato time to market.
Nel 2015, i microservizi erano sulla cresta dell'onda. Secondo alcune ricerche, nessuna conferenza si svolgeva senza una relazione sui microservizi. In effetti, alcune conferenze erano dedicate esclusivamente ai microservizi. Oggi molti progetti iniziano già con questo stile architettonico, e se un progetto contiene tonnellate di codice legacy, è probabile che stia avvenendo una migrazione attiva verso i microservizi.
Nonostante quanto sopra, ancora un numero limitato di sviluppatori riesce a definire il concetto di 'microservizio'. Ma di questo parleremo più avanti...
Monolite
Lo stile architettonico opposto a quello dei microservizi è il monolite (o 'tutto in uno'). Non ha molto senso spiegare cos'è un monolite, quindi procederò immediatamente a elencare gli svantaggi di questo stile architettonico che hanno portato allo sviluppo di stili architettonici alternativi: dimensione, interdipendenza, distribuzione, scalabilità, affidabilità e rigidità. Di seguito, propongo di esaminare ciascuno di questi svantaggi separatamente.
Dimension
Il monolite è molto grande. Comunica generalmente con un'ampia base di dati. L'applicazione diventa così complessa che è difficile da comprendere per un singolo sviluppatore. Solo coloro che hanno trascorso molto tempo a lavorare su questo codice possono gestire bene il monolite, mentre i neofiti possono impiegare molto tempo nel tentativo di capirlo, senza la certezza di riuscirci. Di solito, c'è sempre un 'senior' condizionale che conosce abbastanza bene il monolite e corregge i nuovi sviluppatori per un anno o anche più. Ovviamente, un tale senior rappresenta un singolo punto di fallimento, e la sua partenza può portare alla rovina del monolite.
Coesione
Il monolite è descritto come un 'grande gomitolo di fango' (big ball of mud), e apportare modifiche in esso può avere conseguenze imprevedibili. Cambiando una parte, si potrebbero rovinare altre aree del monolite (si tratta di 'grattarsi un orecchio e far cadere il resto'). Questo è dovuto al fatto che i componenti nel monolite hanno relazioni molto complesse e, soprattutto, non ovvie.
Distribuzione
Il deployment di un monolite, a causa delle complesse interconnessioni tra i suoi componenti, è un processo lungo con il suo rituale. Questo rituale di solito non è standardizzato in modo definitivo e viene trasmesso "da bocca a bocca".
Scalabilità
I moduli del monolite possono avere esigenze di risorse in conflitto, il che richiede di cercare un compromesso in termini di hardware. Immaginate un monolite composto dai servizi A e B. Il servizio A è esigente in termini di spazio su disco, mentre il servizio B lo è in termini di memoria. In questo caso, o la macchina su cui viene installato il monolite deve soddisfare i requisiti di entrambi i servizi, oppure sarà necessario disattivare manualmente uno dei servizi.
Un altro esempio (più classico): il servizio A è molto più popolare del servizio B, quindi volete avere 100 istanze del servizio A e 10 del servizio B. Anche qui ci sono due opzioni: o deployiamo 100 monoliti completi, oppure su alcuni di essi sarà necessario disattivare manualmente i servizi B.
Affidabilità
Poiché tutti i servizi sono integrati, se il monolite fallisce, falliscono tutti i servizi contemporaneamente. In realtà, forse non è così male; almeno non ci saranno guasti parziali in un sistema distribuito. D'altra parte, a causa di un errore in una funzionalità utilizzata dallo 0,001% degli utenti, puoi perdere tutti gli utenti del tuo sistema.
Rigidità
A causa delle dimensioni del monolite, è difficile passare a nuove tecnologie. Di conseguenza, emerge l'esigenza di trattenere quel famoso senior. La stack tecnologica scelta all'inizio del progetto può diventare un ostacolo allo sviluppo del prodotto.
Conclusione
La prossima volta parleremo di come le persone hanno tentato di risolvere i problemi evidenziati passando a componenti e SOA.
Leggi di più:
Fonte: habr.com
