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.
Nell'ultima parte abbiamo parlato dei vari tipi di monoliti e dell'uso dei componenti per la loro costruzione, sia dei componenti di assemblaggio che di distribuzione. Abbiamo approfondito l'architettura orientata ai servizi.
Adesso definiamo finalmente le principali caratteristiche dell'architettura a microservizi.
Relazione tra architettura
È fondamentale comprendere che, basandosi sui dati degli articoli precedenti, qualsiasi servizio è un componente, ma non tutti i servizi sono microservizi.
Caratteristiche dell'architettura a microservizi
Le principali caratteristiche dell'architettura a microservizi sono:
- Organizzazione attorno alle capacità aziendali (Organized around Business Capabilities)
- Prodotti, non progetti (Products not Projects)
- Punti di accesso intelligenti e canali stupidi (Smart endpoints and dumb pipes)
- Governance decentralizzata (Decentralized Governance)
- Gestione decentralizzata dei dati (Decentralized Data Management)
- Automazione dell'infrastruttura (Infrastructure Automation)
- Progettazione per la resilienza (Design for failure)
- Architettura con evoluzione continua (Evolutionary Design)
Il primo punto deriva dall'architettura orientata ai servizi, poiché i microservizi sono un caso particolare dei servizi. Gli altri punti meritano un'esaminazione a parte.
Organizzazione attorno alle capacità aziendali (Organized around Business Capabilities)
È ora di ricordare la legge di Conway: le organizzazioni che costruiscono sistemi strutturano la loro architettura in modo da rispecchiare la struttura delle interazioni all'interno di queste organizzazioni. Un esempio è la creazione di un compilatore: un team di sette persone ha sviluppato un compilatore a sette passaggi, e un team di cinque ha realizzato uno a cinque passaggi.
Parlando di monoliti e microservizi, se lo sviluppo è organizzato per dipartimenti funzionali (backend, frontend, amministratori di database), si ottiene un classico monolite.
Per ottenere microservizi, i team devono essere organizzati attorno a opportunità di business (team ordini, spedizioni, catalogo). Questa organizzazione consentirà ai team di concentrarsi sulla creazione di parti specifiche dell'applicazione.
Prodotti, non progetti (Products not Projects)
L'approccio progettuale in cui il team trasferisce le funzionalità sviluppate ad altri team in un'architettura a microservizi non è affatto appropriato. Il team deve sostenere il sistema per l'intero ciclo di vita. Amazon, uno dei leader nell'adozione dei microservizi, ha affermato: «crei un prodotto e lo lanci» («you build, you run it»). L'approccio incentrato sul prodotto consente al team di percepire le esigenze del business.
Punti di accesso intelligenti e canali stupidi (Smart endpoints and dumb pipes)
L'architettura SOA prestava molta attenzione ai canali di comunicazione, in particolare all'Enterprise Service Bus. Questo spesso porta a un Erroneous Spaghetti Box, dove la complessità del monolite si trasforma nella complessità delle interazioni tra i servizi. Nell'architettura a microservizi, vengono utilizzati solo metodi semplici di interazione.
Governance decentralizzata (Decentralized Governance)
Le decisioni chiave sui microservizi devono essere prese da coloro che effettivamente sviluppano i microservizi. Qui con decisioni chiave si intendono la scelta
dei linguaggi di programmazione, delle metodologie di distribuzione, dei contratti delle interfacce pubbliche, ecc.
Gestione decentralizzata dei dati (Decentralized Data Management)
L'approccio standard, in cui un'applicazione si basa su un unico database, non può tenere conto delle specificità di ciascun servizio. L'architettura a microservizi (MSA) prevede una gestione decentralizzata dei dati, fino all'uso di diverse tecnologie.
Automazione dell'infrastruttura (Infrastructure Automation)
MSA supporta i processi di distribuzione e consegna continua. Questo è possibile solo mediante l'automazione dei processi. Di conseguenza, il deployment di un gran numero di servizi non appare più un'impresa spaventosa. Il processo di distribuzione deve diventare ordinario. Un secondo aspetto riguarda la gestione dei servizi in un ambiente di produzione. Senza automazione, la gestione dei processi avviati in diversi ambienti operativi diventa impossibile.
Progettazione per la resilienza (Design for failure)
I numerosi servizi di MSA sono soggetti a guasti. In tal caso, la gestione degli errori in un sistema distribuito è un compito tutt'altro che banale. L'architettura delle applicazioni deve essere resistente a tali guasti. Rebecca Parsons ritiene molto importante che non utilizziamo più nemmeno l'interazione intra-processo tra i servizi; per la comunicazione, ricorriamo invece a HTTP, che è lontano dall'essere altrettanto affidabile.
Architettura con evoluzione continua (Evolutionary Design)
L'architettura dei sistemi MSA deve evolversi in modo graduale. È preferibile limitare le modifiche necessarie ai confini di un singolo servizio. È essenziale considerare anche l'impatto sugli altri servizi. L'approccio tradizionale consiste nel tentare di risolvere questo problema tramite la gestione delle versioni, ma MSA prevede di utilizzare la gestione delle versioni come
ultima risorsa.
Conclusione
Dopo quanto detto, possiamo definire cosa sono i microservizi. L'architettura a microservizi è un approccio allo sviluppo di un'applicazione come un insieme di piccoli servizi, ognuno dei quali opera in un proprio processo e interagisce tramite meccanismi semplificati, spesso tramite API HTTP. Questi servizi sono costruiti su opportunità di business e possono essere distribuiti in modo indipendente tramite meccanismi di distribuzione completamente automatizzati.
Esiste un livello minimo di gestione centralizzata di questi servizi, che possono essere scritti in diversi linguaggi di programmazione e utilizzare diverse tecnologie di archiviazione dei dati.
Fonte: habr.com
