Dihotomia datelor: regândirea relației dintre date și servicii

Salutare tuturor! Avem vești grozave, OTUS lansează cursul din nou în iunie „Arhitectul software”, în legătură cu care vă împărtășim în mod tradițional material util.

Dacă ați întâlnit toată chestia asta cu microservicii fără niciun context, ați fi iertat că credeți că este puțin ciudat. Împărțirea unei aplicații în fragmente conectate printr-o rețea înseamnă în mod necesar adăugarea unor moduri complexe de toleranță la erori la sistemul distribuit rezultat.

Deși această abordare implică împărțirea în mai multe servicii independente, scopul final este mult mai mult decât să ruleze aceste servicii pe mașini diferite. Vorbim aici despre interacțiunea cu lumea exterioară, care este și ea distribuită în esența ei. Nu în sensul tehnic, ci mai degrabă în sensul unui ecosistem care este format din mulți oameni, echipe, programe și fiecare dintre aceste părți trebuie cumva să-și facă treaba.

Companiile, de exemplu, sunt o colecție de sisteme distribuite care contribuie colectiv la atingerea unui obiectiv. Am ignorat acest fapt de zeci de ani, încercând să realizăm unificarea prin intermediul fișierelor FTP sau folosind instrumente de integrare a întreprinderii, concentrându-ne în același timp pe propriile noastre obiective izolate. Dar odată cu apariția serviciilor, totul s-a schimbat. Serviciile ne-au ajutat să privim dincolo de orizont și să vedem o lume de programe interdependente care funcționează împreună. Cu toate acestea, pentru a funcționa cu succes, este necesar să recunoaștem și să proiectăm două lumi fundamental diferite: lumea externă, în care trăim într-un ecosistem de multe alte servicii, și lumea noastră personală, internă, în care guvernăm singuri.

Această lume distribuită este diferită de cea în care am crescut și cu care suntem obișnuiți. Principiile construcției arhitecturii tradiționale monolitice nu rezistă criticilor. Așadar, realizarea corectă a acestor sisteme înseamnă mai mult decât crearea unei diagrame grozave de tablă albă sau a unei dovezi interesante de concept. Ideea este să ne asigurăm că un astfel de sistem funcționează cu succes pe o perioadă lungă de timp. Din fericire, serviciile există de ceva timp, deși arată diferit. Lecții SOA sunt încă relevante, chiar condimentate cu Docker, Kubernetes și bărbi hipsteri ușor ponosite.

Așa că astăzi vom analiza cum s-au schimbat regulile, de ce trebuie să regândim modul în care abordăm serviciile și datele pe care le transmit unul altuia și de ce vom avea nevoie de instrumente complet diferite pentru a face acest lucru.

Încapsularea nu va fi întotdeauna prietenul tău

Microserviciile pot funcționa independent unul de celălalt. Această proprietate este cea care le oferă cea mai mare valoare. Această proprietate permite serviciilor să se extindă și să crească. Nu atât în ​​sensul de scalare la cvadrilioane de utilizatori sau petabytes de date (deși acestea pot ajuta și acolo), ci în sensul de scalare în termeni de oameni, pe măsură ce echipele și organizațiile cresc continuu.

Cu toate acestea, independența este o sabie cu două tăișuri. Adică, serviciul în sine poate rula ușor și natural. Dar dacă o funcție este implementată într-un serviciu care necesită utilizarea unui alt serviciu, atunci ajungem să facem modificări la ambele servicii aproape simultan. Într-un monolit acest lucru este ușor de făcut, doar faci o modificare și o trimiți la lansare, dar în cazul sincronizării serviciilor independente vor fi mai multe probleme. Coordonarea dintre echipe și ciclurile de lansare distruge agilitatea.

Ca parte a abordării standard, pur și simplu încearcă să evite schimbările enervante de la capăt la capăt, împărțind clar funcționalitatea între servicii. Serviciul de conectare unică poate fi un bun exemplu aici. Are un rol clar definit care o diferențiază de alte servicii. Această separare clară înseamnă că, într-o lume a cererilor în schimbare rapidă pentru serviciile din jurul său, este puțin probabil ca serviciul de conectare unică să se schimbe. Ea există într-un context strict limitat.

Problema este că, în lumea reală, serviciile de afaceri nu pot menține aceeași separare pură a rolurilor tot timpul. De exemplu, aceleași servicii de afaceri funcționează într-o măsură mai mare cu date care provin de la alte servicii similare. Dacă sunteți implicat în comerțul cu amănuntul online, atunci procesarea fluxului de comenzi, a catalogului de produse sau a informațiilor despre utilizator va deveni o cerință pentru multe dintre serviciile dumneavoastră. Fiecare dintre servicii va avea nevoie de acces la aceste date pentru a funcționa.

Majoritatea serviciilor de afaceri partajează același flux de date, astfel încât munca lor este invariabil împletită.

Ajungem astfel la un punct important despre care merită să vorbim. În timp ce serviciile funcționează bine pentru componentele de infrastructură care funcționează în mare măsură izolat, majoritatea serviciilor de afaceri ajung să fie împletite mult mai strâns.

Dihotomia datelor

Este posibil să existe deja abordări orientate către servicii, dar încă nu au o perspectivă asupra modului de a partaja cantități mari de date între servicii.

Principala problemă este că datele și serviciile sunt inseparabile. Pe de o parte, încapsularea ne încurajează să ascundem datele, astfel încât serviciile să poată fi separate unele de altele și să le facilităm creșterea și schimbările ulterioare. Pe de altă parte, trebuie să fim capabili să împărțim și să cucerim liber datele partajate, la fel ca orice alte date. Ideea este să poți începe să lucrezi imediat, la fel de liber ca în orice alt sistem informațional.

Cu toate acestea, sistemele informaționale au puțin de-a face cu încapsularea. De fapt, este chiar invers. Bazele de date fac tot posibilul pentru a oferi acces la datele pe care le stochează. Ele vin cu o interfață declarativă puternică care vă permite să modificați datele după cum aveți nevoie. O astfel de funcționalitate este importantă în etapa de cercetare preliminară, dar nu pentru gestionarea complexității tot mai mari a unui serviciu în continuă evoluție.

Și aici apare o dilemă. Contradicţie. Dihotomie. La urma urmei, sistemele de informații sunt despre furnizarea de date, iar serviciile sunt despre ascunderea.

Aceste două forțe sunt fundamentale. Ei stau la baza mult din munca noastră, luptând constant pentru excelență în sistemele pe care le construim.

Pe măsură ce sistemele de servicii cresc și evoluează, vedem consecințele dihotomiei datelor în multe feluri. Fie interfața de serviciu va crește, oferind o gamă din ce în ce mai mare de funcționalități și va începe să arate ca o bază de date foarte elegantă, sau vom deveni frustrați și vom implementa o modalitate de a prelua sau muta în masă seturi întregi de date de la serviciu la serviciu.

La rândul său, crearea a ceva care să arate ca o bază de date fantezică de acasă va duce la o serie întreagă de probleme. Nu vom intra în detalii despre motivul pentru care este periculos bază de date partajată, să spunem doar că reprezintă o inginerie costisitoare și operațională semnificativă dificultăți pentru compania care încearcă să-l folosească.

Mai rău este că volumele de date măresc problemele la limitele serviciilor. Cu cât se află mai multe date partajate într-un serviciu, cu atât interfața va deveni mai complexă și va fi mai dificilă combinarea seturilor de date care provin de la servicii diferite.

Abordarea alternativă de extragere și mutare a întregilor seturi de date are, de asemenea, problemele sale. O abordare comună a acestei întrebări arată ca simpla preluare și stocare a întregului set de date și apoi stocarea lui local în fiecare serviciu consumator.

Problema este că diferitele servicii interpretează diferit datele pe care le consumă. Aceste date sunt întotdeauna la îndemână. Sunt modificate și procesate local. Destul de repede încetează să aibă ceva în comun cu datele din sursă.

Cu cât copiile sunt mai mutabile, cu atât datele vor varia în timp.

Pentru a înrăutăți lucrurile, astfel de date sunt dificil de corectat retrospectiv (MDM Aici poate veni cu adevărat la salvare). De fapt, unele dintre problemele tehnologice insolubile cu care se confruntă companiile apar din datele disparate care se multiplică de la aplicație la aplicație.

Pentru a găsi o soluție la această problemă, trebuie să gândim diferit despre datele partajate. Ele trebuie să devină obiecte de primă clasă în arhitecturile pe care le construim. Pat Helland numește astfel de date „externe”, iar aceasta este o caracteristică foarte importantă. Avem nevoie de încapsulare, astfel încât să nu expunem funcționarea interioară a unui serviciu, dar trebuie să facilităm accesul serviciilor la datele partajate, astfel încât să își poată face treaba corect.

Problema este că nicio abordare nu este relevantă astăzi, deoarece nici interfețele de servicii, nici mesageria, nici Baza de date partajată nu oferă o soluție bună pentru lucrul cu date externe. Interfețele de servicii sunt slab potrivite pentru schimbul de date la orice scară. Mesageria mută datele, dar nu le stochează istoricul, astfel încât datele devin corupte în timp. Bazele de date partajate se concentrează prea mult pe un singur punct, ceea ce împiedică progresul. Inevitabil, rămânem blocați într-un ciclu de eșec de date:

Ciclul de eșec al datelor

Fluxuri: o abordare descentralizată a datelor și serviciilor

În mod ideal, trebuie să schimbăm modul în care funcționează serviciile cu datele partajate. În acest moment, oricare abordare se confruntă cu dihotomia menționată mai sus, deoarece nu există praf magic care să poată fi stropit pe ea pentru a o face să dispară. Cu toate acestea, putem regândi problema și ajungem la un compromis.

Acest compromis presupune un anumit grad de centralizare. Putem folosi mecanismul de jurnal distribuit, deoarece oferă fluxuri de încredere și scalabile. Acum dorim ca serviciile să se poată alătura și să opereze pe aceste fire partajate, dar vrem să evităm serviciile complexe centralizate ale lui Dumnezeu care fac această procesare. Prin urmare, cea mai bună opțiune este de a construi procesarea fluxului în fiecare serviciu pentru consumatori. În acest fel, serviciile vor putea să combine seturi de date din diferite surse și să lucreze cu ele așa cum au nevoie.

O modalitate de a realiza această abordare este prin utilizarea unei platforme de streaming. Există multe opțiuni, dar astăzi ne vom uita la Kafka, deoarece utilizarea Stateful Stream Processing ne permite să rezolvăm eficient problema prezentată.

Utilizarea unui mecanism de înregistrare distribuită ne permite să urmăm calea bine bătută și să folosim mesageria pentru a lucra arhitectură condusă de evenimente. Se consideră că această abordare oferă o scalare și o partiționare mai bune decât mecanismul cerere-răspuns, deoarece oferă controlul fluxului mai degrabă receptorului decât expeditorului. Cu toate acestea, pentru tot în această viață trebuie să plătiți, iar aici aveți nevoie de un broker. Dar pentru sistemele mari, compromisul merită (ceea ce poate să nu fie cazul aplicației dvs. web obișnuite).

Dacă un broker este responsabil pentru înregistrarea distribuită mai degrabă decât pentru un sistem tradițional de mesagerie, puteți profita de funcții suplimentare. Transportul se poate scala liniar aproape la fel de bine ca un sistem de fișiere distribuit. Datele pot fi stocate în jurnale pentru o perioadă destul de lungă de timp, astfel încât obținem nu numai schimb de mesaje, ci și stocare de informații. Stocare scalabilă fără teama de stare partajată mutabilă.

Puteți utiliza apoi procesarea fluxului cu stare pentru a adăuga instrumente de bază de date declarative la serviciile consumatoare. Aceasta este o idee foarte importantă. În timp ce datele sunt stocate în fluxuri partajate pe care toate serviciile le pot accesa, agregarea și procesarea pe care o face serviciul este privată. Ei se trezesc izolați într-un context strict limitat.

Eliminați dihotomia datelor prin separarea fluxului de stare imuabil. Apoi adăugați această funcționalitate la fiecare serviciu utilizând Procesarea fluxului cu stat.

Astfel, dacă serviciul dumneavoastră trebuie să funcționeze cu comenzi, un catalog de produse, un depozit, acesta va avea acces deplin: doar dumneavoastră veți decide ce date să combinați, unde să le procesați și cum ar trebui să se schimbe în timp. În ciuda faptului că datele sunt partajate, lucrul cu acestea este complet descentralizat. Este produs în cadrul fiecărui serviciu, într-o lume în care totul merge conform regulilor tale.

Partajați datele fără a le compromite integritatea. Încapsulați funcția, nu sursa, în fiecare serviciu care are nevoie de ea.

Se întâmplă ca datele să fie mutate în masă. Uneori, un serviciu necesită un set de date istoric local în motorul de bază de date selectat. Trucul este că poți garanta că, dacă este necesar, o copie poate fi restaurată din sursă accesând mecanismul de logare distribuită. Conectorii din Kafka fac o treabă grozavă în acest sens.

Deci, abordarea discutată astăzi are mai multe avantaje:

• Datele sunt utilizate sub formă de fluxuri comune, care pot fi stocate în jurnale pentru o lungă perioadă de timp, iar mecanismul de lucru cu date comune este conectat în fiecare context individual, ceea ce permite serviciilor să funcționeze ușor și rapid. În acest fel, dihotomia datelor poate fi echilibrată.
• Datele care provin de la diferite servicii pot fi ușor combinate în seturi. Acest lucru simplifică interacțiunea cu datele partajate și elimină nevoia de a menține seturile de date locale în baza de date.
• Stateful Stream Processing doar stochează datele, iar sursa adevărului rămân jurnalele generale, astfel încât problema coruperii datelor în timp nu este atât de acută.
• În esență, serviciile sunt bazate pe date, ceea ce înseamnă că, în ciuda volumelor tot mai mari de date, serviciile pot răspunde rapid la evenimentele de afaceri.
• Problemele de scalabilitate revin brokerului, nu serviciilor. Acest lucru reduce semnificativ complexitatea serviciilor de scriere, deoarece nu este nevoie să ne gândim la scalabilitate.
• Adăugarea de noi servicii nu necesită schimbarea celor vechi, astfel încât conectarea noilor servicii devine mai ușoară.

După cum puteți vedea, acesta este mai mult decât REST. Am primit un set de instrumente care vă permit să lucrați cu date partajate într-o manieră descentralizată.

Nu toate aspectele au fost tratate în articolul de astăzi. Încă trebuie să ne dăm seama cum să echilibrăm între paradigma cerere-răspuns și paradigma bazată pe evenimente. Dar ne vom ocupa de asta data viitoare. Există subiecte pe care trebuie să le cunoașteți mai bine, de exemplu, de ce Procesarea fluxului cu stat este atât de bună. Vom vorbi despre asta în al treilea articol. Și există și alte constructe puternice de care putem profita dacă recurgem la ele, de exemplu, Exact o dată procesare. Este un schimbător de joc pentru sistemele de afaceri distribuite, deoarece oferă garanții tranzacționale pentru XA într-o formă scalabilă. Acest lucru va fi discutat în al patrulea articol. În cele din urmă, va trebui să trecem peste detaliile de implementare a acestor principii.

Dar deocamdată, amintiți-vă doar acest lucru: dihotomia datelor este o forță cu care ne confruntăm atunci când construim servicii de afaceri. Și trebuie să ne amintim asta. Trucul este să întorci totul și să începi să tratezi datele partajate ca obiecte de primă clasă. Procesarea fluxului cu stat oferă un compromis unic în acest sens. Evită „Componentele lui Dumnezeu” centralizate care împiedică progresul. Mai mult, asigură agilitatea, scalabilitatea și rezistența conductelor de streaming de date și le adaugă la fiecare serviciu. Prin urmare, ne putem concentra asupra fluxului general de conștiință la care orice serviciu se poate conecta și poate lucra cu datele sale. Acest lucru face serviciile mai scalabile, interschimbabile și autonome. Așadar, nu numai că vor arăta bine pe tablele albe și pe testele de ipoteze, dar vor funcționa și vor evolua timp de zeci de ani.

Aflați mai multe despre curs.

Sursa: www.habr.com