{"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\/et\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Andmete dikotoomia: uue m\u00f5tlemise suhe andmete ja teenustega","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere k\u00f5igile! Meil on suurep\u00e4raseid uudiseid, juunis k\u00e4ivitab OTUS taas kursuse \u201eTarkvara arhitekt\u201c<\/a><\/noindex>, millega seoses jagame teiega traditsiooniliselt kasulikku materjali.<\/b><\/i><\/p>\n

\"Andmete
\n
\n Kui olete kokku puutunud kogu sellele mikroteenuste jutule ilma igasuguse kontekstita, on teil m\u00f5istetav seda veidi kummalisena pidada. Rakenduse jagamine osadeks, mis on omavahel seotud v\u00f5rguga, t\u00e4hendab kindlasti ka keeruliste talitlush\u00e4ired taluvate mehhanismide lisamist tekkinud hajutatud s\u00fcsteemi. <\/p>\n

Kuigi see l\u00e4henemine h\u00f5lmab jagamist paljudele s\u00f5ltumatutele teenustele, on l\u00f5ppeesm\u00e4rk midagi enam kui lihtsalt nende teenuste t\u00f6\u00f6tamine erinevates masinates. Jutt on siin keskkonna interaktsioonist, mis iseenesest on samuti hajus. Mitte tehnilises m\u00f5ttes, vaid pigem \u00f6kos\u00fcsteemis, mis koosneb paljusid inimesi, meeskondi, programme, ning iga\u00fcks neist peab mingil moel oma t\u00f6\u00f6d tegema.<\/a><\/noindex><\/p>\n

Ettev\u00f5tted, n\u00e4iteks, koosnevad hajusate s\u00fcsteemide kogumist, mis kokkuv\u00f5ttes aitavad saavutada teatud eesm\u00e4rki. Me ignoreerisime seda fakti aastak\u00fcmneid, p\u00fc\u00fcdes saavutada \u00fchtsust, edastades faile FTP kaudu v\u00f5i kasutades ettev\u00f5tte integreerimist\u00f6\u00f6riistu, keskendudes samal ajal oma isiklikele lahkarvamustele. Kuid teenuste saabumisega k\u00f5ik muutus. Teenused aitasid meil vaadata kaugemale ja n\u00e4ha vastastikust s\u00f5ltuvust, kus programmid t\u00f6\u00f6tavad \u00fchiselt. Kuid selleks, et edukalt tegutseda, tuleb m\u00f5ista ja disainida kahte fundamentaalselt erinevat maailma: v\u00e4lismaailm, kus elame paljude teiste teenuste \u00f6kos\u00fcsteemis, ja meie isiklik, sisemaailm, kus me valitseme \u00fcksi.<\/p>\n

\"Andmete
\n
\n Selline hajustatud maailm erineb sellest, kus me kasvasime ja millega harjusime. Traditsioonilise monoliit arhitektuuri ehitamise p\u00f5him\u00f5tted ei pea mingit kriitikat. Seet\u00f5ttu on selliste s\u00fcsteemide \u00f5ige m\u00f5istmine midagi muud kui vaid lahe skeemi loomine valgel tahvlil v\u00f5i lahe t\u00f5estus kontseptsioonist. Oluline on, et selline s\u00fcsteem toimiks edukalt pika aja jooksul. \u00d5nneks on teenused eksisteerinud juba piisavalt kaua, kuigi need n\u00e4evad v\u00e4lja erinevad. SOA \u00f5ppetunnid<\/a><\/noindex> on endiselt aktuaalsed, isegi kui need on maitsestatud Docker'i, Kubernetes'e ja kergelt kulunud hipsteri habe. <\/p>\n

Nii et t\u00e4na vaatame, kuidas reeglid on muutunud, miks peame \u00fcmber m\u00f5tlema oma l\u00e4henemist teenustele ja andmetele, mida nad \u00fcksteisele edastavad, ja miks meil selleks on vaja t\u00e4iesti teistsuguseid t\u00f6\u00f6riistu.<\/p>\n

Inkaptsulatsioon ei ole alati teie s\u00f5ber<\/h3>\n

\n Mikroteenused saavad t\u00f6\u00f6tada iseseisvalt. Just see omadus annab neile suurima v\u00e4\u00e4rtuse. See omadus v\u00f5imaldab teenustel kasvatada ja laieneda. Mitte ainult mitte kuni kvadriljonite kasutajateni v\u00f5i petabaitide andmeteni (kuigi nad saavad ka siin aidata), vaid pigem inimeste perspektiivist, kuna meeskonnad ja organisatsioonid kasvavad pidevalt.<\/p>\n

\"Andmete
\n
\nKuid iseseisvus on kaheaegne m\u00f5\u00f5k. Teenus v\u00f5ib iseenesest t\u00f6\u00f6tada lihtsasti ja vaevata. Kuid kui teenuses rakendatakse funktsiooni, mis vajab teise teenuse kaasamist, peame l\u00f5puks tegema muudatusi m\u00f5lemas teenuses peaaegu samal ajal. Monoliidis on see lihtne, sa lihtsalt teed muudatuse ja saadad selle v\u00e4lja, aga iseseisvate teenuste s\u00fcnkroniseerimisel on probleeme rohkem. Koordineerimine meeskondade ja v\u00e4ljalasetts\u00fcklite vahel h\u00e4vitab paindlikkuse.<\/p>\n

\"Andmete
\n
\nTavap\u00e4rases l\u00e4henemises p\u00fc\u00fctakse ebameeldivate l\u00e4bivoolavate muudatuste tegemist lihtsalt v\u00e4ltida, eristades selgelt funktsionaalsust teenuste vahel. \u00dchtse sisenemise teenus on siin hea n\u00e4ide. Sellel on selgelt m\u00e4\u00e4ratletud roll, mis eristab seda teistest teenustest. Selline selge jaotus t\u00e4hendab, et kiiresti muutuvate n\u00f5udmiste maailmas muudatuste osas j\u00e4\u00e4b \u00fchtse sisenemise teenus t\u00f5en\u00e4oliselt muutumatuks. See eksisteerib range piiratuse kontekstis.<\/p>\n

\"Andmete
\n
\n Probleem seisneb selles, et reaalses maailmas ei saa \u00e4riteenused pidevalt s\u00e4ilitada sama puhast rolli jaotust. N\u00e4iteks t\u00f6\u00f6tavad need samad \u00e4riteenused laiemalt andmetega, mis on saadud teistelt sarnastelt teenustelt. Kui tegelete veebikaubandusega, siis tellimuste, tootekatalooge v\u00f5i kasutajainformatsiooni t\u00f6\u00f6tlemine saab olema paljude teie teenuste n\u00f5udmine. Iga teenus vajab nende andmete t\u00f6\u00f6tlemiseks ligip\u00e4\u00e4su. <\/p>\n

\"Andmete
\nEnamik \u00e4riteenuseid kasutavad \u00fcks ja sama andmevoogu, seet\u00f5ttu on nende t\u00f6\u00f6 pidevalt omavahel seotud.<\/i><\/p>\n

Nii oleme j\u00f5udnud olulisse hetke, millest tasub r\u00e4\u00e4kida. Kuigi teenused toimivad h\u00e4sti infrastruktuuri komponentide puhul, mis t\u00f6\u00f6tavad suures osas isoleeritult, on enamik \u00e4riteenuseid omavahel tihedalt seotud.<\/p>\n

Andmete dikotoomia<\/h3>\n

\n Teenustele orienteeritud l\u00e4henemised v\u00f5ivad juba eksisteerida, kuid neis on endiselt v\u00e4he teavet selle kohta, kuidas vahetada suuri andmemahtusid teenuste vahel.<\/p>\n

P\u00f5hiprobleem on see, et andmed ja teenused on lahutamatud. \u00dchest k\u00fcljest kutsub kapseldamine meid andmeid peitma, et teenuseid oleks v\u00f5imalik omavahel eraldada ning nende kasvu ja edasisi muutusi lihtsustada. Teisest k\u00fcljest peame saama vabalt jagada ja hallata \u00fchiseid andmeid, nagu ka mis tahes teisi. K\u00fcsimus on selles, et oleksime v\u00f5imelised kohe t\u00f6\u00f6le asuma, sama vabalt kui mis tahes muus infos\u00fcsteemis.<\/p>\n

Kuid informatsioonis\u00fcsteemidel on v\u00e4he \u00fchist kapseldamisega. Tegelikult on see isegi vastupidine. Andmebaasid teevad k\u00f5ik endast oleneva, et anda juurdep\u00e4\u00e4s neis hoitavatele andmetele. Need pakuvad v\u00f5imsat deklaratiivset liidest, mis v\u00f5imaldab andmeid vastavalt vajadusele muuta. See funktsionaalsus on oluline eeluurimise etapis, kuid mitte pidevalt areneva teenuse keerukuse haldamiseks.<\/p>\n

\"Andmete
\n
\n Ja siin tekib dilemma. Vastur\u00e4\u00e4kivus. Dihotoomia. Sest informatsioonis\u00fcsteemid on seotud andmete pakkumisega, samas kui teenused on seotud nende varjamisega.<\/p>\n

Need kaks j\u00f5udu on fundamentaalsed. Need on meie t\u00f6\u00f6 p\u00f5hialuseks, pidevalt v\u00f5ideldes \u00fclemv\u00f5imu nimel meie loodud s\u00fcsteemides.<\/p>\n

Teen, kui teenuses\u00fcsteemid arenevad ja kasvavad, m\u00e4rkame andmete diktoomia erinevaid v\u00e4ljundeid. Kas teenuse liides laieneb, pakkudes \u00fcha laiemat funktsioonide kogumit ja hakkab n\u00e4gema v\u00e4lja nagu veidra koduvalmistatud andmebaas, v\u00f5i seisame silmitsi pettumusega ja leiname vajadust leida viise massiliste andmekogumite teenuste vahel liikumiseks v\u00f5i teisaldamiseks.<\/p>\n

\"Andmete
\n
\n Oma olemuselt viib miski, mis n\u00e4eb v\u00e4lja nagu veidralt koduvalmistatud andmebaas, terve rea probleemideni. Me ei p\u00f5hjalda n\u00fc\u00fcd, kui ohtlik see on, shared database<\/i>, lihtsalt \u00fctleme, et see esindab m\u00e4rkimisv\u00e4\u00e4rseid ja kallid inseneri- ja operatiivsed v\u00e4ljakutsed<\/a><\/noindex> ettev\u00f5ttele, kes \u00fcritab seda kasutada.<\/p>\n

Halvem on see, et andmemaht suurendab teenuste vaheprobleeme. Mida rohkem jagatud andmeid teenuses on, seda keerulisemaks muutub liides ja seda raskem on \u00fchendada erinevatest teenustest p\u00e4rit andmekogumeid.<\/p>\n

Alternatiivne l\u00e4henemine andmekogude t\u00e4ieliku eraldamisele ja liigutamisele toob endaga kaasa oma probleemid. Levinud l\u00e4henemine sellele probleemile on andmekogumi lihtne eraldamine ja s\u00e4ilitamine, mille j\u00e4rel hoitakse seda kohapeal igas tarbimisteenus.<\/p>\n

\"Andmete
\n
\n Probleem seisneb selles, et erinevad teenused t\u00f5lgendavad andmeid, mida nad tarbivad, erinevalt. Need andmed on alati k\u00e4ep\u00e4rast. Need muutuvad ja t\u00f6\u00f6deldakse kohapeal. Suhteliselt kiiresti kaotavad nad igasuguse seose allikate andmetega.<\/p>\n

\"Andmete
\n Mida mutatiivsemad on koopiad, seda rohkem erinevad andmed aja jooksul.<\/i><\/p>\n

Veelgi hullem on, et selliseid andmeid on retrospektiivis raske parandada (MDM<\/a><\/noindex> siin v\u00f5ib t\u00f5epoolest abiks tulla). Tegelikult on m\u00f5ned keerulised tehnoloogilised probleemid, millega ettev\u00f5tted silmitsi seisavad, tingitud heterogeensetest andmetest, mis paljunevad rakendusest rakendusse.<\/p>\n

Selle probleemi lahendamiseks, mis puudutab \u00fchiseid andmeid, tuleb m\u00f5elda teistmoodi. Need peaksid olema esmaklassilised objektid arhitektuurides, mida me loome. Pat Heliand<\/a><\/noindex> nimeltakse selliseid andmeid \"v\u00e4listeks\", ja see on v\u00e4ga oluline omadus. Me vajame kapseldamist, et mitte paljastada teenuse sisemist struktuuri, kuid peame h\u00f5lbustama teenustel juurdep\u00e4\u00e4su jagatud andmetele, et nad saaksid oma t\u00f6\u00f6d t\u00f5husalt teha.<\/p>\n

\"Andmete
\n
\n Probleem seisneb selles, et \u00fckski t\u00e4nap\u00e4evane l\u00e4henemine ei ole enam asjakohane, kuna ei teenuse liidesed, s\u00f5numivahetus ega jagatud andmebaasid ei paku head lahendust v\u00e4listest andmetest t\u00f6\u00f6tamiseks. Teenuse liidesed ei sobi andmete vahetamiseks mingis mahus. S\u00f5numivahetus edastab andmeid, kuid ei hoia nende ajalugu, seet\u00f5ttu andmed aja jooksul kahjustuvad. Jagatud andmebaasid keskenduvad liiga tugevalt \u00fches kohas, mis pidurdab arengu edenemist. Me j\u00e4\u00e4me paratamatult andmete eba\u00f5nnestumise ts\u00fcklisse:<\/p>\n

\"Andmete
\n Andmete eba\u00f5nnestumise ts\u00fckkel<\/i><\/p>\n

Voogud: detsentraliseeritud l\u00e4henemine andmetele ja teenustele<\/h3>\n

\n Ideaalis peaksime muutma l\u00e4henemist sellele, kuidas teenused t\u00f6\u00f6tavad jagatud andmetega. Praegu seisavad k\u00f5ik l\u00e4henemised silmitsi \u00fclaltoodud dikotoomiaga, kuna ei ole olemas mingit imerohtu, mille abil saaksime selle lahendada. Siiski saame problematiseerimist \u00fcmber m\u00f5elda ja j\u00f5uda kompromissini.<\/p>\n

See kompromiss eeldab teatud m\u00e4\u00e4ral tsentraliseerimist. Saame kasutada detsentraliseeritud logide mehhanismi, kuna see tagab usaldusv\u00e4\u00e4rsed ja skaleeritavad vood. N\u00fc\u00fcd on vaja, et teenused saaksid \u00fchineda ja t\u00f6\u00f6tada nende jagatud voogudega, kuid soovime v\u00e4ltida keerulisi tsentraliseeritud God Service'e, mis sellist t\u00f6\u00f6tlemist teevad. Seega on parim variant integreerida voogude t\u00f6\u00f6tlemine igasse teenusekasutajasse. Nii saavad teenused \u00fchendada andmestikke erinevatest allikatest ja kasutada neid vajalikel viisidel.<\/p>\n

\u00dcks viis sellise l\u00e4henemisviisi saavutamiseks on voogedastusteenuse kasutamine. Valikuid on palju, kuid t\u00e4na vaatame Kafka't, kuna selle Stateful Stream Processing v\u00f5imaldab t\u00f5husalt lahendada esitatud probleemi.<\/p>\n

\"Andmete
\n
\n Jaotatud loggingu mehhanismi kasutamine v\u00f5imaldab meil minna kulutatud teed pidi ja kasutada s\u00f5numivahetust, et t\u00f6\u00f6tada s\u00fcndmustep\u00f5hise arhitektuuriga<\/a><\/noindex>. Sellise l\u00e4henemise puhul peetakse, et see tagab parema skaleeritavuse ja jaotuse kui \"p\u00e4ring-vastus\" mehhanism, kuna see annab voolu kontrolli saajale, mitte saatjale. Kuid k\u00f5ik n\u00f5uab elus maksmist, ja siin on teil vaja vahetusjaama. Kuid suurte s\u00fcsteemide puhul on see kompromiss seda v\u00e4\u00e4rt (mida ei saa \u00f6elda teie keskmiste veebirakenduste kohta).<\/p>\n

Kui hajutatud logimise eest vastutab vahendaja, mitte traditsiooniline s\u00f5numites\u00fcsteem, saab kasutada lisafunktsioone. Transporti on v\u00f5imalik lineaarselt skaleerida peaaegu sama h\u00e4sti kui hajutatud failis\u00fcsteemi. Andmeid saab salvestada logides piisavalt kaua, seega saame mitte ainult s\u00f5numite edastamise, vaid ka teabe hoidmist. Skaleeritav salvestus ilma hirmuta saada muudetav \u00fchine olek.<\/p>\n

Seej\u00e4rel saab kasutada stateful stream processing (olekuga voogude t\u00f6\u00f6tlemise) mehhanismi, et lisada deklareeritud andmebaasi t\u00f6\u00f6riistu tarbimisteenustele. See on v\u00e4ga oluline m\u00f5te. Kuni andmed on salvestatud \u00fchistes voogudes, millega k\u00f5ik teenused saavad juurde p\u00e4\u00e4seda, on teenuse poolt \u00fchendamine ja t\u00f6\u00f6tlemine privaatne. Need j\u00e4\u00e4vad rangelt piiratud konteksti isolatsiooni.<\/p>\n

\"Andmete
\n Vabanege andmete dikotoomiast, eraldades immutaabelne olekuvoog. Seej\u00e4rel lisage see funktsioon igasse teenusesse Stateful Stream Processing'i abil.<\/i><\/p>\n

Seega, kui teie teenus peab t\u00f6\u00f6tama tellimustega, toote katalooge, varudega, on teil t\u00e4ielik juurdep\u00e4\u00e4s: ainult teie otsustate, millised andmed \u00fchendada, kus neid t\u00f6\u00f6delda ja kuidas need ajaga muutuvad. Hoolimata sellest, et andmed on jagatud, on t\u00f6\u00f6tlemine t\u00e4iesti detsentraliseeritud. See toimub igas teenuses, maailmas, kus k\u00f5ik k\u00e4ib teie reeglite j\u00e4rgi.<\/p>\n

\"Andmete
\nJagage andmeid nii, et nende terviklikkus ei oleks ohustatud. Omakorda funktsioon, mitte allikas, igas teenuses, kus seda vajatakse.<\/i><\/p>\n

Tegelikult v\u00f5ib andmeid olla vaja massiliselt liigutada. M\u00f5nikord vajab teenus valitud andmebaasi mootori jaoks kohalikke ajaloolisi andmekogumeid. Punkt on see, et v\u00f5ite garanteerida, et vajadusel saab koopia taastada allikast, kasutades jaotatud logimise mehhanismi. Kafka \u00fchendajad teevad seda \u00fclesannet suurep\u00e4raselt.<\/p>\n

Nii et t\u00e4nasel k\u00e4sitletud l\u00e4henemisel on mitmeid eeliseid:<\/p>\n