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.
L'ultima volta abbiamo parlato dei diversi tipi di monoliti e dell'uso dei componenti per costruirli, sia componenti di costruzione che componenti di distribuzione. Comprendiamo l'architettura orientata ai servizi.
Ora definiremo finalmente le principali caratteristiche di un'architettura a microservizi.
Rapporto tra architetture
È necessario comprendere che, in base alle definizioni fornite negli articoli precedenti, qualsiasi servizio è un componente, ma non tutti i servizi sono un microservizio.
Caratteristiche dell'architettura a microservizi
Le principali caratteristiche dell’architettura a microservizi sono:
- Organizzato attorno alle capacità aziendali
- Prodotti, non progetti
- Endpoint intelligenti e tubi stupidi
- Governance decentralizzata
- Gestione decentralizzata dei dati
- Automazione delle infrastrutture
- Progettare per il fallimento
- Architettura con sviluppo evolutivo (Evolutionary Design)
Il primo punto deriva dall’architettura orientata ai servizi perché i microservizi sono un caso speciale di servizi. Altri punti meritano una considerazione a parte.
Organizzato attorno alle capacità aziendali
Ora è necessario ricordare la legge di Conway: le organizzazioni che creano sistemi organizzano la propria architettura, copiando la struttura dell'interazione all'interno di queste organizzazioni. Ad esempio, possiamo ricordare il caso della creazione di un compilatore: un team di sette persone ha sviluppato un compilatore a sette passaggi e un team di cinque ha sviluppato un compilatore a cinque passaggi.
Se parliamo di monoliti e microservizi, se lo sviluppo è organizzato da dipartimenti funzionali (backend, frontend, amministratori di database), otteniamo un classico monolite.
Per ottenere i microservizi i team devono essere organizzati per capacità aziendale (ordini, spedizioni, team catalogo). Questa organizzazione consentirà ai team di concentrarsi sulla creazione di parti specifiche dell'applicazione.
Prodotti, non progetti
Un approccio progettuale in cui un team trasferisce le funzionalità sviluppate ad altri team è del tutto inadatto nel caso di un'architettura a microservizi. Il team deve supportare il sistema durante tutto il suo ciclo di vita. Amazon, uno dei leader nell’implementazione dei microservizi, ha affermato: “you build, you run it”. L'approccio al prodotto consente al team di percepire le esigenze dell'azienda.
Endpoint intelligenti e tubi stupidi
L'architettura SOA ha prestato grande attenzione ai canali di comunicazione, in particolare all'Enterprise Service Bus. Il che porta spesso a Erroneous Spaghetti Box, ovvero la complessità del monolite si trasforma nella complessità delle connessioni tra servizi. L'architettura dei microservizi utilizza solo metodi di comunicazione semplici.
Governance decentralizzata
Le decisioni chiave sui microservizi dovrebbero essere prese dalle persone che effettivamente li sviluppano. Qui, le decisioni chiave significano scelte
linguaggi di programmazione, metodologia di implementazione, contratti di interfaccia pubblica, ecc.
Gestione decentralizzata dei dati
L'approccio standard, in cui l'applicazione si basa su un unico database, non può tenere conto delle specificità di ciascun servizio specifico. La MSA prevede una gestione decentralizzata dei dati, compreso l’uso di varie tecnologie.
Automazione delle infrastrutture
MSA supporta processi di distribuzione e distribuzione continui. Ciò può essere ottenuto solo automatizzando i processi. Allo stesso tempo, l’implementazione di un gran numero di servizi non sembra più qualcosa di spaventoso. Il processo di distribuzione dovrebbe diventare noioso. Il secondo aspetto è legato alla gestione del servizio in un ambiente di prodotto. Senza automazione, la gestione dei processi eseguiti in ambienti operativi diversi diventa impossibile.
Progettare per il fallimento
Numerosi servizi MSA sono soggetti a guasti. Allo stesso tempo, la gestione degli errori in un sistema distribuito non è un compito banale. L'architettura dell'applicazione deve essere resistente a tali errori. Rebecca Parsons ritiene molto importante non utilizzare più nemmeno la comunicazione in-process tra i servizi; ricorrere invece a HTTP per la comunicazione, che non è altrettanto affidabile.
Architettura con sviluppo evolutivo (Evolutionary Design)
L'architettura del sistema MSA dovrebbe svilupparsi in modo evolutivo. È consigliabile limitare le modifiche necessarie ai confini di un singolo servizio. Occorre tenere conto anche dell’impatto su altri servizi. L'approccio tradizionale consiste nel provare a risolvere questo problema con il controllo delle versioni, ma MSA suggerisce di utilizzare il controllo delle versioni
come ultima opzione.
conclusione
Dopo tutto quanto sopra, possiamo formulare cosa sono i microservizi. L'architettura dei microservizi è un approccio allo sviluppo di una singola applicazione come raccolta di piccoli servizi, ciascuno in esecuzione nel proprio processo e interagendo attraverso meccanismi leggeri, spesso un'API di risorse HTTP. Questi servizi si basano sulle capacità aziendali e possono essere distribuiti in modo indipendente utilizzando completamente
meccanismo di distribuzione automatizzata. 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