{"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: andmete ja teenuste suhete \u00fcmberm\u00f5testamine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, k\u00f5igile! Meil on suurep\u00e4rased uudised, juunis alustab OTUS taas kursust \u201eTarkvara arhitekt\u201c<\/a><\/noindex>, seet\u00f5ttu jagame traditsiooniliselt teiega kasulikke materjale.<\/b><\/i><\/p>\n

\"Andmete
\n
\n Kui olete sattunud kogu sellele mikroteenuste jutu peale ilma igasuguse kontekstita, siis on teil vabandatav seda veidi kummalisena pidada. Rakenduse jagamine fragmentideks, mis on omavahel seotud v\u00f5rguga, t\u00e4hendab kindlasti keerukate talitlush\u00e4irete taluvuse re\u017eiimide lisamist tekkivasse jaotatud s\u00fcsteemi. <\/p>\n

Kuigi selline l\u00e4henemine h\u00f5lmab mitme eraldiseisva teenuse jagamist, on l\u00f5ppkokkuv\u00f5tte eesm\u00e4rk palju rohkem kui lihtsalt nende teenuste t\u00f6\u00f6 erinevates masinates. Siin on juttu suheldes \u00fcmbritseva maailmaga, mis oma olemuselt on samuti jaotatud. Mitte tehnilises m\u00f5ttes, vaid pigem ekos\u00fcsteemi m\u00f5ttes, mis koosneb paljusid inimesi, meeskondi, programme, ja iga \u00fcks neist peab omamoodi oma t\u00f6\u00f6d tegema.<\/a><\/noindex><\/p>\n

Ettev\u00f5tted, n\u00e4iteks, on nagu kogum jaotatud s\u00fcsteeme, mis koos aitavad kaasa teatud eesm\u00e4rgi saavutamisele. Me oleme ignoreerinud seda fakti aastak\u00fcmneid, p\u00fc\u00fcdes saavutada \u00fchtsust, edastades faile FTP kaudu v\u00f5i kasutades ettev\u00f5tte integratsioonit\u00f6\u00f6riistu, samal ajal keskendudes oma isiklikele eraldatud eesm\u00e4rkidele. Kuid teenuste tulekuga on k\u00f5ik muutunud. Teenused on aidanud meil vaadata \u00fcle horisondi ja n\u00e4ha maailma omavahel seotud programme, mis t\u00f6\u00f6tavad koos. Kuid eduka toimimise jaoks on vajalik teadvustada ja projekteerida kaks p\u00f5him\u00f5tteliselt erinevat maailma: v\u00e4line maailm, kus me elame teiste teenuste ekos\u00fcsteemis, ja meie isiklik, sisemine maailm, kus me valime \u00fcksi.<\/p>\n

\"Andmete
\n
\n Selline jaotatud maailm erineb sellest, kus me \u00fcles oleme kasvanud ja millega oleme harjunud. Tava monoliitsete arhitektuuride ehitamise p\u00f5him\u00f5tted ei pea mingit kriitikat. Seet\u00f5ttu on selliste s\u00fcsteemide \u00f5ige m\u00f5istmine midagi enamat kui lihtsalt toreda skeemi loomine valgele markeritahvlile v\u00f5i lahe t\u00f5estus kontseptsioonist. Siin on juttu sellest, et selline s\u00fcsteem t\u00f6\u00f6taks edukalt pika aja jooksul. \u00d5nneks on teenused juba \u00fcsna kaua olemas olnud, kuigi need n\u00e4evad v\u00e4lja erinevad. SOA \u00f5ppetunnid<\/a><\/noindex> on endiselt asjakohane, isegi kui see on maitsestatud Dockeri, Kubernetesega ja veidi hipsterlike habemete poolt kulunud. <\/p>\n

Seega vaatame t\u00e4na, kuidas reeglid on muutunud, miks peame oma l\u00e4henemist teenustele ja andmetele, mida nad \u00fcksteisele edastavad, uuesti \u00fcle vaatama ning miks me vajame selleks t\u00e4iesti erinevat t\u00f6\u00f6riistakomplekti.<\/p>\n

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

\n Mikroteenused saavad \u00fcksteisest s\u00f5ltumatult t\u00f6\u00f6tada. Just see omadus annab neile suurima v\u00e4\u00e4rtuse. See omadus v\u00f5imaldab teenustel skaleeruda ja kasvada. Mitte ainult kvadriljonite kasutajate v\u00f5i petabaitide andmete skaleerimise m\u00f5ttes (kuigi ka siin v\u00f5ivad nad aidata), vaid pigem inimestega seoses, kuna meeskonnad ja organisatsioonid kasvavad pidevalt.<\/p>\n

\"Andmete
\n
\nSiiski, s\u00f5ltumatus on kahe teraga m\u00f5\u00f5k. See t\u00e4hendab, et teenus v\u00f5ib iseenesest sujuvalt ja probleemideta t\u00f6\u00f6tada. Kuid kui teenuses kasutatakse funktsiooni, mis n\u00f5uab teise teenuse kaasamist, peame l\u00f5puks tegema muudatusi peaaegu samaaegselt m\u00f5lemas teenuses. Monoliidis on see lihtne, lihtsalt teete muudatuse ja saadate selle v\u00e4lja, aga iseseisvate teenuste s\u00fcnkroonimise korral on probleeme rohkem. Meeskondade ja v\u00e4ljalaskets\u00fcklite koordineerimine h\u00e4irib paindlikkust.<\/p>\n

\"Andmete
\n
\nStandardse l\u00e4henemise kohaselt p\u00fc\u00fctakse ebameeldivaid \u00fclekandeid lihtsalt v\u00e4ltida, eraldades funktsionaalsuse selgelt teenuste vahel. \u00dche sissep\u00e4\u00e4su teenus v\u00f5ib olla siin hea n\u00e4ide. Sellel on selgelt m\u00e4\u00e4ratletud roll, mis eristab seda teistest teenustest. See selge jaotus t\u00e4hendab, et kiiresti muutuva n\u00f5udlusega teenuste maailmas on seesama \u00fchesissep\u00e4\u00e4su teenus t\u00f5en\u00e4oliselt harva muutuv. See eksisteerib \u00e4\u00e4rmiselt piiratud kontekstis.<\/p>\n

\"Andmete
\n
\n Probleem on selles, et reaalmaailmas ei saa \u00e4riteenused pidevalt hoida sama selget rollide eristust. N\u00e4iteks t\u00f6\u00f6tavad need \u00e4riteenused suuremal m\u00e4\u00e4ral andmetega, mis p\u00e4rinevad teistelt sarnastelt teenustelt. Kui tegelete veebikaubandusega, siis tellimuste t\u00f6\u00f6tlemine, toodete kataloog v\u00f5i kasutajainformatsioon muutuvad paljude teie teenuste n\u00f5udmiseks. Iga teenus vajab nende andmete t\u00f6\u00f6ks juurdep\u00e4\u00e4su. <\/p>\n

\"Andmete
\nEnamik \u00e4riteenuseid kasutab sama andmevoogu, mist\u00f5ttu nende t\u00f6\u00f6 on pidevalt omavahel seotud.<\/i><\/p>\n

Niinimetatud oleme j\u00f5udnud olulise hetkeni, millest tasub r\u00e4\u00e4kida. Kuigi teenused toimivad h\u00e4sti infrastruktuuri komponentide puhul, mis t\u00f6\u00f6tavad suuresti isoleeritult, on enamik \u00e4riteenuseid omavahel palju tihedamalt 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 selles, et andmed ja teenused on lahutamatud. \u00dchelt poolt kutsub kapseldamine meid andmeid varjama, et teenuseid saaks omavahel eristada ja nende kasvu ja edasisi muudatusi lihtsustada. Teiselt poolt peame saama vabalt jagada ja omada \u00fchiseid andmeid nagu ka teisi. R\u00e4\u00e4gime v\u00f5imalusest alustada t\u00f6\u00f6d kohe, sama vabalt nagu igas muus infotehnoloogias.<\/p>\n

Kuid infotehnoloogiatel on kapseldamisega v\u00e4he \u00fchist. Tegelikult on isegi vastupidi. Andmebaasid teevad k\u00f5ik endast oleneva, et anda juurdep\u00e4\u00e4s neis hoitavatele andmetele. Need tulevad koos v\u00f5imsa deklaratiivse liidese, mis v\u00f5imaldab andmeid muuta nii, nagu soovite. See funktsionaalsus on oluline eeluurimisfaasis, kuid mitte pidevalt kasvava teenuse haldamiseks.<\/p>\n

\"Andmete
\n
\n Siin tekib dilemma. Vastur\u00e4\u00e4kivus. Dikotoomia. Sest infotehnoloogiad \u2013 see on andmete pakkumine, ja teenused \u2013 andmete varjamine.<\/p>\n

Need two forces are fundamental. They underlie much of our work, constantly fighting for supremacy in the systems we create.<\/p>\n

As service systems grow and evolve, we see different manifestations of the consequences of data dichotomy. Either the service interface will grow, providing an ever-wider range of functions and will start looking like a very strange homemade database, or we will be faced with disappointment and will implement some way to extract or move large sets of data from service to service.<\/p>\n

\"Andmete
\n
\n In turn, creating anything that looks like a strange homemade database will lead to a whole series of problems. We won't go into the details of what is dangerous about shared database<\/i>, let's just say it represents significant costly engineering and operational challenges<\/a><\/noindex> for a company trying to use it.<\/p>\n

Worse still, data volumes multiply the problems with service boundaries. The more shared data lies within a service, the more complex the interface will become and the harder it will be to merge datasets coming from various services.<\/p>\n

An alternative approach of extracting and moving whole datasets also has its problems. The common approach to this issue looks like simply extracting and storing a dataset entirely, and then storing it locally in each consumer service.<\/p>\n

\"Andmete
\n
\n The issue is that different services interpret the data they consume differently. This data is always at hand. It changes and is processed locally. Quite quickly, it ceases to have anything in common with the source data.<\/p>\n

\"Andmete
\n The more mutable the copies are, the more the data will differ over time.<\/i><\/p>\n

What\u2019s worse, such data is difficult to correct retrospectively (MDM<\/a><\/noindex> can indeed come to the rescue here). In fact, some of the intractable technological problems faced by businesses arise from heterogeneous data multiplying from application to application.<\/p>\n

To find a solution to the problem of common data, one needs to think differently. They must become first-class objects in the architectures we build. Pat Helland<\/a><\/noindex> nimetatakse neid andmeid \"v\u00e4listeks\", ja see on v\u00e4ga oluline omadus. Me vajame kapseldamist, et mitte paljastada teenuse sisemist \u00fclesehitust, kuid peame h\u00f5lbustama teenuste juurdep\u00e4\u00e4su jagatud andmetele, et nad saaksid oma t\u00f6\u00f6d \u00f5igesti teha.<\/p>\n

\"Andmete
\n
\n Probleem on selles, et \u00fckski praegustest l\u00e4henemisviisidest ei ole enam asjakohane, kuna ei teenuse liidesed, juhuslikud teated ega jagatud andmebaasid ei paku head lahendust v\u00e4liste andmete t\u00f6\u00f6tlemiseks. Teenuse liidesed ei sobi andmete vahetamiseks mingis ulatuses. Juhuslikud teated edastavad andmeid, kuid ei salvesta nende ajalugu, mist\u00f5ttu andmed aja jooksul riknevad. Jagatud andmebaasid on liiga keskendunud \u00fchele punktile, mis pidurdab edusamme. Me j\u00e4\u00e4me paratamatult n\u00f5rkade andmete ts\u00fcklisse:<\/p>\n

\"Andmete
\n N\u00f5rkade andmete ts\u00fckkel<\/i><\/p>\n

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

\n Ideaalis peame muutma l\u00e4henemist sellele, kuidas teenused t\u00f6\u00f6tavad jagatud andmetega. Praegu seisavad k\u00f5ik l\u00e4henemisviisid silmitsi \u00fclaltoodud dikotoomiaga, kuna ei ole mingit maagilist pulbrit, millega saaksime selle lahendada. Siiski saame probleemi uuesti m\u00f5testada ja leida kompromissi.<\/p>\n

See kompromiss eeldab teatud m\u00e4\u00e4ral tsentraliseerimist. Saame kasutada jaotatud logide mehhanismi, kuna see tagab usaldusv\u00e4\u00e4rsed ja skaleeritavad vood. N\u00fc\u00fcd peab teenused saama liituda ja t\u00f6\u00f6tada nende jagatud voogudega, kuid soovime v\u00e4ltida keerulisi tsentraliseeritud Jumala teenuseid, mis teevad sellist t\u00f6\u00f6tlemist. Seet\u00f5ttu on parim lahendus integreerida voogude t\u00f6\u00f6tlemine igasse teenusesse-kasutajasse. Nii saavad teenused kombineerida andmekogusid erinevatest allikatest ja t\u00f6\u00f6tada nendega nii, nagu nemad soovivad.<\/p>\n

\u00dcks v\u00f5imalus sellise l\u00e4henemise saavutamiseks on voogude t\u00f6\u00f6tlemise platvormi kasutamine. Olemas on palju v\u00f5imalusi, kuid t\u00e4na vaatame just Kafka't, kuna selle Stateful Stream Processing kasutamine v\u00f5imaldab t\u00f5husalt lahendada esitatud probleemi.<\/p>\n

\"Andmete
\n
\n Jaotatud logimise mehhanismi kasutamine v\u00f5imaldab meil minna m\u00f6\u00f6da rajatud rada ja kasutada juhuslikku teatevahetust, et t\u00f6\u00f6tada koos. \u00fcritus-suunaline arhitektuur<\/a><\/noindex>. Sellise l\u00e4henemise eelduseks on parem skaleerimine ja jaotamine kui \u201ek\u00fcsi-vasta\u201d mehhanism, kuna see annab vooluhalduse kontrolli saajale, mitte saatjale. Kuid k\u00f5ike selles elus peab eest maksma, ja siin vajate brokerit. Suurte s\u00fcsteemide puhul on see kompromiss seda v\u00e4\u00e4rt (mida ei saa \u00f6elda teie keskmiste veebirakenduste kohta).<\/p>\n

Kui jaotatud logimine s\u00f5ltub brokerist, mitte traditsioonilisest s\u00f5numiteedest, siis saab kasutada t\u00e4iendavaid funktsioone. Transporti saab lineaarselt skaleerida peaaegu sama h\u00e4sti kui jaotatud failis\u00fcsteemi. Andmeid v\u00f5ib logides hoida piisavalt kaua, mist\u00f5ttu saame mitte ainult s\u00f5numite_exchange, vaid ka teabe s\u00e4ilitamise. Skaleeritav salvestus ilma hirmuta, et saada muudetav \u00fcldine olek.<\/p>\n

Seej\u00e4rel on v\u00f5imalik kasutada stateful stream processing (olekuga voogude t\u00f6\u00f6tlemine) mehhanismi andmebaasi deklaratiivsete t\u00f6\u00f6riistade lisamiseks tarbiteenustele. See on v\u00e4ga oluline m\u00f5te. Niikaua kui andmed on jagatud voogudes, millele k\u00f5ik teenused saavad juurde p\u00e4\u00e4seda, on teenuse poolne \u00fchendamine ja t\u00f6\u00f6tlemine privaatne. Nad j\u00e4\u00e4vad rangelt piiratud konteksti sees eraldatuks.<\/p>\n

\"Andmete
\n Vabanege andmete diktoomast, jagades muutumatud olekute vood. Seej\u00e4rel lisage see funktsioon iga teenuse jaoks, kasutades stateful stream processing.<\/i><\/p>\n

Seega, kui teie teenus peab t\u00f6\u00f6tama tellimustega, toote kataloogiga, laoga, on tal t\u00e4ielik juurdep\u00e4\u00e4s: ainult teie otsustate, millised andmed \u00fchendada, kus neid t\u00f6\u00f6delda ja kuidas need aja jooksul muutuvad. Kuigi andmed on jagatud, on nende t\u00f6\u00f6tlemine t\u00e4ielikult detsentraliseeritud. Seda tehakse igas teenuses, maailmas, kus k\u00f5ik k\u00e4ib teie reeglite j\u00e4rgi.<\/p>\n

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

Tavaliselt juhtub, et andmeid tuleb massiliselt liigutada. M\u00f5nikord vajab teenus valitud andmebaasi mootori kohaliku ajaloolise andmeseti. Oluline on, et vajadusel saab koopia taastada allikast, kasutades jaotatud logimise mehhanismi. Kafka \u00fchendused teevad selle \u00fclesande suurep\u00e4raselt \u00e4ra.<\/p>\n

K\u00e4esoleval l\u00e4henemisel on mitmeid eeliseid:<\/p>\n