{"id":83248,"date":"2020-05-29T19:42:48","date_gmt":"2020-05-29T17:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam"},"modified":"2020-05-29T19:42:48","modified_gmt":"2020-05-29T17:42:48","slug":"dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dicotomia datelor: reinterpretarea rela\u021biei cu datele \u0219i serviciile","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Salut tuturor! Avem ve\u0219ti excelente, \u00een iunie OTUS va relua cursul \u201eArhitect de Software\u201d<\/a><\/noindex>, motiv pentru care \u00eemp\u0103rt\u0103\u0219im cu voi materiale utile.<\/b><\/i><\/p>\n

\"Dicotomia
\n
\n Dac\u0103 te-ai confruntat cu toat\u0103 aceast\u0103 poveste despre microservicii f\u0103r\u0103 niciun context, este de \u00een\u021beles s\u0103 o consideri pu\u021bin ciudat\u0103. \u00cemp\u0103r\u021birea aplica\u021biei \u00een fragmente interconectate printr-o re\u021bea presupune, inevitabil, ad\u0103ugarea unor moduri complexe de redundan\u021b\u0103 \u00eentr-un sistem distribuit rezultat. <\/p>\n

Cu toate c\u0103 aceast\u0103 abordare implic\u0103 \u00eemp\u0103r\u021birea \u00een numeroase servicii independente, scopul final este mult mai amplu dec\u00e2t simpla func\u021bionare a acestor servicii pe ma\u0219ini diferite. Este vorba despre interac\u021biunea cu lumea din jur, care, \u00een esen\u021b\u0103, este tot distribuit\u0103. Nu \u00een sens tehnic, ci mai degrab\u0103 \u00een sensul unei ecosisteme formate din numeroase persoane, echipe, programe, \u0219i fiecare dintre aceste p\u0103r\u021bi trebuie s\u0103 \u00ee\u0219i \u00eendeplineasc\u0103, \u00eentr-un fel sau altul, rolul.<\/a><\/noindex><\/p>\n

Companiile, de exemplu, reprezint\u0103 un set de sisteme distribuite, care, \u00een totalitate, contribuie la atingerea unui anumit obiectiv. Am ignorat acest fapt timp de zeci de ani, \u00eencerc\u00e2nd s\u0103 ob\u021binem integrarea, transfer\u00e2nd fi\u0219iere prin FTP sau folosind instrumente de integrare corporativ\u0103, concentr\u00e2ndu-ne pe obiectivele noastre personale izolate. Dar odat\u0103 cu apari\u021bia serviciilor, totul s-a schimbat. Serviciile ne-au ajutat s\u0103 privim dincolo de orizont \u0219i s\u0103 vedem o lume de programe interdependente care lucreaz\u0103 \u00eempreun\u0103. Cu toate acestea, pentru a avea succes, este necesar s\u0103 \u00een\u021belegem \u0219i s\u0103 proiect\u0103m dou\u0103 lumi fundamental diferite: lumea exterioar\u0103, unde tr\u0103im \u00eentr-o ecosistem\u0103 de multe alte servicii, \u0219i lumea noastr\u0103 interioar\u0103, unde domnim singuri.<\/p>\n

\"Dicotomia
\n
\n Aceast\u0103 lume distribuit\u0103 este diferit\u0103 de cea \u00een care am crescut \u0219i la care ne-am obi\u0219nuit. Principiile construirii arhitecturii tradi\u021bionale monolitice nu rezist\u0103 criticii. Prin urmare, o \u00een\u021belegere corect\u0103 a acestor sisteme reprezint\u0103 mai mult dec\u00e2t realizarea unei scheme elegante pe o tabl\u0103 alb\u0103 sau o demonstra\u021bie atr\u0103g\u0103toare a conceptului. Este vorba despre asigurarea func\u021bion\u0103rii de succes a unui astfel de sistem pe termen lung. Din fericire, serviciile exist\u0103 deja de ceva timp, de\u0219i apar diferit. Lec\u021bii SOA<\/a><\/noindex> sunt \u00eenc\u0103 relevante, chiar \u0219i condimentate cu Docker, Kubernetes \u0219i u\u0219or uzate de b\u0103rbile hipster. <\/p>\n

A\u0219adar, ast\u0103zi ne vom concentra asupra modului \u00een care s-au schimbat regulile, de ce trebuie s\u0103 ne reg\u00e2ndim abordarea fa\u021b\u0103 de servicii \u0219i datele pe care acestea le transmit \u00eentre ele \u0219i de ce avem nevoie de unelte complet diferite pentru acest lucru.<\/p>\n

\u00cencapsularea nu va fi \u00eentotdeauna prietena ta<\/h3>\n

\n Microserviciile pot opera independent unele de altele. Aceast\u0103 proprietate le confer\u0103 cea mai mare valoare. Aceea\u0219i proprietate permite serviciilor s\u0103 se scaleze \u0219i s\u0103 creasc\u0103. Nu at\u00e2t \u00een sensul de a scala la cvadrilioane de utilizatori sau petabytes de date (de\u0219i pot ajuta \u0219i aici), c\u00e2t \u00een sensul de a scala din perspectiva oamenilor, pe m\u0103sur\u0103 ce echipele \u0219i organiza\u021biile cresc continuu.<\/p>\n

\"Dicotomia
\n
\nCu toate acestea, independen\u021ba este o sabie cu dou\u0103 t\u0103i\u0219uri. Adic\u0103, serviciul \u00een sine poate func\u021biona u\u0219or \u0219i f\u0103r\u0103 probleme. Dar dac\u0103 \u00een cadrul unui serviciu se implementeaz\u0103 o func\u021bie care necesit\u0103 implicarea unui alt serviciu, \u00een final va trebui s\u0103 facem modific\u0103ri \u00een ambele servicii aproape simultan. \u00centr-un monolit, acest lucru este simplu, pur \u0219i simplu faci modificarea \u0219i o lansezi, dar \u00een cazul sincroniz\u0103rii serviciilor independente vor ap\u0103rea mai multe probleme. Coordonarea \u00eentre echipe \u0219i ciclurile de lansare distruge flexibilitatea.<\/p>\n

\"Dicotomia
\n
\n\u00cen cadrul abord\u0103rii standard, schimb\u0103rile nedorite sunt evitate prin delimitarea clar\u0103 a func\u021bionalit\u0103\u021bii \u00eentre servicii. Un serviciu de intrare unic\u0103 poate fi un bun exemplu aici. Acesta are un rol clar definit, care \u00eel diferen\u021biaz\u0103 de celelalte servicii. Aceast\u0103 delimitare clar\u0103 \u00eenseamn\u0103 c\u0103, \u00eentr-o lume cu cerin\u021be \u00een continu\u0103 schimbare, serviciul de intrare unic\u0103 va avea pu\u021bine modific\u0103ri. Acesta exist\u0103 \u00eentr-un context strict limitat.<\/p>\n

\"Dicotomia
\n
\n Problema const\u0103 \u00een faptul c\u0103 \u00een lumea real\u0103, serviciile de business nu pot men\u021bine constant o separare clar\u0103 a rolurilor. De exemplu, acelea\u0219i servicii de business lucreaz\u0103 adesea cu date provenite de la alte servicii similare. Dac\u0103 te ocupi de comer\u021bul online, atunci gestionarea fluxului de comenzi, a catalogului de produse sau a informa\u021biilor despre utilizatori va deveni o cerin\u021b\u0103 pentru multe dintre serviciile tale. Fiecare dintre servicii va necesita acces la aceste date pentru a func\u021biona. <\/p>\n

\"Dicotomia
\nMajoritatea serviciilor de business folosesc acela\u0219i flux de date, astfel \u00eenc\u00e2t activitatea lor se \u00eempletesc inevitabil.<\/i><\/p>\n

Astfel, am ajuns la un moment important despre care merit\u0103 s\u0103 discut\u0103m. \u00cen timp ce serviciile func\u021bioneaz\u0103 bine pentru componentele infrastructurii care opereaz\u0103 \u00eentr-un mod relativ separat, majoritatea serviciilor de business se dovedesc a fi interconectate mult mai str\u00e2ns.<\/p>\n

Dihotomia datelor<\/h3>\n

\n Abord\u0103rile orientate spre servicii exist\u0103 poate deja, \u00eens\u0103 au \u00eenc\u0103 foarte pu\u021bine informa\u021bii despre cum s\u0103 schimbe volume mari de date \u00eentre servicii.<\/p>\n

Problema principal\u0103 const\u0103 \u00een faptul c\u0103 datele \u0219i serviciile sunt inseparabile. Pe de o parte, encapsularea ne \u00eendeamn\u0103 s\u0103 ascundem datele, astfel \u00eenc\u00e2t serviciile s\u0103 poat\u0103 fi separate unele de altele, facilit\u00e2nd cre\u0219terea \u0219i modific\u0103rile ulterioare. Pe de alt\u0103 parte, trebuie s\u0103 avem posibilitatea de a \u00eemp\u0103rt\u0103\u0219i \u0219i controla liber datele comune, la fel ca pe orice alte date. Este vorba despre a putea \u00eencepe imediat s\u0103 lucr\u0103m, la fel de liber ca \u00een orice alt sistem informa\u021bional.<\/p>\n

Cu toate acestea, sistemele informa\u021bionale au pu\u021bin \u00een comun cu encapsularea. De fapt, chiar opusul. Bazele de date fac tot ce le st\u0103 \u00een putere pentru a oferi acces la datele stocate \u00een ele. Ele vin cu o interfa\u021b\u0103 declarativ\u0103 puternic\u0103, care permite modificarea datelor a\u0219a cum dore\u0219ti. Aceast\u0103 func\u021bionalitate este important\u0103 \u00een etapa cercet\u0103rilor preliminare, dar nu pentru gestionarea complexit\u0103\u021bii \u00een continu\u0103 cre\u0219tere a unui serviciu \u00een dezvoltare.<\/p>\n

\"Dicotomia
\n
\n \u0218i aici apare dilema. Contradic\u021bia. Dihotomia. Sistemele informa\u021bionale sunt despre furnizarea de date, iar serviciile sunt despre a ascunde.<\/p>\n

Aceste dou\u0103 for\u021be sunt fundamentale. Ele stau la baza celei mai mari p\u0103r\u021bi din munca noastr\u0103, lupt\u00e2nd constant pentru suprema\u021bie \u00een sistemele pe care le construim.<\/p>\n

Pe m\u0103sur\u0103 ce sistemele de servicii cresc \u0219i evolueaz\u0103, observ\u0103m diferite manifest\u0103ri ale consecin\u021belor dihotomiei datelor. Fie interfa\u021ba serviciului va cre\u0219te, oferind un set din ce \u00een ce mai larg de func\u021bii \u0219i va \u00eencepe s\u0103 semene cu o baz\u0103 de date foarte ciudat\u0103 \u0219i de cas\u0103, fie vom suferi de dezam\u0103gire \u0219i vom implementa o modalitate de a extrage sau de a muta \u00een mas\u0103 \u00eentregi seturi de date dintr-un serviciu \u00een altul.<\/p>\n

\"Dicotomia
\n
\n \u00cen schimb, crearea a ceva care arat\u0103 ca o baz\u0103 de date foarte ciudat\u0103 \u0219i de cas\u0103 va duce la o serie \u00eentreag\u0103 de probleme. Nu ne vom aprofunda \u00een detaliile despre ce este periculos, shared database<\/i>, dar s\u0103 spunem doar c\u0103 reprezint\u0103 dificult\u0103\u021bi ingineresti \u0219i opera\u021bionale semnificative \u0219i costisitoare pentru compania care \u00eencearc\u0103 s\u0103 o utilizeze.<\/a><\/noindex> Mai r\u0103u, volumul de date amplific\u0103 problemele cu limitele serviciilor. Cu c\u00e2t exist\u0103 mai multe date comune \u00een cadrul serviciului, cu at\u00e2t interfa\u021ba devine mai complicat\u0103 \u0219i mai greu de combinat seturile de date care provin din diverse servicii.<\/p>\n

O abordare alternativ\u0103 pentru extragerea \u0219i mutarea \u00eentregilor seturi de date are, de asemenea, problemele sale. Un mod comun de a aborda aceast\u0103 problem\u0103 arat\u0103 ca o simpl\u0103 extragere \u0219i stocare a unui set de date \u00een \u00eentregime, apoi stocarea acestuia local \u00een fiecare serviciu consumator.<\/p>\n

Problema este c\u0103 diferitele servicii interpreteaz\u0103 datele pe care le consum\u0103 \u00een mod diferit. Aceste date sunt \u00eentotdeauna la \u00eendem\u00e2n\u0103. Ele sunt modificate \u0219i procesate local. Destul de repede, ele \u00eenceteaz\u0103 s\u0103 mai aib\u0103 ceva \u00een comun cu datele din surs\u0103.<\/p>\n

\"Dicotomia
\n
\n Cu c\u00e2t copiile sunt mai mutabile, cu at\u00e2t datele vor diferi mai mult \u00een timp.<\/p>\n

\"Dicotomia
\n Ce e \u0219i mai r\u0103u, astfel de date sunt greu de corectat \u00een retrospectiv\u0103 (<\/i><\/p>\n

MDMpoate cu adev\u0103rat s\u0103 vin\u0103 \u00een ajutor aici). De fapt, unele dintre problemele tehnologice greu de rezolvat cu care se confrunt\u0103 afacerile apar din cauza datelor heterogene care se multiplic\u0103 de la o aplica\u021bie la alta.<\/a><\/noindex> Pentru a g\u0103si o solu\u021bie la aceast\u0103 problem\u0103 cu datele comune, trebuie s\u0103 g\u00e2ndim diferit. Ele trebuie s\u0103 devin\u0103 obiecte de prim\u0103 clas\u0103 \u00een arhitecturile pe care le construim.<\/p>\n

Pat Helland Pet Helland<\/a><\/noindex> denume\u0219te aceste date \u201eexterne\u201d, iar aceasta este o caracteristic\u0103 foarte important\u0103. Avem nevoie de \u00eencapsulare pentru a nu dezv\u0103lui structura intern\u0103 a serviciului, dar trebuie s\u0103 facilit\u0103m accesul serviciilor la datele partajate, astfel \u00eenc\u00e2t acestea s\u0103-\u0219i poat\u0103 \u00eendeplini corect sarcinile.<\/p>\n

\"Dicotomia
\n
\n Problema const\u0103 \u00een faptul c\u0103 niciuna dintre metodele disponibile nu mai este relevant\u0103 ast\u0103zi, deoarece nici interfe\u021bele de serviciu, nici schimbul de mesaje, nici baza de date partajat\u0103 nu ofer\u0103 o solu\u021bie bun\u0103 pentru a lucra cu date externe. Interfe\u021bele de serviciu sunt pu\u021bin potrivite pentru schimbul de date la orice scar\u0103. Schimbul de mesaje mut\u0103 datele, dar nu le p\u0103streaz\u0103 istoricul, astfel c\u0103, \u00een timp, datele se corup. Bazele de date partajate se concentreaz\u0103 prea mult \u00eentr-un singur punct, ceea ce restric\u021bioneaz\u0103 progresul. Inevitabil, r\u0103m\u00e2nem bloca\u021bi \u00eentr-un ciclu de e\u0219ec al datelor:<\/p>\n

\"Dicotomia
\n Ciclul de e\u0219ec al datelor<\/i><\/p>\n

Fluxuri: o abordare descentralizat\u0103 a datelor \u0219i serviciilor<\/h3>\n

\n \u00cen ideal, trebuie s\u0103 schimb\u0103m abordarea privind modul \u00een care serviciile lucreaz\u0103 cu datele comune. \u00cen prezent, orice metod\u0103 se confrunt\u0103 cu dicotomia men\u021bionat\u0103, deoarece nu exist\u0103 o solu\u021bie miraculoas\u0103 cu care s\u0103 o acoperim pentru a o face s\u0103 dispar\u0103. Cu toate acestea, putem reinterpreta problema \u0219i ajunge la un compromis.<\/p>\n

Acest compromis presupune un anumit grad de centralizare. Putem folosi mecanismele jurnalelor distribuite, deoarece acestea ofer\u0103 fluxuri fiabile \u0219i scalabile. Acum trebuie ca serviciile s\u0103 se poat\u0103 al\u0103tura \u0219i s\u0103 utilizeze aceste fluxuri comune, dar dorim s\u0103 evit\u0103m serviciile centralizate complexe care fac aceast\u0103 prelucrare. Prin urmare, cea mai bun\u0103 op\u021biune este s\u0103 integr\u0103m procesarea fluxurilor \u00een fiecare serviciu-consumator. Astfel, serviciile vor putea combina seturi de date din surse diferite \u0219i vor lucra cu ele a\u0219a cum au nevoie.<\/p>\n

Una dintre modalit\u0103\u021bile de a atinge o astfel de abordare este utilizarea unei platforme de streaming. Exist\u0103 multe op\u021biuni disponibile, dar ast\u0103zi ne vom concentra pe Kafka, deoarece utilizarea sa pentru procesarea fluxurilor de st\u0103ri ne permite s\u0103 abord\u0103m eficient problema prezentat\u0103.<\/p>\n

\"Dicotomia
\n
\n Utilizarea mecanismului de jurnalizare distribuit\u0103 ne permite s\u0103 urm\u0103m un drum b\u0103t\u0103torit \u0219i s\u0103 folosim schimbul de mesaje pentru a lucra cu arhitectur\u0103 orientat\u0103 pe evenimente<\/a><\/noindex>. Se consider\u0103 c\u0103 aceast\u0103 abordare ofer\u0103 o scalabilitate \u0219i o separare mai bun\u0103 dec\u00e2t mecanismul \u201ecerere-r\u0103spuns\u201d, deoarece pred\u0103 controlul fluxului c\u0103tre destinatari, nu expeditori. Totu\u0219i, trebuie s\u0103 pl\u0103ti\u021bi pentru tot \u00een via\u021ba aceasta, iar aici ve\u021bi avea nevoie de un broker. Dar pentru sistemele mari, acest compromis merit\u0103 (ceea ce nu se poate spune despre aplica\u021biile web medii).<\/p>\n

Dac\u0103 brokerul se ocup\u0103 de jurnalizarea distribuit\u0103, nu sistemul tradi\u021bional de mesagerie, se pot folosi func\u021bionalit\u0103\u021bi adi\u021bionale. Transportul poate fi scalat liniar aproape la fel de bine ca un sistem de fi\u0219iere distribuit. Datele pot fi stocate \u00een jurnale pentru o perioad\u0103 destul de lung\u0103, astfel \u00eenc\u00e2t ob\u021binem nu doar mesagerie, ci \u0219i stocare de informa\u021bii. Stocare scalabil\u0103 f\u0103r\u0103 teama de a ob\u021bine o stare general\u0103 modificabil\u0103.<\/p>\n

Apoi, se poate folosi mecanismul de procesare a fluxului cu stare (stateful stream processing) pentru a ad\u0103uga instrumente declarative de baz\u0103 de date \u00een serviciile consumatori. Aceasta este o idee foarte important\u0103. At\u00e2ta timp c\u00e2t datele sunt stocate \u00een fluxuri comune, la care pot avea acces toate serviciile, combinarea \u0219i prelucrarea efectuate de serviciu sunt private. Ele se afl\u0103 izolate \u00eentr-un context strict limitat.<\/p>\n

\"Dicotomia
\n Sc\u0103pa\u021bi de dicotomia datelor, \u00eemp\u0103r\u021bind fluxul de st\u0103ri imutabile. Apoi, ad\u0103uga\u021bi aceast\u0103 func\u021bie \u00een fiecare serviciu folosind Procesarea Fluxului cu Stare.<\/i><\/p>\n

Astfel, dac\u0103 serviciul vostru trebuie s\u0103 lucreze cu comenzi, catalogul de produse, depozit, va avea acces complet: doar voi ve\u021bi decide ce date s\u0103 combina\u021bi, unde s\u0103 le procesa\u021bi \u0219i cum ar trebui s\u0103 se schimbe \u00een timp. De\u0219i datele sunt comune, lucrul cu ele este complet descentralizat. Se desf\u0103\u0219oar\u0103 \u00een interiorul fiec\u0103rui serviciu, \u00eentr-o lume unde totul se desf\u0103\u0219oar\u0103 dup\u0103 regulile voastre.<\/p>\n

\"Dicotomia
\n\u00cemp\u0103rt\u0103\u0219i\u021bi datele astfel \u00eenc\u00e2t s\u0103 nu fie afectat\u0103 integritatea acestora. \u00cencapsula\u021bi func\u021bia, nu sursa, \u00een fiecare serviciu de care este nevoie.<\/i><\/p>\n

Se \u00eent\u00e2mpl\u0103 ca datele s\u0103 fie necesar s\u0103 fie mutate \u00een mas\u0103. Uneori, serviciul are nevoie de un set istoric local de date \u00een motorul de baze de date ales. Cheia este c\u0103 se poate garanta c\u0103, atunci c\u00e2nd este necesar, copia poate fi restaurat\u0103 din surs\u0103 prin intermediul mecanismului de jurnalizare distribuit\u0103. Conectorii din Kafka \u00ee\u0219i fac excelent treaba \u00een aceast\u0103 privin\u021b\u0103.<\/p>\n

A\u0219adar, abordarea discutat\u0103 ast\u0103zi are c\u00e2teva avantaje:<\/p>\n