{"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\/sl\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dikotomija podatkov: prenova odnosa do podatkov in storitev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozdravljeni! Imamo odli\u010dne novice, junija OTUS ponovno za\u010denja te\u010daj \u00bbArhitekt programske opreme\u00ab<\/a><\/noindex>, zato tradicionalno z vami delimo koristne materiale.<\/b><\/i><\/p>\n

\"Dikotomija
\n
\n \u010ce ste se sre\u010dali s to zgodbo o mikroservisih brez kakr\u0161negakoli konteksta, vam je lahko opro\u0161\u010deno, da jo imate za nekoliko nenavadno. Razdelitev aplikacije na ko\u0161\u010dke, med seboj povezane v omre\u017eju, nujno pomeni dodajanje kompleksnih na\u010dinov odpornosti na napake v nastalo razdeljeno sistem. <\/p>\n

Kljub temu, da tak pristop vklju\u010duje razdelitev na \u0161tevilne neodvisne storitve, je kon\u010dni cilj veliko ve\u010d kot le delovanje teh storitev na razli\u010dnih napravah. Gre za interakcijo z okoljem, ki je po svoji naravi prav tako razdeljeno. Ne v tehni\u010dnem smislu, temve\u010d bolj v smislu ekosistema, ki ga sestavlja mnogo ljudi, ekip, programov, pri \u010demer mora vsak del nekako opravljati svoje delo.<\/a><\/noindex><\/p>\n

Podjetja na primer predstavljajo zbirko razdeljenih sistemov, ki skupaj prispevajo k doseganju dolo\u010denega cilja. Ta dejstvo smo zanemarjali desetletja, medtem ko smo se trudili dose\u010di integracijo, prena\u0161ali datoteke prek FTP ali uporabljali orodja za podjetni\u0161ko integracijo, pri \u010demer smo se osredoto\u010dali na svoje osebne cilje. A s prihodom storitev se je vse spremenilo. Storitve so nam pomagale pogledati \u010dez obzorje in videti svet medsebojno povezanih programov, ki delujejo skupaj. Vendar pa je za uspe\u0161no delovanje potrebno razumeti in zasnovati dva temeljno razli\u010dna sveta: zunanji svet, kjer \u017eivimo v ekosistemu \u0161tevilnih drugih storitev, in na\u0161 osebni, notranji svet, kjer vlada Solo.<\/p>\n

\"Dikotomija
\n
\n Ta razdeljen svet se razlikuje od tistega, v katerem smo odra\u0161\u010dali in na katerega smo navajeni. Na\u010dela oblikovanja tradicionalne monolitne arhitekture ne prenesejo nobene kritike. Zato je pravilno razumevanje takih sistemov nekaj ve\u010d kot le ustvarjanje super sheme na beli markerni tabli ali kul dokaz koncepta. Gre za to, da tak sistem uspe\u0161no deluje dolgotrajno. Na sre\u010do storitve obstajajo \u017ee kar dolgo, \u010deprav izgledajo razli\u010dno. Lekcije SOA<\/a><\/noindex> \u0161e vedno velja, kljub dodatkom Docker, Kubernetes in nekoliko zanemarjenim hipsterskim bradam. <\/p>\n

Torej danes bomo pogledali, kako so se pravila spremenila, zakaj moramo predelati na\u0161 pristop k storitvam in podatkom, ki si jih izmenjujejo, ter zakaj bomo potrebovali povsem druga\u010dna orodja.<\/p>\n

Inkapzulacija vam ne bo vedno v pomo\u010d.<\/h3>\n

\n Mikrostoritve lahko delujejo neodvisno ena od druge. To lastnost jim daje najve\u010djo vrednost. Ta lastnost omogo\u010da storitvam, da se raz\u0161irijo in rastejo. Ne toliko v smislu raz\u0161irjanja na kvadrilijone uporabnikov ali petabajte podatkov (\u010deprav lahko tudi pri tem pomagajo), ampak v smislu raz\u0161irjanja z vidika ljudi, saj ekipe in organizacije nenehno rastejo.<\/p>\n

\"Dikotomija
\n
\nVendar pa je neodvisnost dvorezni me\u010d. To pomeni, da se storitev sama lahko izvaja enostavno in brez te\u017eav. Toda, \u010de v storitvi izvedemo funkcijo, ki zahteva vklju\u010ditev druge storitve, bomo na koncu morali spremeniti obe storitvi skoraj hkrati. Pri monolitu je to enostavno, preprosto spremenite in po\u0161ljete v izdajo, medtem ko se pri usklajevanju neodvisnih storitev pojavlja ve\u010d te\u017eav. Koordinacija med ekipami in izdajnimi cikli ru\u0161i pro\u017enost.<\/p>\n

\"Dikotomija
\n
\nV okviru standardnega pristopa se sku\u0161ajo nadle\u017enim pre\u010dnim spremembam preprosto izogniti, tako da jasno lo\u010dijo funkcionalnost med storitvami. Storitev enotne to\u010dke dostopa je lahko dober primer tega. Ima jasno opredeljeno vlogo, ki jo lo\u010duje od drugih storitev. Tak\u0161na jasna razdelitev pomeni, da v svetu hitro spreminjajo\u010dih se zahtev do okoli\u0161kih storitev storitev enotne to\u010dke dostopa verjetno ne bo veliko spreminjala. Deluje v strogo omejenem kontekstu.<\/p>\n

\"Dikotomija
\n
\n Te\u017eava je v tem, da v resni\u010dnem svetu poslovne storitve ne morejo nenehno vzdr\u017eevati popolne lo\u010denosti vlog. Na primer, te iste poslovne storitve v ve\u010dji meri delujejo z podatki, ki jih prejmejo od drugih takih storitev. \u010ce se ukvarjate z elektronsko trgovino, bo obdelava toka naro\u010dil, kataloga izdelkov ali informacij o uporabnikih postala zahteva za mnoge va\u0161e storitve. Vsaki od storitev bo za delovanje potreboval dostop do teh podatkov. <\/p>\n

\"Dikotomija
\nVe\u010dina poslovnih storitev uporablja isti tok podatkov, zato se njihovo delovanje neizogibno prepleta.<\/i><\/p>\n

Tako smo pri\u0161li do pomembne to\u010dke, o kateri je vredno govoriti. Medtem ko storitve dobro delujejo za komponente infrastrukture, ki delujejo v veliki meri lo\u010deno, se ve\u010dina poslovnih storitev izka\u017ee za tesno prepleteno.<\/p>\n

Dikotomija podatkov<\/h3>\n

\n Pristopi, usmerjeni v storitve, morda \u017ee obstajajo, vendar \u0161e vedno ni veliko informacij o tem, kako izmenjavati velike koli\u010dine podatkov med storitvami.<\/p>\n

Glavna te\u017eava je, da sta podatka in storitve nedeljiva. Po eni strani nas inkapsulacija poziva, naj skrijemo podatke, da lahko storitve lo\u010dimo druga od druge in olaj\u0161amo njihovo rast in nadaljnje spremembe. Po drugi strani pa moramo imeti mo\u017enost svobodno deliti in imeti oblast nad skupnimi podatki, tako kot nad katerimikoli drugimi. Gre za to, da imamo mo\u017enost takoj za\u010deti delati, tako svobodno, kot v kateri koli drugi informacijski sistem.<\/p>\n

Vendar pa imajo informacijski sistemi malo skupnega z inkapsulacijo. Dejansko v nasprotju. Podatkovne baze naredijo vse, kar lahko, da omogo\u010dijo dostop do podatkov, ki jih hranijo. Na voljo so z mo\u010dnim deklarativnim vmesnikom, ki omogo\u010da, da oblikujete podatke, kot \u017eelite. Ta funkcionalnost je pomembna v fazi predhodnih raziskav, ne pa za upravljanje nara\u0161\u010dajo\u010de zapletenosti stalno razvijajo\u010de se storitve.<\/p>\n

\"Dikotomija
\n
\n In tukaj se pojavi dilema. Proti govor. Dikotomija. Kajti informacijski sistemi so o zagotavljanju podatkov, storitve pa o skrivanju.<\/p>\n

Ti dve sile sta osnovne. Le\u017eijo v temelju ve\u010dine na\u0161ega dela, nenehno se borita za prevlado v sistemih, ki jih ustvarjamo.<\/p>\n

Ko se sistemi storitev \u0161irijo in razvijajo, opa\u017eamo razli\u010dne manifestacije posledic dihotomije podatkov. Ali bo vmesnik storitve rasel, ponujal vedno \u0161ir\u0161i nabor funkcij in za\u010denjal izgledati kot zelo \u010dudna doma\u010da baza podatkov, ali pa nas bo doletelo razo\u010daranje in razvili bomo kak\u0161en na\u010din za mno\u017ei\u010dno ekstrakcijo ali premikanje celih nizov podatkov iz storitve v storitev.<\/p>\n

\"Dikotomija
\n
\n V samo ustvarjanje \u010desarkoli, kar izgleda kot \u010dudna doma\u010da baza podatkov, privede do vrsto te\u017eav. Ne bomo se poglabljali v podrobnosti tega, kako je nevarna shared database<\/i>, ampak re\u010demo, da prina\u0161a znatne drage in\u017eenirske ter operativne te\u017eave<\/a><\/noindex> za podjetje, ki se trudi z njo.<\/p>\n

\u0160e slab\u0161e je, da se volumni podatkov pomno\u017eijo te\u017eave z mejami storitev. \u010cim ve\u010d skupnih podatkov le\u017ei znotraj storitve, te\u017eji postane vmesnik in te\u017eje je zdru\u017eiti niz podatkov, ki prihajajo iz razli\u010dnih storitev.<\/p>\n

Alternativni pristop z ekstrakcijo in premikanjem celih nizov podatkov prav tako ima svoje te\u017eave. Raz\u0161irjen pristop k temu vpra\u0161anju se zdi preprosta ekstrakcija in hranjenje niza podatkov v celoti, nato pa shranjevanje lokalno v vsakem storitvenem uporabniku.<\/p>\n

\"Dikotomija
\n
\n Te\u017eava je v tem, da razli\u010dne storitve razli\u010dno interpretirajo podatke, ki jih porabijo. Ti podatki so vedno pri roki. Spremenijo se in obdelajo lokalno. Zelo hitro prenehajo imeti kaj skupnega s podatki v viru.<\/p>\n

\"Dikotomija
\n \u010cim bolj so kopije mutabilne, tem bolj se bodo podatki razlikovali s \u010dasom.<\/i><\/p>\n

\u0160e huje, tak\u0161ne podatke je te\u017eko popraviti retrospektivno (MDM<\/a><\/noindex> tukaj resni\u010dno lahko pride v pomo\u010d). V resnici nekatere od te\u017eko re\u0161ljivih tehnolo\u0161kih te\u017eav, s katerimi se podjetja soo\u010dajo, izhajajo iz heterogenih podatkov, ki se mno\u017eijo od aplikacije do aplikacije.<\/p>\n

Da bi na\u0161li re\u0161itev tega problema o skupnih podatkih, je treba razmi\u0161ljati druga\u010de. Postati morajo objekti prvega razreda v arhitekturah, ki jih gradimo. Pat Helland<\/a><\/noindex> imenuje takie dane 'zewn\u0119trznymi', co jest bardzo istotn\u0105 cech\u0105. Potrzebujemy enkapsulacji, aby nie ujawnia\u0107 wewn\u0119trznej struktury us\u0142ugi, ale musimy u\u0142atwi\u0107 us\u0142ugom dost\u0119p do wsp\u00f3lnych danych, aby mog\u0142y prawid\u0142owo wykonywa\u0107 swoj\u0105 prac\u0119.<\/p>\n

\"Dikotomija
\n
\n Problem polega na tym, \u017ce \u017cadne z podej\u015b\u0107 dzisiaj nie jest ju\u017c aktualne, poniewa\u017c ani interfejsy us\u0142ug, ani wymiana wiadomo\u015bci, ani wsp\u00f3lna baza danych nie oferuj\u0105 dobrego rozwi\u0105zania do pracy z danymi zewn\u0119trznymi. Interfejsy us\u0142ug s\u0105 s\u0142abo przystosowane do wymiany danych w jakiejkolwiek skali. Wymiana wiadomo\u015bci przenosi dane, ale nie przechowuje ich historii, przez co z biegiem czasu dane ulegaj\u0105 zniekszta\u0142ceniu. Wsp\u00f3lne bazy danych zbytnio koncentruj\u0105 si\u0119 w jednym punkcie, co ogranicza rozw\u00f3j post\u0119pu. Nieuchronnie utkn\u0119li\u015bmy w cyklu niemo\u017cno\u015bci danych:<\/p>\n

\"Dikotomija
\n Cykl niemo\u017cno\u015bci danych<\/i><\/p>\n

Strumienie: zdecentralizowane podej\u015bcie do danych i us\u0142ug<\/h3>\n

\n W idealnym \u015bwiecie musimy zmieni\u0107 podej\u015bcie do tego, jak us\u0142ugi pracuj\u0105 z wsp\u00f3lnymi danymi. Na chwil\u0119 obecn\u0105 ka\u017cde podej\u015bcie napotyka wspomnian\u0105 powy\u017cej dychotomi\u0119, poniewa\u017c nie ma \u017cadnego magicznego proszku, kt\u00f3rym mo\u017cna by to obficie posypa\u0107, aby to znikn\u0119\u0142o. Mo\u017cemy jednak przemy\u015ble\u0107 problem i doj\u015b\u0107 do kompromisu.<\/p>\n

Ten kompromis zak\u0142ada pewien stopie\u0144 centralizacji. Mo\u017cemy skorzysta\u0107 z mechanizmu rozproszonych log\u00f3w, poniewa\u017c zapewnia on niezawodne, skalowalne strumienie. Teraz us\u0142ugi musz\u0105 m\u00f3c do\u0142\u0105cza\u0107 i pracowa\u0107 z tymi wsp\u00f3lnymi strumieniami, jednak chcemy unikn\u0105\u0107 skomplikowanych, scentralizowanych us\u0142ug God Service, kt\u00f3re wykonuj\u0105 takie przetwarzanie. Dlatego najlepsz\u0105 opcj\u0105 jest wbudowanie przetwarzania strumieniowego w ka\u017cd\u0105 us\u0142ug\u0119-konsumenta. W ten spos\u00f3b us\u0142ugi b\u0119d\u0105 mog\u0142y \u0142\u0105czy\u0107 zbiory danych z r\u00f3\u017cnych \u017ar\u00f3de\u0142 i pracowa\u0107 z nimi w spos\u00f3b, kt\u00f3ry jest im potrzebny.<\/p>\n

Jednym ze sposob\u00f3w dotarcia do takiego podej\u015bcia jest wykorzystanie platformy strumieniowej. Istnieje wiele opcji, ale dzisiaj przyjrzymy si\u0119 dok\u0142adnie Kafka, poniewa\u017c jej Stateful Stream Processing skutecznie rozwi\u0105zuje przedstawiony problem.<\/p>\n

\"Dikotomija
\n
\n Wykorzystanie mechanizmu rozproszonego logowania pozwala nam pod\u0105\u017ca\u0107 wytyczon\u0105 \u015bcie\u017ck\u0105 i korzysta\u0107 z wymiany wiadomo\u015bci, aby pracowa\u0107 z dogodkovno usmerjene arhitekture<\/a><\/noindex>. Verjame se, da ta pristop zagotavlja bolj\u0161o skalabilnost in razdelitev kot mehanizem \"vpra\u0161anje-odgovor\", saj nadzor nad tokom preda prejemniku, namesto po\u0161iljatelju. Vendar pa je potrebno za vse v tem \u017eivljenju pla\u010dati, zato boste potrebovali posrednika. Toda za velike sisteme je ta kompromis vreden (kar ne moremo re\u010di za va\u0161a povpre\u010dna spletna aplikacija).<\/p>\n

\u010ce za porazdeljeno bele\u017eenje poskrbi posrednik in ne tradicionalni sistem za izmenjavo sporo\u010dil, lahko izkoristimo dodatne funkcionalnosti. Transport je mogo\u010de linearno skalirati skoraj tako dobro kot porazdeljeni sistem datotek. Podatki se lahko hranijo v dnevnikih dovolj dolgo, zato dobimo ne le izmenjavo sporo\u010dil, temve\u010d tudi skladi\u0161\u010de informacij. Skalabilno skladi\u0161\u010de brez strahu pred spreminjanjem skupnega stanja.<\/p>\n

Nato lahko uporabimo mehanizem obdelave toka s shranjevanjem stanja za dodajanje deklarativnih orodij baze podatkov v storitve-prejemnike. To je zelo pomembna misel. Dokler so podatki shranjeni v skupnih tokovih, do katerih imajo dostop vse storitve, je zdru\u017eevanje in obdelava, ki jo izvaja storitev, zasebna. So izolirane v strogo omejenem kontekstu.<\/p>\n

\"Dikotomija
\n Znebite se dihotomije podatkov z delitvijo neomejenega toka stanj. Nato to funkcijo dodajte v vsako storitev s pomo\u010djo obdelave toka s shranjevanjem stanja.<\/i><\/p>\n

Tako, \u010de va\u0161a storitev mora delovati s naro\u010dili, katalogom izdelkov, skladi\u0161\u010dem, bo imela popoln dostop: samo vi boste odlo\u010dali, katere podatke zdru\u017eiti, kje jih obdelati in kako se morajo spreminjati s \u010dasom. Kljub temu, da so podatki skupni, je delo z njimi popolnoma decentralizirano. Poteka znotraj vsake storitve, v svetu, kjer vse poteka po va\u0161ih pravilih.<\/p>\n

\"Dikotomija
\nDelite podatke tako, da ne kr\u0161ite njihove celovitosti. Inkapsulirajte funkcijo, ne vira, v vsaki storitvi, ki jo potrebuje.<\/i><\/p>\n

Ponekad je potrebno masovno premestiti podatke. Ponekad servisu treba lokalni istorijski skup podataka u odabranom sistemu baze podataka. Klju\u010dna ta\u010dka je da se mo\u017ee garantovati da se, kada je potrebno, kopija mo\u017ee obnoviti iz izvora putem obra\u0107anja mehanizmu distribuiranog logiranja. Poveziva\u010di u Kafki odli\u010dno obavljaju ovaj zadatak.<\/p>\n

Dakle, pristup o kojem smo danas razgovarali ima nekoliko prednosti:<\/p>\n