Vuliu scrive un articulu nantu à u tema di l'architettura di u microserviziu per un bellu pezzu, ma duie cose mi fermavanu - più mi sfondava in u tema, più mi paria chì ciò chì cunnoscu hè ovvi, è ciò chì aghju. ùn sapete chì deve esse studiatu è studiatu. Per d 'altra banda, pensu chì ci hè digià qualcosa da discutiri trà un vastu publicu. Allora l'opinioni alternative sò benvenute.
A lege di Conway è a relazione trà l'imprese, l'urganizazione è u sistema d'infurmazione
Una volta mi permetteraghju di citari:
"Ogni urganizazione chì cuncepisce un sistema (in u sensu largu) riceverà un disignu chì a so struttura replica a struttura di e squadre in quella urganizazione".
- Melvyn Conway, 1967
In u mo parè, sta lege hè più prubabile di rilancià à a fattibilità di urganizà un affari, piuttostu cà direttamente à u sistema d'infurmazione. Lasciami spiegà cun un esempiu. Diciamu chì avemu una opportunità di cummerciale abbastanza stabile cù un ciculu di vita di una tale durata chì hè sensu per urganizà una impresa (questu ùn hè micca un typo, ma mi piace assai stu terminu chì aghju arrubatu). Naturalmente, u sistema di supportu di questa attività. currisponderà organizzativamente è processually à questa attività.
Orientazione cummerciale di i sistemi d'infurmazione
Lasciami spiegà cun un esempiu. Diciamu chì ci hè una opportunità di cummerciale per urganizà un affari chì vende pizza. In a versione V1 (chiamemu pre-infurmazione), a cumpagnia era una pizzeria, una cash register è un serviziu di consegna. Sta versione hè stata longa in cundizioni di variabilità ambientale bassa. Allora a versione 2 hè ghjunta à rimpiazzà - più avanzata è capace di utilizà un sistema d'infurmazione in u so core per l'affari cù una architettura monolitica. E quì, in my opinion, ci hè solu una terribile inghjustizia in relazione à i monoliti - l'architettura presunta monolitica ùn currisponde micca à u mudellu di cummerciale di duminiu. Iè, s'ellu era cusì, u sistema ùn puderia micca travaglià in tuttu - in cuntradizioni cù a stessa lege di Conway è u sensu cumunu. No, l'architettura monolitica hè cumplettamente coherente cù u mudellu di cummerciale in questa tappa di u sviluppu di l'affari - I, sicuru, significheghju u stadiu quandu u sistema hè digià creatu è messu in opera. Hè un fattu assolutamente maravigliu chì, indipendentemente da l'approcciu architettonicu, sia a versione di l'architettura orientata à u serviziu 3 sia a versione di l'architettura di microservizi N funzioneranu ugualmente bè. Chì ci hè a cattura ?
Tuttu scorri, tuttu cambia, o sò i microservizi un mezzu per cumbatte a cumplessità ?
Prima di cuntinuà, fighjemu alcune idee sbagliate nantu à l'architettura di microserviziu.
I sustenitori di l'usu di un approcciu di microserviziu spessu sustene chì a rottura di un monolitu in i microservizi simplifica l'approcciu di sviluppu riducendu a basa di codice di i servizii individuali. In u mo parè, sta dichjarazione hè una sciocchezza cumpleta. Seriu, l'interazzione ovvia in un codice monolitu è omogeneu pare cumplicatu? S'ellu era veramente u casu, tutti i prughjetti seranu inizialmente custruiti cum'è microservizi, mentri a pratica mostra chì a migrazione da un monolitu à i microservizii hè assai più cumuni. A cumplessità ùn sparisce micca; si move solu da moduli individuali à interfacce (sia buse di dati, RPC, API, è altri protokolli) è sistemi orchestrating. È questu hè difficiule!
U vantaghju di utilizà una pila heterogenea hè ancu discutibile. Ùn discuteraghju micca chì questu hè ancu pussibule, ma in a realtà raramente accade (Fighjendu avanti - questu duverebbe succede - ma piuttostu com'è una cunsiguenza cà un vantaghju).
Ciclu di vita di u produttu è ciclu di vita di serviziu
Pigliate un altru sguardu à u schema sopra. Ùn hè micca una coincidenza chì aghju nutatu u ciculu di vita decrescente di una versione separata di un affari - in cundizioni muderni, hè l'accelerazione di a transizione di un affari trà e versioni chì hè decisivu per u so successu. U successu di un pruduttu hè determinatu da a rapidità di pruvà l'ipotesi cummerciale in questu. È quì, in my opinion, si trova u vantaghju chjave di l'architettura di microserviziu. Ma andemu in ordine.
Passemu à a prossima tappa in l'evoluzione di i sistemi d'informazione - à l'architettura orientata à u serviziu di SOA. Dunque, à un certu puntu avemu evidenziatu in u nostru pruduttu servizii di longa vita - longa vita in u sensu chì quandu si move trà versioni di un pruduttu, ci hè una chance chì u ciculu di vita di u serviziu serà più longu di u ciculu di vita di a prossima versione di u pruduttu. Saria logicu micca di cambià in tuttu - noi Ciò chì importa hè a rapidità di transizione à a prossima versione. Ma sfurtunatamente, simu custretti à fà cambiamenti custanti à i servizii - è quì tuttu funziona per noi, pratiche DevOps, containerizazione, è cusì - tuttu ciò chì vene in mente. Ma questi ùn sò ancu micca microservizii !
Microservices cum'è un mezzu per cumbatte a cumplessità... gestione di cunfigurazione
È quì pudemu infine passà à u rolu di definizione di i microservizi - questu hè un approcciu chì simplifica a gestione di cunfigurazione di u produttu. In più detail, a funzione di ogni microserviziu descrive esattamente a funzione cummerciale in u pruduttu secondu u mudellu di duminiu - è queste sò cose chì ùn campanu micca in una versione di corta vita, ma in una opportunità di cummerciale di longa durata. È a transizione à a prossima versione di u produttu passa literalmente inosservata - cambiate / aghjunghje un microserviziu, è forse solu u schema di a so interazzione, è di colpu vi truverete in u futuru, lascendu cuncurrenti chianci chì cuntinueghjanu à saltà trà e versioni di u pruduttu. i so monoliti. Avà imaginate chì ci hè un volume abbastanza grande di microservizi cù interfacce predefinite è capacità cummerciale. È venite à custruisce a struttura di u vostru pruduttu da i microservizi pronti - solu per disegnu un diagramma, per esempiu. Felicitazioni - avete una piattaforma - è avà pudete attruverà l'affari per sè stessu. Sogni Sogni.
scuperti
- L'architettura di u sistema deve esse determinata da u ciclu di vita di i so cumpunenti. Se un cumpunente vive in una versione di produttu, ùn ci hè nunda di aumentà a cumplessità di u sistema utilizendu un approcciu di microserviziu.
- L'architettura di u microserviziu deve esse basatu annantu à u mudellu di duminiu - perchè l'opportunità di cummerciale hè u duminiu più longevu
- E pratiche di consegna (prassi DevOps) è l'orchestrazione sò unu di i più impurtanti per l'architettura di microserviziu - perchè l'aumentu di u ritmu di cambiamentu di cumpunenti pone esigenze aumentate nantu à a velocità è a qualità di consegna.
Source: www.habr.com