Ciao, Habr. In questo momento è aperta in OTUS l'iscrizione a un nuovo ciclo del corso . 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 informativo. In questa serie di articoli, propongo di analizzare gli stili architettonici più popolari per la creazione di applicazioni e rispondere alla domanda su quale stile architettonico sia preferibile in ciascun caso. Durante la mia esposizione cercherò di elaborare una catena logica che spiega l'evoluzione degli stili architettonici dai monoliti ai microservizi.
Un po' di storia
Se provi a chiedere ai programmatori: «A cosa servono i microservizi?», riceverai le risposte più varie. Sentirai che i microservizi migliorano la scalabilità, semplificano la comprensione del codice, aumentano la resilienza, e a volte si può sentire che permettono di «ripulire il codice». Rivolgiamoci alla storia per comprendere quale obiettivo ha guidato l'emergere dei microservizi.
In breve, i microservizi nella nostra attuale comprensione sono emersi in questo modo: nel 2011, James Lewis, analizzando il lavoro di diverse aziende, ha notato l'emergere di un nuovo modello chiamato «micro-app», che ottimizzava il SOA dal punto di vista del rapido dispiegamento dei servizi. Poco dopo, nel 2012, durante un summit architettonico, il modello è stato ribattezzato microservizio. Pertanto, l'obiettivo iniziale dell'implementazione dei microservizi era il miglioramento del time to market.
Nel 2015, i microservizi erano sulla «cresta dell'onda». Secondo alcune ricerche, nessuna conferenza si svolgeva senza una relazione sui microservizi. Inoltre, alcune conferenze erano dedicate esclusivamente ai microservizi. Attualmente, molti progetti iniziano utilizzando questo stile architettonico, e se un progetto contiene tonnellate di codice legacy, è probabile che si stia effettuando una migrazione attiva verso i microservizi.
Nonostante quanto detto, solo un numero relativamente ridotto di sviluppatori riesce a definire il concetto di «microservizio». Ma di questo ne discuteremo più tardi...
Monolite
Lo stile architettonico contrapposto ai microservizi è il monolite (o «tutto in uno»). Spiegare cos'è un monolite probabilmente non ha senso, quindi elencherò subito i difetti di questo stile architettonico che hanno avviato lo sviluppo di altri stili architettonici: dimensioni, coesione, distribuzione, scalabilità, affidabilità e rigidità. Di seguito propongo di esaminare ciascuno di questi difetti separatamente.
Dimensione
Il monolite è molto grande. E, di norma, comunica con un database molto grande. L'applicazione diventa troppo grande perché possa essere compresa da un singolo sviluppatore. Solo coloro che hanno trascorso molto tempo con questo codice possono lavorare bene con un monolite, mentre i neofiti passeranno molto tempo a cercare di capire il monolite senza garanzie di successo. Di solito, quando si lavora con un monolite, c'è sempre un «senior» che conosce il monolite abbastanza bene e tiene a bada per un anno o un anno e mezzo gli altri sviluppatori nuovi. È evidente che tale senior rappresenta un punto di guasto unico e la sua partenza può portare alla morte del monolite.
Coesione
Il monolite è come un «grande groviglio di fango» (big ball of mud), in cui le modifiche possono portare a conseguenze imprevedibili. Apportando modifiche in un luogo, si può danneggiare il monolite in un altro (proprio come nel detto «ho grattato l'orecchio e qualcosa è andato storto»). Questo è dovuto al fatto che i componenti all'interno del monolite hanno relazioni molto complesse e, soprattutto, poco evidenti.
Distribuzione
La distribuzione del monolite, a causa delle complesse relazioni tra i suoi componenti, è un processo lungo con il suo rituale. Questo rituale non è solitamente completamente standardizzato e si trasmette «di bocca in bocca».
Scalabilità
I moduli del monolite possono avere esigenze conflittuali in termini di risorse, il che rende necessario cercare un compromesso dal punto di vista dell'hardware. Immaginate di avere 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 RAM. In questo caso, la macchina su cui viene installato il monolite deve supportare i requisiti di entrambi i servizi, oppure si dovrà disattivare manualmente uno dei servizi.
Un altro esempio (più classico): il servizio A è molto più popolare del servizio B, quindi vuoi che ci siano 100 servizi A e 10 servizi B. Anche in questo caso ci sono due opzioni: o distribuiamo 100 monoliti completi, oppure su alcuni di essi dovremo disattivare manualmente i servizi B.
Affidabilità
Poiché tutti i servizi sono insieme, se il monolite fallisce, tutti i servizi cadono contemporaneamente. In realtà, potrebbe non essere così male, almeno non ci saranno guasti parziali in un sistema distribuito, ma dall'altra parte, a causa di un errore in una funzionalità utilizzata dallo 0,001% degli utenti, potresti perdere tutti gli utenti del tuo sistema.
Rigidità
A causa delle dimensioni del monolite, è difficile passare a nuove tecnologie. Di conseguenza, diventa un compito separate mantenere quello che potremmo definire un senior. Lo stack tecnologico scelto all'inizio del progetto può diventare un blocco che ostacola lo sviluppo del prodotto.
Conclusione
La prossima volta parleremo di come le persone hanno cercato di risolvere i problemi identificati, passando a componenti e SOA.
Leggi anche:
Fonte: habr.com
