Salut à tutti ! Avemu una grande nutizia, OTUS lancia di novu u corsu in ghjugnu , in cunnessione cù quale avemu tradiziunale sparte materiale utile cun voi.
Sè vo avete scontru tuttu stu microserviziu cosa senza alcun cuntestu, vi sarà pardunatu per pensà chì hè un pocu stranu. Splitting una applicazione in frammenti cunnessi da una rete significa necessariamente aghjunghje modi cumplessi di tolleranza di difetti à u sistema distribuitu risultatu.
Ancu s'ellu stu approcciu implica a scumparsa in parechji servizii indipendenti, l'obiettivu finale hè assai più cà solu chì i servizii funzionanu in diverse macchine. Parlemu quì di l'interazzione cù u mondu esternu, chì hè ancu distribuitu in a so essenza. Micca in u sensu tecnicu, ma piuttostu in u sensu di un ecosistema chì hè custituitu di parechje persone, squadre, prugrammi, è ognuna di queste parti hà bisognu di fà u so travagliu.
L'imprese, per esempiu, sò una cullizzioni di sistemi distribuiti chì cuntribuiscenu cullettivamente à a realizazione di qualchì scopu. Avemu ignoratu stu fattu per decennii, pruvendu à ottene l'unificazione per i fugliali FTP o utilizendu strumenti d'integrazione di l'impresa mentre ci focalizemu nantu à i nostri scopi isolati. Ma cù l'avventu di servizii, tuttu hà cambiatu. I servizii ci anu aiutatu à guardà oltre l'orizzonte è vede un mondu di prugrammi interdependenti chì travaglianu inseme. In ogni casu, per travaglià bè, hè necessariu di ricunnosce è cuncepisce dui mondi fundamentalmente diffirenti: u mondu esternu, induve vivemu in un ecosistema di parechji altri servizii, è u nostru mondu persunale, internu, induve guvernemu solu.
Stu mondu distribuitu hè sfarente di quellu chì avemu crisciutu è sò abituati. I principii di a custruzzione di l'architettura monolitica tradiziunale ùn resistanu micca à a critica. Dunque, ottene questi sistemi ghjustu hè più di creà un diagramma di lavagna bianca fresca o una prova di cuncettu cool. U puntu hè di assicurà chì un tali sistema opera cù successu per un longu periodu di tempu. Fortunatamente, i servizii sò stati intornu per un bellu pezzu, ancu s'ellu parenu diffirenti. sò sempre pertinenti, ancu staghjunati cù Docker, Kubernetes è barbe hipster leggermente squallide.
Allora oghje avemu da fighjulà cumu e regule sò cambiate, perchè avemu bisognu di ripensà a manera di avvicinà i servizii è i dati chì si passanu l'un à l'altru, è perchè avemu bisognu di strumenti completamente differenti per fà.
L'incapsulazione ùn serà micca sempre u vostru amicu
I microservizi ponu operare indipindentamente l'un l'altru. Hè sta pruprietà chì li dà u più grande valore. Sta stessa pruprietà permette à i servizii di scala è di crescita. Micca tantu in u sensu di scaling à quadrillioni d'utilizatori o petabytes di dati (ancu se quelli chì ponu aiutà ancu quì), ma in u sensu di scaling in termini di persone cum'è squadre è urganisazione crescenu continuamente.
Tuttavia, l'indipendenza hè una spada à doppiu tagliu. Questu hè, u serviziu stessu pò eseguisce facilmente è naturali. Ma se una funzione hè implementata in un serviziu chì richiede l'usu di un altru serviziu, allora avemu da fà cambiamenti à i dui servizii quasi simultaneamente. In un monolitu, questu hè faciule fà, fate solu un cambiamentu è mandate à liberà, ma in u casu di sincronizazione di servizii indipendenti, ci saranu più prublemi. A coordinazione trà e squadre è i cicli di liberazione distrugge l'agilità.
Cum'è parte di l'approcciu standard, solu pruvate d'evità cambiamenti fastidiosi da a fine à a fine, dividendu chjaramente a funziunalità trà i servizii. U serviziu di sign-on unicu pò esse un bon esempiu quì. Hà un rolu chjaramente definitu chì u distingue da altri servizii. Questa separazione chjara significa chì in un mondu di richieste chì cambianu rapidamente nantu à i servizii intornu, u serviziu di sign-on unicu hè improbabile di cambià. Esisti in un cuntestu strettamente limitatu.
U prublema hè chì in u mondu reale, i servizii di l'imprese ùn ponu micca mantene a stessa separazione pura di roli tuttu u tempu. Per esempiu, i stessi servizii di l'affari travaglianu in una misura più grande cù dati chì venenu da altri servizii simili. Sè site implicatu in vendita in linea, u flussu di l'ordine di trasfurmazioni, u catalogu di u produttu o l'infurmazioni d'utilizatori diventeranu un requisitu per parechji di i vostri servizii. Ognunu di i servizii avarà bisognu di accessu à sta dati per operare.
A maiò parte di i servizii di cummerciale sparte u stessu flussu di dati, cusì u so travagliu hè invariabilmente intrecciatu.
Cusì venemu à un puntu impurtante chì vale a pena parlà. Mentre i servizii funzionanu bè per i cumpunenti di l'infrastruttura chì operanu largamente in isolazione, a maiò parte di i servizii di l'imprese finiscinu per esse intrecciati assai più strettamente.
Dicotomia di dati
Approcci orientati à u serviziu pò esse digià, ma mancanu ancu insight in quantu à sparte grandi quantità di dati trà i servizii.
U prublema principali hè chì i dati è i servizii sò inseparabili. Per una banda, l'incapsulazione ci incuraghjenu à ammuccià e dati in modu chì i servizii ponu esse separati l'una di l'altru è facilità a so crescita è più cambiamenti. Per d 'altra banda, avemu bisognu di pudè sparte liberamente è cunquistà e dati spartuti, cum'è qualsiasi altri dati. U puntu hè di pudè cumincià à travaglià immediatamente, cum'è liberamente cum'è in qualsiasi altru sistema d'infurmazione.
In ogni casu, i sistemi d'infurmazione anu pocu à fà cù l'encapsulazione. In fatti, hè tuttu u cuntrariu. E basa di dati facenu tuttu ciò chì ponu per furnisce l'accessu à e dati chì almacenanu. Venenu cù una interfaccia dichjarazione putente chì permette di mudificà i dati cum'è avete bisognu. Tali funziunalità hè impurtante in u stadiu di ricerca preliminare, ma micca per gestisce a cumplessità crescente di un serviziu in constante evoluzione.
È quì nasce un dilema. Cuntradizzione. Dicotomia. Dopu tuttu, i sistemi d'infurmazione sò di furnisce dati, è i servizii sò di ammuccià.
Sti dui forzi sò fundamentali. Sostenenu gran parte di u nostru travagliu, luttendu constantemente per l'eccellenza in i sistemi chì custruemu.
Quandu i sistemi di serviziu crescenu è evoluzione, vedemu e cunsequenze di a dicotomia di dati in parechje manere. O l'interfaccia di serviziu crescerà, furnisce una gamma sempre più crescente di funziunalità è cumencia à guardà cum'è una basa di dati casalinga assai fantasiosa, o diventeremu frustrati è implementeremu un modu per ricuperà o spustà in massa setti interi di dati da u serviziu à u serviziu.
A so volta, a creazione di qualcosa chì s'assumiglia à una basa di dati di casa di fantasia porta à una mansa di prublemi. Ùn andemu micca in dettagli nantu à perchè hè periculosu basa di dati spartutu, Dicemu solu chì rapprisenta una ingegneria costosa è operativa significativa per a cumpagnia chì prova à aduprà.
U peghju hè chì i volumi di dati ingrandiscenu i prublemi di frontiere di serviziu. U più dati spartuti si trovanu in un serviziu, u più cumplessu l'interfaccia diventerà è più difficiuli di cumminà i setti di dati chì venenu da diversi servizii.
L'approcciu alternativu di estrazione è di trasfurmà insemi interi di dati hà ancu i so prublemi. Un accostu cumunu à sta quistione s'assumiglia solu à ricuperà è almacenà l'inseme di dati sanu, è poi l'almacenà in u locu in ogni serviziu di cunsumazione.
U prublema hè chì i diversi servizii interpretanu i dati chì cunsumanu in modu diversu. Sta dati hè sempre in manu. Sò mudificati è trasfurmati in u locu. Abbastanza rapidamente cessanu di avè qualcosa in cumunu cù e dati in a fonte.
A più mutabile e copie, più i dati varieranu cù u tempu.
Per aggravà e cose, tali dati sò difficiuli di correggerà in retrospettiva ( Questu hè induve pò veramente vene in salvezza). In fattu, alcuni di i prublemi di tecnulugia intrattabile chì l'imprese affruntà nascenu da i dati disparati chì si multiplica da l'applicazione à l'applicazione.
Per truvà una suluzione à stu prublema, avemu bisognu di pensà in modu diversu nantu à i dati spartuti. Anu devenu esse oggetti di prima classe in l'architetture chì custruemu. chjama tali dati "esterni", è questu hè una funzione assai impurtante. Avemu bisognu di l'incapsulazione per ùn esse micca espunutu u funziunamentu internu di un serviziu, ma avemu bisognu di facilità per i servizii per accede à e dati spartuti per pudè fà u so travagliu currettamente.
U prublema hè chì nè l'approcciu hè pertinenti oghje, postu chì nè l'interfaccia di serviziu, nè a messageria, nè a Database Shared offre una bona suluzione per travaglià cù dati esterni. L'interfacce di serviziu sò pocu adattate per u scambiu di dati à ogni scala. A messageria move i dati ma ùn guarda micca a so storia, cusì i dati diventanu currutti cù u tempu. E basa di dati spartuti si concentranu troppu nantu à un puntu, chì frena u prugressu. Semu inevitabilmente bloccati in un ciculu di fallimentu di dati:
Ciclu di fallimentu di dati
Streams: un accostu descentralizatu di dati è servizii
Ideale, avemu bisognu di cambià a manera chì i servizii travaglianu cù dati spartuti. À questu puntu, ogni avvicinamentu face a dicotomia citata, cum'è ùn ci hè micca una polvera magica chì pò esse sprinkled nantu à ellu per fà sparisce. Tuttavia, pudemu ripensà u prublema è ghjunghje à un cumprumissu.
Stu cumprumissu implica un certu gradu di centralizazione. Pudemu aduprà u mecanismu di log distribuitu perchè furnisce flussi affidabili è scalabili. Avemu avà vulete servizii à esse in gradu di unisce è upirari nant'à issi fili spartuti, ma vulemu evitari cumplessu centralizati Diu Services chì fà stu prucessu. Dunque, a megliu opzione hè di custruisce u processu di flussu in ogni serviziu di u cunsumadore. In questu modu, i servizii seranu capaci di cumminà setti di dati da diverse fonti è travaglià cun elli in a manera chì anu bisognu.
Una manera di ottene stu approcciu hè attraversu l'usu di una piattaforma streaming. Ci hè parechje scelte, ma oghje avemu da circà à Kafka, postu chì l'usu di u so Stateful Stream Processing ci permette di risolve in modu efficace u prublema presentatu.
Utilizà un mecanismu di logging distribuitu ci permette di seguità u percorsu ben battutu è aduprà messageria per travaglià . Stu approcciu hè cunsideratu per furnisce una scala è una particionazione megliu cà u mecanismu di dumanda-risposta perchè dà u cuntrollu di u flussu à u receptore invece di u mittente. Tuttavia, per tuttu in questa vita avete da pagà, è quì avete bisognu di un broker. Ma per i grandi sistemi, u scambiu vale a pena (chì pò esse micca u casu per a vostra applicazione web media).
Se un broker hè rispunsevuli di logging distribuitu piuttostu cà un sistema di messageria tradiziunale, pudete prufittà di funzioni supplementari. U trasportu pò scala linealemente quasi cum'è un sistema di schedari distribuitu. I dati ponu esse guardati in logs per un bellu pezzu, cusì avemu micca solu u scambiu di messagi, ma ancu u almacenamentu di l'infurmazioni. Almacenamiento scalabile senza a paura di un statu spartutu mutabile.
Pudete tandu aduprà u processu di flussu stateful per aghjunghje strumenti di basa di dati dichjarativi à i servizii di cunsumazione. Questa hè una idea assai impurtante. Mentre i dati sò guardati in flussi spartuti chì tutti i servizii ponu accede, l'agregazione è u processu chì u serviziu faci hè privatu. Si trovanu isolati in un cuntestu strettamente limitatu.
Eliminate a dicotomia di dati sepandu u flussu di statu immutable. Allora aghjunghje sta funziunalità à ogni serviziu usendu Stateful Stream Processing.
Cusì, se u vostru serviziu hà bisognu di travaglià cù ordini, un catalogu di prudutti, un magazzinu, avarà un accessu sanu: solu decide quale dati cumminà, induve processà è cumu si deve cambià cù u tempu. Malgradu u fattu chì i dati sò spartuti, u travagliu cun ellu hè cumplettamente decentralizatu. Hè pruduciutu in ogni serviziu, in un mondu induve tuttu va secondu e vostre regule.
Sparte dati senza compromette a so integrità. Incapsulate a funzione, micca a fonte, in ogni serviziu chì hà bisognu.
Succece chì e dati deve esse spustatu in massa. A volte un serviziu richiede un dataset storicu lucale in u mutore di basa di dati sceltu. U truccu hè chì pudete guarantisci chì, se ne necessariu, una copia pò esse restaurata da a fonte accede à u mecanismu di logging distribuitu. Connettori in Kafka facenu un grande travagliu di questu.
Dunque, l'approcciu discututu oghje hà parechji vantaghji:
- I dati sò usati in forma di flussi cumuni, chì ponu esse guardati in logs per un bellu pezzu, è u mecanismu per travaglià cù dati cumuni hè hardwired in ogni cuntestu individuale, chì permette à i servizii di travaglià facilmente è rapidamente. In questu modu, a dicotomia di e dati pò esse equilibrata.
- Dati chì venenu da diversi servizii ponu esse facilmente cumminati in setti. Questu simplifica l'interazzione cù e dati spartuti è elimina a necessità di mantene e datasets lucali in a basa di dati.
- Stateful Stream Processing solu cache data, è a fonte di a verità ferma i logs generale, cusì u prublema di corruzzione di dati in u tempu ùn hè micca cusì acutu.
- In u so core, i servizii sò guidati da dati, vale à dì chì, malgradu i volumi sempre crescente di dati, i servizii ponu sempre risponde rapidamente à l'avvenimenti cummerciale.
- I prublemi di scalabilità cascanu nantu à u broker, micca i servizii. Questu reduce significativamente a cumplessità di i servizii di scrittura, postu chì ùn ci hè bisognu di pensà à a scalabilità.
- L'aghjunzione di novi servizii ùn hè micca bisognu di cambià i vechji, cusì cunnetta novi servizii diventa più faciule.
Comu pudete vede, questu hè più cà solu REST. Avemu ricevutu un inseme di arnesi chì vi permette di travaglià cù dati spartuti in una manera decentralizata.
Ùn sò micca tutti l'aspettu cuparti in l'articulu d'oghje. Avemu sempre bisognu di capisce cumu equilibriu trà u paradigma di dumanda-risposta è u paradigma guidatu da l'avvenimentu. Ma avemu da trattà cù questu a prossima volta. Ci sò temi chì avete bisognu di cunnosce megliu, per esempiu, perchè Stateful Stream Processing hè cusì bonu. Avemu da parlà di questu in u terzu articulu. E ci sò altre custruzzioni putenti chì pudemu prufittà si avemu ricursu à elli, per esempiu, . Hè un cambiamentu di ghjocu per i sistemi di cummerciale distribuiti perchè furnisce garanzii transazionali per in una forma scalabile. Questu serà discutitu in u quartu articulu. Infine, avemu bisognu di passà nantu à i dettagli di implementazione di sti principii.
Ma per avà, ricordate solu di questu: a dicotomia di dati hè una forza chì facemu quandu custruite servizii cummerciale. È avemu da ricurdà questu. U truccu hè di vultà tuttu in u so capu è cumincià à trattà e dati spartuti cum'è oggetti di prima classe. Stateful Stream Processing furnisce un cumprumissu unicu per questu. Evita i "Componenti di Diu" centralizzati chì frenanu u prugressu. Inoltre, assicura l'agilità, a scalabilità è a resilienza di i pipeline di streaming di dati è li aghjunghje à ogni serviziu. Dunque, pudemu fucalizza nantu à u flussu generale di a cuscenza à quale ogni serviziu pò cunnette è travaglià cù e so dati. Questu rende i servizii più scalabili, intercambiabili è autonomi. Allora ùn anu micca solu vede bè nantu à i lavagne è i testi di ipotesi, ma anu da travaglià è evoluzione per decennii.
Source: www.habr.com