Ciao, Habr. Oggi continuo la serie di pubblicazioni che ho scritto appositamente per l'inizio di un nuovo flusso del corso .
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.
In ci siamo occupati del monolite e abbiamo concluso che presenta una serie di problemi: dimensione, coesione, distribuzione, scalabilità, affidabilità e rigidità.
Questa volta propongo di parlare delle possibilità di organizzare il sistema come un insieme di moduli/librerie (architettura orientata ai componenti) o servizi (architettura orientata ai servizi).
Architettura orientata ai componenti
L'architettura orientata ai componenti implica l'implementazione 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 tiene conto di: idoneità al riutilizzo, sostituibilità, indipendenza dal contesto, estensibilità, incapsulamento e indipendenza.
Un corretto utilizzo dei componenti risolve il problema del "grande granello di sporco" (grande dimensione + alta coesione), e i componenti stessi possono essere sia unità di assemblaggio (moduli, librerie) sia unità di distribuzione (servizi). Le unità di distribuzione non sempre si riflettono nel processo in esecuzione: ad esempio, un'applicazione web e un database vengono distribuiti insieme.
I monoliti sono più comunemente sviluppati come un insieme di moduli. Questo approccio facilita l'indipendenza nello sviluppo, ma persistono problemi di scalabilità e distribuzione indipendente, tolleranza ai guasti e dipendenza dall'insieme tecnologico comune. Ecco perché un modulo è un componente parzialmente indipendente.
Il principale problema di un simile monolite è che la suddivisione in moduli è puramente logica e può essere facilmente violata dagli sviluppatori. Può emergere un modulo core che gradualmente si trasforma in un disastro, possono crescere le dipendenze tra i moduli e così via. Per evitare tali problemi, lo sviluppo deve essere condotto da un team molto esperto o sotto la guida di un "architetto" che si occupa a tempo pieno della revisione del codice e punisce gli sviluppatori che violano la struttura logica.
"Il monolite perfetto" è composto da un insieme di moduli logicamente separati, ciascuno dei quali fa riferimento 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 suoi principi includono: interoperabilità delle applicazioni focalizzate sugli utenti, riutilizzo dei servizi aziendali, indipendenza dalle tecnologie utilizzate e autonomia (evoluzione, scalabilità e distribuzione indipendenti).
L'architettura orientata ai servizi (SOA = service oriented architecture) risolve tutti i problemi indicati del monolite: quando si apportano modifiche, viene interessato solo un servizio e un'API ben definita supporta una buona incapsulazione dei componenti.
Tuttavia, non tutto è così semplice: la SOA porta alla nascita di nuovi problemi. Le chiamate remote sono più costose di quelle locali e la redistribuzione delle responsabilità tra i componenti è diventata significativamente più costosa.
A proposito, la possibilità di un'implementazione indipendente è una caratteristica molto importante del servizio. Se i servizi devono essere implementati insieme o, peggio ancora, in una sequenza specifica, allora il sistema non può essere considerato orientato ai servizi. In tal caso si parla di monolite distribuito (considerato un antipattern non solo in termini di SOA, ma anche di architettura a microservizi).
L'architettura orientata ai servizi è ben supportata dalla comunità architettonica e dai fornitori. Da ciò deriva la presenza di numerosi corsi e certificazioni, con modelli ben sviluppati. Tra questi c'è, per esempio, la conosciutissima Enterprise Service Bus (ESB). Tuttavia, l'ESB è un'eredità dai fornitori e non deve necessariamente essere utilizzata in SOA.
Il picco di popolarità dell'architettura orientata ai servizi è avvenuto intorno al 2008, dopodiché ha cominciato a declinare, e questo declino è diventato molto più marcato dopo l'avvento dei microservizi (circa 2015).
Conclusione
Dopo aver discusso le possibilità di organizzare i sistemi informativi sotto forma di servizi e moduli, propongo finalmente di passare ai principi dell'architettura a microservizi, prestando particolare attenzione alle differenze tra l'architettura a microservizi e quella orientata ai servizi nella prossima parte.
Fonte: habr.com
