Ciao, abru. L'iscrizzione per un novu flussu di cursu hè aperta avà à OTUS . A vigilia di l'iniziu di u corsu, vogliu sparte cun voi u mo articulu originale.
Introduzione
L'scelta di u stilu architettonicu hè una di e decisioni tecniche fundamentali quandu custruisce un sistema d'infurmazione. In questa serie di articuli, pruponu di analizà i stili architecturali più populari per l'applicazioni di custruzzione è risponde à a quistione di quandu quale stile architettonicu hè più preferitu. In u prucessu di presentazione, pruvaraghju à disegnà una catena logica chì spiega u sviluppu di stili architecturali da i monoliti à i microservizii.
Un pocu di storia
Se pruvate à dumandà à i sviluppatori: "Perchè avemu bisognu di microservizi?", uttene una varietà di risposte. Senterete chì i microservizi migliurà a scalabilità, facenu u codice più faciule da capisce, migliurà a tolleranza à i difetti, è qualchì volta si sentenu chì permettenu di "pulizziari u vostru codice". Fighjemu a storia per capisce u scopu daretu à l'emergenza di i microservizi.
In breve, i microservizi in a nostra cunniscenza attuale sò sviluppati cusì: in u 2011, James Lewis, analizendu u travagliu di diverse cumpagnie, hà attiratu l'attenzione à l'emergenza di un novu mudellu "micro-app", chì hà ottimizatu SOA in quantu à accelerà a implementazione di servizii. Un pocu dopu, in u 2012, in una cima di l'architettura, u mudellu hè statu rinominatu microservice. Cusì, l'obiettivu iniziale di l'introduzione di i microservizi era di migliurà u famusu tempu à mercatu.
I microservizi eranu nantu à l'onda di hype in 2015. Sicondu certi studii, micca una sola cunferenza era cumpleta senza un rapportu nantu à u tema di i microservizii. Inoltre, alcune cunferenze sò state dedicate solu à i microservizi. Oghje, parechji prughjetti cumincianu à aduprà stu stilu architettonicu, è se u prughjettu cuntene tunnellate di codice legatu, allora a migrazione à i microservizi hè prubabilmente attivamente realizatu.
Malgradu tuttu ciò chì sopra, un pocu numeru di sviluppatori ponu sempre definisce u cuncettu di "microservice". Ma ne parleremu un pocu dopu...
Monolitu
U stilu architettonicu chì cuntrasta i microservizi hè u monolitu (o all-in-one). Probabilmente ùn hè micca sensu per dì ciò chì hè un monolitu, cusì vi elencu immediatamente i disadvantages di stu stilu architettonicu, chì hà iniziatu u sviluppu ulteriore di stili architecturali: dimensione, cunnessione, implementazione, scalabilità, affidabilità è rigidità. Sottu pruponu di piglià un ochju à ognunu di i difetti per separatamente.
grannizza
U monolitu hè assai grande. È di solitu cumunicà cù una basa di dati assai grande. L'applicazione diventa troppu grande per un sviluppatore per capisce tuttu. Solu quelli chì anu passatu assai tempu à travaglià nantu à stu codice pò travaglià bè cù u monolitu, mentre chì i principianti passanu assai tempu per pruvà à capì u monolitu è ùn ci hè micca una guaranzia chì l'anu da capisce. Di solitu, quandu u travagliu cù un monolitu, ci hè sempre un anzianu "condizionale" chì cunnosce u monolitu più o menu bè è batte e mani di l'altri sviluppatori novi in un annu è mezu. Naturalmente, un tali anzianu cundizionale hè un puntu unicu di fallimentu, è a so partenza pò purtà à a morte di u monolitu.
Cunnessu
U monolitu hè una "grande bola di fangu", cambiamenti chì ponu purtà à cunsequenze imprevisible. Facendu cambiamenti in un locu, pudete dannà u monolitu in un altru (u stessu "avete scratched your ear, *@ falle off"). Questu hè duvuta à u fattu chì i cumpunenti in u monolitu anu assai cumplessu è, più impurtante, relazioni micca evidenti.
Distribuzione
A implementazione di un monolitu, per via di e rilazioni cumplessi trà i so cumpunenti, hè un prucessu longu cù u so propiu rituali. Un tali rituali ùn hè generalmente micca cumplettamente standardizatu è hè trasmessu "oralmente".
Scalabilità
I moduli monoliti ponu avè bisogni cunflitti di risorse, chì necessitanu un cumprumissu per esse fattu in termini di hardware. Imagine chì avete un monolitu custituitu di servizii A è B. U serviziu A hè esigenti nantu à a dimensione di u discu duru, è u serviziu B hè esigenti à RAM. In questu casu, o a macchina nantu à quale hè stallatu u monolitu deve sustene e esigenze di i dui servizii, o duverete disattivà manualmente, artificialmente, unu di i servizii.
Un altru esempiu (più classicu): u serviziu A hè assai più pupulare cà u serviziu B, cusì vulete chì ci sia 100 servizii A, è 10 servizii B. In novu, duie opzioni: o avemu implementatu 100 monoliti cumpleti, o in qualchi allora. i servizii B anu da esse disattivati manualmente.
Affidabilità
Siccomu tutti i servizii sò situati inseme, se u monolitu cade, allora tutti i servizii falanu in una volta. In fatti, questu pò esse micca cusì male, almenu ùn ci sarà micca fallimentu parziale in un sistema distribuitu, ma d'altra parte, per via di un bug in funziunalità chì hè utilizatu da 0.001% di l'utilizatori, pudete perde tutti l'utilizatori. di u vostru sistema.
Inerzia
A causa di a dimensione di u monolitu, hè difficiule di cambià à e tecnulugia novi. In u risultatu, mantene u stessu anzianu hè un compitu separatu. A pila di tecnulugia scelta à l'iniziu di un prughjettu pò diventà un bloccu chì impedisce u sviluppu di u pruduttu.
cunchiusioni
A prossima volta parleremu di cumu a ghjente hà pruvatu à risolve questi prublemi trasfittendu à cumpunenti è SOA.
Leghjite più:
Source: www.habr.com