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.
L'ultima volta abbiamo parlato dei vari tipi di monoliti e dell'uso dei componenti per costruirli, sia dei componenti di assemblaggio che dei componenti di distribuzione. Abbiamo esaminato l'architettura orientata ai servizi.
Ora definiamo finalmente le principali caratteristiche dell'architettura a microservizi.
Relazione tra architetture
È necessario comprendere che, basandosi sui dati contenuti nei precedenti articoli, qualsiasi servizio è un componente, ma non ogni servizio è un microservizio.
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 ingresso intelligenti e tubi stupidi (Smart endpoints and dumb pipes)
- Governance decentralizzata (Decentralized Governance)
- Gestione decentralizzata dei dati (Decentralized Data Management)
- Automazione dell'infrastruttura (Infrastructure Automation)
- Progettazione per il fallimento (Design for failure)
- Architettura con sviluppo evolutivo (Evolutionary Design)
Il primo punto deriva dall'architettura orientata ai servizi, perché i microservizi sono un caso particolare dei servizi. Gli altri punti meritano un'analisi separata.
Organizzazione attorno alle capacità aziendali (Organized around Business Capabilities)
Ora è necessario ricordare la legge di Conway: le organizzazioni che creano sistemi organizzano la loro architettura in maniera che rifletta 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, mentre un team di cinque ha realizzato uno a cinque passaggi.
Se parliamo di monoliti e microservizi, se lo sviluppo è organizzato in base a dipartimenti funzionali (backend, frontend, database administrator), risulta un classico monolite.
Per ottenere microservizi, i team devono essere organizzati attorno alle capacità aziendali (team ordini, spedizioni, catalogo). Tale 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 la funzionalità sviluppata ad altri team nel caso di architettura a microservizi non è affatto adeguato. Il team deve supportare il sistema per tutta la durata del suo ciclo di vita. Amazon, uno dei leader nell'implementazione dei microservizi, ha dichiarato: «costruisci un prodotto e lo avvii tu» («you build, you run it»). L'approccio prodotto consente al team di percepire le esigenze del business.
Punti di ingresso intelligenti e tubi stupidi (Smart endpoints and dumb pipes)
L'architettura SOA ha posto grande attenzione ai canali di comunicazione, in particolare all'Enterprise Service Bus (servizio di bus aziendale). Questo porta spesso a una Erroneous Spaghetti Box, cioè la complessità del monolite si riversa nella complessità delle interazioni tra servizi. Nell'architettura microservizi vengono utilizzati solo metodi semplici di interazione.
Governance decentralizzata (Decentralized Governance)
Le decisioni chiave sui microservizi devono essere prese dalle persone che realmente sviluppano i microservizi. Qui con decisioni chiave si intende la scelta
dei linguaggi di programmazione, della metodologia di distribuzione, dei contratti delle interfacce pubbliche, ecc.
Gestione decentralizzata dei dati (Decentralized Data Management)
L'approccio standard, in cui l'applicazione si basa su un unico database, non può tenere conto delle specificità di ciascun servizio specifico. L'MSA prevede una gestione decentralizzata dei dati, fino all'uso di diverse tecnologie.
Automazione dell'infrastruttura (Infrastructure Automation)
L'MSA supporta i processi di distribuzione e fornitura continua. Questo è possibile solo attraverso l'automazione dei processi. A questo punto, distribuire un gran numero di servizi non sembra più così spaventoso. Il processo di distribuzione deve diventare noioso. Il secondo aspetto è legato alla gestione dei servizi in un ambiente di prodotto. Senza automazione, la gestione dei processi avviati in diversi ambienti operativi diventa impossibile.
Progettazione per il fallimento (Design for failure)
Numerosi servizi MSA sono soggetti a guasti. Tuttavia, 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 nemmeno l'interazione intra-processo tra i servizi; invece, per la comunicazione ci affidiamo all'HTTP, che non è nemmeno lontanamente così affidabile.
Architettura con sviluppo evolutivo (Evolutionary Design)
L'architettura di un sistema MSA deve svilupparsi in modo evolutivo. È preferibile limitare le modifiche necessarie ai confini di un singolo servizio. È necessario considerare anche l'impatto sugli altri servizi. L'approccio tradizionale consiste nel cercare di risolvere questo problema attraverso la gestione delle versioni, ma l'MSA prevede di utilizzare la gestione delle versioni come
ultima risorsa.
Conclusione
Dopo quanto detto, possiamo definire cosa siano i microservizi. L'architettura a microservizi è un approccio allo sviluppo di un'applicazione separata come un insieme di piccoli servizi, ognuno dei quali opera nel proprio processo e interagisce tramite meccanismi leggeri, spesso utilizzando interfacce API HTTP. Questi servizi sono costruiti su opportunità di business e possono essere implementati indipendentemente mediante un meccanismo di
distribuzione completamente automatizzato. Esiste un livello minimo di gestione centralizzata di questi servizi, che possono essere scritti in diversi linguaggi di programmazione e utilizzare varie tecnologie di archiviazione dei dati.
Fonte: habr.com
