Ciao, Habr. Oggi continuo la mia serie di pubblicazioni che ho scritto appositamente per il lancio del nuovo corso. .
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.
In Abbiamo esaminato il monolite e siamo giunti alla conclusione che ha una serie di problemi: dimensioni, coesione, distribuzione, scalabilità, affidabilità e rigidità.
Questa volta propongo di discutere le opportunità di organizzare un sistema come un insieme di moduli/libriere (architettura orientata ai componenti) o servizi (architettura orientata ai servizi).
Architettura orientata ai componenti
L'architettura orientata ai componenti prevede l'esecuzione del sistema come un insieme di componenti, che possono essere utilizzati sia nei progetti attuali che in quelli futuri. Nel suddividere il sistema in componenti, si tengono in considerazione: l'idoneità al riuso, la sostituibilità, l'indipendenza dal contesto, l'espandibilità, l'incapsulamento e l'indipendenza.
Un uso corretto dei componenti risolve il problema della "grande massa di spazzatura" (grande dimensione + alta coesione), mentre i componenti stessi possono rappresentare sia unità di assemblaggio (moduli, librerie) sia unità di distribuzione (servizi). Le unità di distribuzione non si riflettono sempre sul processo esecutivo: ad esempio, un'applicazione web e un database vengono distribuiti insieme.
I monoliti vengono solitamente sviluppati come un insieme di moduli. Questo approccio garantisce l'indipendenza nello sviluppo, ma i problemi di scalabilità e distribuzione indipendenti, di tolleranza ai guasti e di indipendenza dal comune stack tecnologico rimangono. È per questo che un modulo è un componente parzialmente indipendente.
La principale problematica di un simile monolite risiede nel fatto che la divisione in moduli è puramente logica e può essere facilmente violata dagli sviluppatori. Può emergere un modulo core che si trasforma gradualmente in un disastro, può aumentare il grafo delle dipendenze tra i moduli, e così via. Per evitare tali problemi, lo sviluppo deve essere guidato da un team molto maturo o sotto la supervisione di un "architetto" che si occupa a tempo pieno della revisione del codice e che frena gli sviluppatori che violano la struttura logica.
Un «monolite» ideale è costituito da un insieme di moduli logicamente separati, ciascuno dei quali accede al proprio database.
Architettura orientata ai servizi
Se si prevede di organizzare il sistema come un insieme di servizi, si parla di architettura orientata ai servizi. I principi includono: interoperabilità delle applicazioni orientate agli utenti, riutilizzo di servizi aziendali, indipendenza da stack tecnologici e autonomia (evoluzione, scalabilità e distribuzione indipendenti).
L'architettura orientata ai servizi (SOA = service oriented architecture) risolve tutti i problemi corsi del monolite: con le modifiche viene coinvolto solo un servizio e un'API ben definita garantisce una buona incapsulazione dei componenti.
Tuttavia, non è tutto roseo: la SOA porta alla nascita di nuovi problemi. Le chiamate remote costano di più rispetto a quelle locali e la redistribuzione delle responsabilità tra i componenti è diventata notevolmente più costosa.
A proposito, la possibilità di distribuzione indipendente è una caratteristica molto importante del servizio. Se i servizi devono essere distribuiti insieme o, peggio, in una certa sequenza, il sistema non può essere considerato orientato ai servizi. In questo caso si parla di un monolite distribuito (considerato un antipattern non solo secondo la SOA, ma anche secondo l'architettura a microservizi).
L'architettura orientata ai servizi è ben supportata dalla comunità archivistica e dai fornitori. Da ciò deriva la presenza di numerosi corsi e certificazioni, e di pattern ben elaborati. Tra questi c'è, ad esempio, la nota Enterprise Service Bus (ESB). L'ESB, però, è un retaggio dei fornitori e non deve necessariamente essere utilizzato nella SOA.
Il picco di popolarità dell'architettura orientata ai servizi risale circa al 2008, dopodiché ha iniziato a declinare, un declino che è diventato notevolmente più marcato dopo l'emergere dei microservizi (~2015).
Conclusione
Dopo aver discusso sulle possibilità di organizzare i sistemi informativi come servizi e moduli, propongo di passare finalmente ai principi dell'architettura a microservizi e di prestare particolare attenzione alla differenza tra architettura a microservizi e architettura orientata ai servizi nella parte successiva.
Fonte: habr.com
