Ciao, Habr. Oggi continuo una serie di pubblicazioni che ho scritto appositamente per l'inizio di un nuovo filone del corso. .
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.
В ci siamo occupati del monolite e siamo giunti alla conclusione che il monolite presenta una serie di problemi: dimensioni, connettività, implementazione, scalabilità, affidabilità e rigidità.
Questa volta propongo di parlare delle possibilità di organizzare un 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 prevede l'esecuzione di un sistema come un insieme di componenti che possono essere utilizzati sia nei progetti attuali che in quelli futuri. Quando si scompone un sistema in componenti si tiene conto di: la loro riusabilità, la loro sostituibilità, l'indipendenza dal contesto, l'estensibilità, l'incapsulamento e l'indipendenza.
Con un uso corretto dei componenti, il problema della “grande palla di terra” (grandi dimensioni + accoppiamento elevato) viene risolto e i componenti stessi possono essere sia unità di assemblaggio (moduli, librerie) che unità di distribuzione (servizi). Le unità di distribuzione non sono sempre mappate al processo in esecuzione: ad esempio, un'applicazione Web e un database vengono distribuiti insieme.
Molto spesso, i monoliti sono sviluppati come un insieme di moduli. Questo approccio porta allo sviluppo indipendente, ma permangono i problemi di scalabilità e implementazione indipendenti, tolleranza agli errori e indipendenza dallo stack tecnologico complessivo. Ecco perché il modulo è un componente parzialmente indipendente.
Il problema più grande con un simile monolite è che la divisione in moduli è puramente logica e può essere facilmente violata dagli sviluppatori. Potrebbe apparire un modulo principale, che gradualmente si trasforma in una discarica, il grafico delle dipendenze tra i moduli potrebbe crescere e così via. Per evitare tali problemi, lo sviluppo dovrebbe essere effettuato da un team molto maturo o sotto la guida di un "architetto" impegnato nella revisione del codice a tempo pieno e battendo le mani degli sviluppatori che violano la struttura logica.
Il monolite “ideale” è un insieme di moduli logicamente separati, ognuno dei quali esamina il proprio database.
Architettura orientata ai servizi
Se si suppone che il sistema sia organizzato sotto forma di un insieme di servizi, allora parliamo di un'architettura orientata ai servizi. I suoi principi sono l'interoperabilità delle applicazioni incentrate sull'utente, il riutilizzo dei servizi aziendali, l'indipendenza dallo stack tecnologico e l'autonomia (evoluzione, scalabilità e implementazione indipendenti).
L'architettura orientata ai servizi (SOA = architettura orientata ai servizi) risolve tutti i problemi identificati di un monolite: solo un servizio viene interessato quando si verifica una modifica e un'API ben definita supporta un buon incapsulamento dei componenti.
Ma non tutto è così liscio: la SOA crea nuovi problemi. Le chiamate remote sono più costose di quelle locali e la ridistribuzione delle responsabilità tra i componenti è diventata notevolmente più costosa.
A proposito, la possibilità di implementazione indipendente è una caratteristica molto importante del servizio. Se i servizi devono essere distribuiti insieme o, inoltre, in una determinata sequenza, il sistema non può essere considerato orientato ai servizi. In questo caso si parla di un monolite distribuito (considerato un anti-pattern non solo dal punto di vista della SOA, ma anche dal punto di vista dell'architettura dei microservizi).
L'architettura orientata ai servizi è ben supportata dalla comunità dell'architettura e dai fornitori. Ciò implica la presenza di numerosi corsi e certificazioni, modelli ben sviluppati. Tra questi rientra ad esempio il noto Enterprise Service Bus (ESB = Enterprise Service Bus). Allo stesso tempo, l’ESB è un bagaglio dei fornitori; non deve necessariamente essere utilizzato nella SOA.
La popolarità dell'architettura orientata ai servizi ha raggiunto il picco intorno al 2008, dopo di che ha iniziato a declinare, diventando significativamente più drammatico con l'avvento dei microservizi (~2015).
conclusione
Dopo aver discusso le possibilità di organizzare i sistemi informativi sotto forma di servizi e moduli, propongo di passare finalmente ai principi dell'architettura dei microservizi e di prestare particolare attenzione alla differenza tra architettura dei microservizi e architettura orientata ai servizi nella parte successiva.
Fonte: habr.com