Ciao, habr. Le iscrizioni per un nuovo flusso di corsi sono aperte proprio ora su OTUS . Alla vigilia dell'inizio del corso, voglio condividere con voi il mio articolo originale.
Introduzione
La scelta dello stile architettonico è una delle decisioni tecniche fondamentali nella realizzazione di un sistema informativo. In questa serie di articoli, propongo di analizzare gli stili architettonici più popolari per le applicazioni edilizie e di rispondere alla domanda su quando quale stile architettonico è preferibile. Nel processo di presentazione, cercherò di tracciare una catena logica che spieghi lo sviluppo degli stili architettonici dai monoliti ai microservizi.
Un po 'di storia
Se provi a chiedere agli sviluppatori: “Perché abbiamo bisogno dei microservizi?”, otterrai diverse risposte. Sentirai che i microservizi migliorano la scalabilità, rendono il codice più facile da comprendere, migliorano la tolleranza agli errori e, a volte, sentirai che ti consentono di "ripulire il tuo codice". Diamo un'occhiata alla storia per comprendere lo scopo dietro l'emergere dei microservizi.
In breve, i microservizi nella nostra attuale comprensione sono nati come segue: nel 2011, James Lewis, analizzando il lavoro di varie aziende, ha attirato l'attenzione sull'emergere di un nuovo modello di "micro-app", che ha ottimizzato la SOA in termini di accelerazione dell'implementazione di Servizi. Qualche tempo dopo, nel 2012, in occasione di un vertice sull’architettura, il modello è stato ribattezzato microservizio. Pertanto, l’obiettivo iniziale dell’introduzione dei microservizi era migliorare il famigerato time to market.
Nel 2015 i microservizi erano in piena espansione. Secondo alcuni studi nessun convegno era completo senza un resoconto sul tema dei microservizi. Inoltre, alcune conferenze erano dedicate esclusivamente ai microservizi. Al giorno d'oggi, molti progetti iniziano a utilizzare questo stile architettonico e, se il progetto contiene tonnellate di codice legacy, è probabile che la migrazione ai microservizi venga eseguita attivamente.
Nonostante tutto quanto sopra, un numero piuttosto ristretto di sviluppatori è ancora in grado di definire il concetto di “microservizio”. Ma di questo ne parleremo un po’ più tardi…
Monolito
Lo stile architettonico che contrasta i microservizi è il monolite (o all-in-one). Probabilmente non ha senso dire cos'è un monolite, quindi elencherò immediatamente gli svantaggi di questo stile architettonico, che ha avviato l'ulteriore sviluppo degli stili architettonici: dimensioni, connettività, implementazione, scalabilità, affidabilità e rigidità. Di seguito propongo di dare un'occhiata a ciascuna delle carenze separatamente.
dimensione
Il monolite è molto grande. E di solito comunica con un database molto grande. L'applicazione diventa troppo grande per essere compresa da uno sviluppatore. Solo coloro che hanno trascorso molto tempo a lavorare su questo codice possono lavorare bene con il monolite, mentre i principianti passeranno molto tempo cercando di capire il monolite e non vi è alcuna garanzia che lo capiranno. Di solito, quando si lavora con un monolite, c'è sempre qualche senior “condizionato” che conosce il monolite più o meno bene e batte le mani di altri nuovi sviluppatori entro un anno e mezzo. Naturalmente, un anziano così condizionale è un unico punto di fallimento e la sua partenza può portare alla morte del monolite.
Connettività
Il monolite è una “grande palla di fango”, i cui cambiamenti possono portare a conseguenze imprevedibili. Apportando modifiche in un punto, puoi danneggiare il monolite in un altro (lo stesso "ti sei grattato l'orecchio, *@ sei caduto"). Ciò è dovuto al fatto che i componenti del monolite hanno relazioni molto complesse e, soprattutto, non ovvie.
Distribuzione
L'implementazione di un monolite, a causa delle complesse relazioni tra i suoi componenti, è un processo lungo con un proprio rituale. Tale rituale di solito non è completamente standardizzato e viene trasmesso “oralmente”.
scalabilità
I moduli monolitici possono avere esigenze di risorse contrastanti, richiedendo un compromesso in termini di hardware. Immagina di avere un monolite composto dai servizi A e B. Il servizio A richiede dimensioni del disco rigido e il servizio B richiede RAM. In questo caso, o la macchina su cui è installato il monolite deve supportare i requisiti di entrambi i servizi, oppure sarà necessario disabilitare manualmente e artificialmente 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. Ancora una volta, due opzioni: o distribuiamo 100 monoliti a tutti gli effetti, o su alcuni poi i servizi B dovranno essere disabilitati manualmente.
Affidabilità
Poiché tutti i servizi si trovano insieme, se il monolite cade, tutti i servizi cadranno contemporaneamente. In effetti, questo potrebbe non essere così grave, almeno non ci saranno guasti parziali in un sistema distribuito, ma d'altra parte, a causa di un bug nella funzionalità utilizzata dallo 0.001% degli utenti, potresti perdere tutti gli utenti del tuo sistema.
Inerzia
A causa delle dimensioni del monolite, è difficile passare alle nuove tecnologie. Di conseguenza, trattenere lo stesso senior è un compito separato. Lo stack tecnologico scelto all’inizio di un progetto può diventare un blocco che ostacola lo sviluppo del prodotto.
conclusione
La prossima volta parleremo di come le persone hanno cercato di risolvere questi problemi passando ai componenti e alla SOA.
Per saperne di più:
Fonte: habr.com