Andmete dikotoomia: andmete ja teenuste suhete ümbermõtestamine

Tere, kõigile! Meil on suurepärased uudised, juunis alustab OTUS taas kursust „Tarkvara arhitekt“, seetõttu jagame traditsiooniliselt teiega kasulikke materjale.

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õrguga, tähendab kindlasti keerukate talitlushäirete taluvuse režiimide lisamist tekkivasse jaotatud süsteemi.

Kuigi selline lähenemine hõlmab mitme eraldiseisva teenuse jagamist, on lõppkokkuvõtte eesmärk palju rohkem kui lihtsalt nende teenuste töö erinevates masinates. Siin on juttu suheldes ümbritseva maailmaga, mis oma olemuselt on samuti jaotatud. Mitte tehnilises mõttes, vaid pigem ekosüsteemi mõttes, mis koosneb paljusid inimesi, meeskondi, programme, ja iga üks neist peab omamoodi oma tööd tegema.

Ettevõtted, näiteks, on nagu kogum jaotatud süsteeme, mis koos aitavad kaasa teatud eesmärgi saavutamisele. Me oleme ignoreerinud seda fakti aastakümneid, püüdes saavutada ühtsust, edastades faile FTP kaudu või kasutades ettevõtte integratsioonitööriistu, samal ajal keskendudes oma isiklikele eraldatud eesmärkidele. Kuid teenuste tulekuga on kõik muutunud. Teenused on aidanud meil vaadata üle horisondi ja näha maailma omavahel seotud programme, mis töötavad koos. Kuid eduka toimimise jaoks on vajalik teadvustada ja projekteerida kaks põhimõtteliselt erinevat maailma: väline maailm, kus me elame teiste teenuste ekosüsteemis, ja meie isiklik, sisemine maailm, kus me valime üksi.

Selline jaotatud maailm erineb sellest, kus me üles oleme kasvanud ja millega oleme harjunud. Tava monoliitsete arhitektuuride ehitamise põhimõtted ei pea mingit kriitikat. Seetõttu on selliste süsteemide õige mõistmine midagi enamat kui lihtsalt toreda skeemi loomine valgele markeritahvlile või lahe tõestus kontseptsioonist. Siin on juttu sellest, et selline süsteem töötaks edukalt pika aja jooksul. Õnneks on teenused juba üsna kaua olemas olnud, kuigi need näevad välja erinevad. SOA õppetunnid on endiselt asjakohane, isegi kui see on maitsestatud Dockeri, Kubernetesega ja veidi hipsterlike habemete poolt kulunud.

Seega vaatame täna, kuidas reeglid on muutunud, miks peame oma lähenemist teenustele ja andmetele, mida nad üksteisele edastavad, uuesti üle vaatama ning miks me vajame selleks täiesti erinevat tööriistakomplekti.

Kapseldamine ei ole alati teie sõber

Mikroteenused saavad üksteisest sõltumatult töötada. Just see omadus annab neile suurima väärtuse. See omadus võimaldab teenustel skaleeruda ja kasvada. Mitte ainult kvadriljonite kasutajate või petabaitide andmete skaleerimise mõttes (kuigi ka siin võivad nad aidata), vaid pigem inimestega seoses, kuna meeskonnad ja organisatsioonid kasvavad pidevalt.

Siiski, sõltumatus on kahe teraga mõõk. See tähendab, et teenus võib iseenesest sujuvalt ja probleemideta töötada. Kuid kui teenuses kasutatakse funktsiooni, mis nõuab teise teenuse kaasamist, peame lõpuks tegema muudatusi peaaegu samaaegselt mõlemas teenuses. Monoliidis on see lihtne, lihtsalt teete muudatuse ja saadate selle välja, aga iseseisvate teenuste sünkroonimise korral on probleeme rohkem. Meeskondade ja väljalasketsüklite koordineerimine häirib paindlikkust.

Standardse lähenemise kohaselt püütakse ebameeldivaid ülekandeid lihtsalt vältida, eraldades funktsionaalsuse selgelt teenuste vahel. Ühe sissepääsu teenus võib olla siin hea näide. Sellel on selgelt määratletud roll, mis eristab seda teistest teenustest. See selge jaotus tähendab, et kiiresti muutuva nõudlusega teenuste maailmas on seesama ühesissepääsu teenus tõenäoliselt harva muutuv. See eksisteerib äärmiselt piiratud kontekstis.

Probleem on selles, et reaalmaailmas ei saa äriteenused pidevalt hoida sama selget rollide eristust. Näiteks töötavad need äriteenused suuremal määral andmetega, mis pärinevad teistelt sarnastelt teenustelt. Kui tegelete veebikaubandusega, siis tellimuste töötlemine, toodete kataloog või kasutajainformatsioon muutuvad paljude teie teenuste nõudmiseks. Iga teenus vajab nende andmete tööks juurdepääsu.

Enamik äriteenuseid kasutab sama andmevoogu, mistõttu nende töö on pidevalt omavahel seotud.

Niinimetatud oleme jõudnud olulise hetkeni, millest tasub rääkida. Kuigi teenused toimivad hästi infrastruktuuri komponentide puhul, mis töötavad suuresti isoleeritult, on enamik äriteenuseid omavahel palju tihedamalt seotud.

Andmete dikotoomia

Teenustele orienteeritud lähenemised võivad juba eksisteerida, kuid neis on endiselt vähe teavet selle kohta, kuidas vahetada suuri andmemahtusid teenuste vahel.

Põhiprobleem on selles, et andmed ja teenused on lahutamatud. Ühelt 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 ühiseid andmeid nagu ka teisi. Räägime võimalusest alustada tööd kohe, sama vabalt nagu igas muus infotehnoloogias.

Kuid infotehnoloogiatel on kapseldamisega vähe ühist. Tegelikult on isegi vastupidi. Andmebaasid teevad kõik endast oleneva, et anda juurdepääs neis hoitavatele andmetele. Need tulevad koos võimsa deklaratiivse liidese, mis võimaldab andmeid muuta nii, nagu soovite. See funktsionaalsus on oluline eeluurimisfaasis, kuid mitte pidevalt kasvava teenuse haldamiseks.

Siin tekib dilemma. Vasturääkivus. Dikotoomia. Sest infotehnoloogiad – see on andmete pakkumine, ja teenused – andmete varjamine.

Need two forces are fundamental. They underlie much of our work, constantly fighting for supremacy in the systems we create.

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.

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, let's just say it represents significant costly engineering and operational challenges for a company trying to use it.

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.

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.

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.

The more mutable the copies are, the more the data will differ over time.

What’s worse, such data is difficult to correct retrospectively (MDM 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.

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 nimetatakse neid andmeid "välisteks", ja see on väga oluline omadus. Me vajame kapseldamist, et mitte paljastada teenuse sisemist ülesehitust, kuid peame hõlbustama teenuste juurdepääsu jagatud andmetele, et nad saaksid oma tööd õigesti teha.

Probleem on selles, et ükski praegustest lähenemisviisidest ei ole enam asjakohane, kuna ei teenuse liidesed, juhuslikud teated ega jagatud andmebaasid ei paku head lahendust väliste andmete töötlemiseks. Teenuse liidesed ei sobi andmete vahetamiseks mingis ulatuses. Juhuslikud teated edastavad andmeid, kuid ei salvesta nende ajalugu, mistõttu andmed aja jooksul riknevad. Jagatud andmebaasid on liiga keskendunud ühele punktile, mis pidurdab edusamme. Me jääme paratamatult nõrkade andmete tsüklisse:

Nõrkade andmete tsükkel

Voogud: detsentraliseeritud lähenemine andmetele ja teenustele

Ideaalis peame muutma lähenemist sellele, kuidas teenused töötavad jagatud andmetega. Praegu seisavad kõik lähenemisviisid silmitsi ülaltoodud dikotoomiaga, kuna ei ole mingit maagilist pulbrit, millega saaksime selle lahendada. Siiski saame probleemi uuesti mõtestada ja leida kompromissi.

See kompromiss eeldab teatud määral tsentraliseerimist. Saame kasutada jaotatud logide mehhanismi, kuna see tagab usaldusväärsed ja skaleeritavad vood. Nüüd peab teenused saama liituda ja töötada nende jagatud voogudega, kuid soovime vältida keerulisi tsentraliseeritud Jumala teenuseid, mis teevad sellist töötlemist. Seetõttu on parim lahendus integreerida voogude töötlemine igasse teenusesse-kasutajasse. Nii saavad teenused kombineerida andmekogusid erinevatest allikatest ja töötada nendega nii, nagu nemad soovivad.

Üks võimalus sellise lähenemise saavutamiseks on voogude töötlemise platvormi kasutamine. Olemas on palju võimalusi, kuid täna vaatame just Kafka't, kuna selle Stateful Stream Processing kasutamine võimaldab tõhusalt lahendada esitatud probleemi.

Jaotatud logimise mehhanismi kasutamine võimaldab meil minna mööda rajatud rada ja kasutada juhuslikku teatevahetust, et töötada koos. üritus-suunaline arhitektuur. Sellise lähenemise eelduseks on parem skaleerimine ja jaotamine kui „küsi-vasta” mehhanism, kuna see annab vooluhalduse kontrolli saajale, mitte saatjale. Kuid kõike selles elus peab eest maksma, ja siin vajate brokerit. Suurte süsteemide puhul on see kompromiss seda väärt (mida ei saa öelda teie keskmiste veebirakenduste kohta).

Kui jaotatud logimine sõltub brokerist, mitte traditsioonilisest sõnumiteedest, siis saab kasutada täiendavaid funktsioone. Transporti saab lineaarselt skaleerida peaaegu sama hästi kui jaotatud failisüsteemi. Andmeid võib logides hoida piisavalt kaua, mistõttu saame mitte ainult sõnumite_exchange, vaid ka teabe säilitamise. Skaleeritav salvestus ilma hirmuta, et saada muudetav üldine olek.

Seejärel on võimalik kasutada stateful stream processing (olekuga voogude töötlemine) mehhanismi andmebaasi deklaratiivsete tööriistade lisamiseks tarbiteenustele. See on väga oluline mõte. Niikaua kui andmed on jagatud voogudes, millele kõik teenused saavad juurde pääseda, on teenuse poolne ühendamine ja töötlemine privaatne. Nad jäävad rangelt piiratud konteksti sees eraldatuks.

Vabanege andmete diktoomast, jagades muutumatud olekute vood. Seejärel lisage see funktsioon iga teenuse jaoks, kasutades stateful stream processing.

Seega, kui teie teenus peab töötama tellimustega, toote kataloogiga, laoga, on tal täielik juurdepääs: ainult teie otsustate, millised andmed ühendada, kus neid töödelda ja kuidas need aja jooksul muutuvad. Kuigi andmed on jagatud, on nende töötlemine täielikult detsentraliseeritud. Seda tehakse igas teenuses, maailmas, kus kõik käib teie reeglite järgi.

Jagage andmeid nii, et nende terviklikkus ei oleks rikutud. Kapselke funktsioon, mitte allikas, igas teenuses, kus seda vajatakse.

Tavaliselt juhtub, et andmeid tuleb massiliselt liigutada. Mõnikord vajab teenus valitud andmebaasi mootori kohaliku ajaloolise andmeseti. Oluline on, et vajadusel saab koopia taastada allikast, kasutades jaotatud logimise mehhanismi. Kafka ühendused teevad selle ülesande suurepäraselt ära.

Käesoleval lähenemisel on mitmeid eeliseid:

• Andmeid kasutatakse jagatud voogude kujul, mida saab pikka aega logides hoida, ning jagatud andmetega töötamine on iga konteksti sees, mis võimaldab teenustel töötada kiiresti ja tõhusalt. Sedasi saab tasakaalustada andmete dikotoomiat.
• Erinevatest teenustest pärinevaid andmeid on lihtne ühendada kogudeks. Nii lihtsustub ühiste andmetega töötamine ja kaob vajadus säilitada kohalikke andmesetteid andmebaasis.
• Stateful Stream Processing ainult vahemälestab andmeid, samas kui tõe allikaks jäävad jagatud logid, seega ei ole probleem andmete kahjustamisest ajas nii terav.
• Oma olemuselt juhivad teenuseid andmed, seega hoolimata andmemahtude pidevast kasvust saavad teenused siiski kiiresti reageerida äriüritustele.
• Skaalautuvuse probleemid lasuvad brokera peal, mitte teenustel. Nii väheneb teenuste kirjutamise keerukus, kuna ei ole vaja muretseda skaala üle.
• Uute teenuste lisamine ei nõua vanade muutmist, seetõttu muutub uute teenuste ühendamine lihtsamaks.

Nagu näete, on see rohkem kui lihtsalt REST. Oleme saanud tööriistade komplekti, mis võimaldab töötada jagatud andmetega detsentraliseeritult.

Käesolevas artiklis ei käsitletud kaugeltki kõiki aspekte. Peame endiselt välja selgitama, kuidas tasakaalustada päringu-vastuse paradigma ja sündmustest lähtuva paradigma vahel. Kuid sellega tegeleme järgmine kord. On teemasid, millega tuleb lähemalt tutvuda, näiteks, miks on Stateful Stream Processing nii hea. Sellest räägime kolmandas artiklis. Lisaks on olemas veel teisi võimsaid konstruktsioone, millest saame kasu, kui me neid ära kasutame, näiteks, Täpselt Üks Kord TöötlemineSelle abil muutuvad mängureeglid jagatud äri süsteemides, kuna see konstruktsioon tagab tehingu garantiid XA skaleeritavas vormis. Sellest räägitakse neljas artiklis. Ja lõpuks peame me kiirelt üle vaatama nende põhimõtete rakendamise/detailid.

Kuid praegu lihtsalt pidage meeles järgmist: andmete dikotoomia on see jõud, millega me silmitsi seisame äriteenuste loomisel. Ja me peame seda meeles pidama. Fookus on selles, et kõik pea peale keerata ja hakata nägema ühiseid andmeid esmaklassiliste objektidena. Stateful Stream Processing pakub selleks ainulaadset kompromissi. See väldib tsentraliseeritud "jumala komponente", mis pidurdavad edusamme. Veelgi enam, see tagab andmevoogude torustike operatiivsuse, skaleeritavuse ja veakindluse ning lisab need igasse teenusesse. Seetõttu saame keskenduda ühiselle teadlikkusele, millega iga teenus saab liituda ja mille andmete kallal töötada. Nii muutuvad teenused skaleeritavamaks, võrdselt asendatavateks ja iseseisvateks. Seetõttu näevad nad head välja mitte ainult märgistusplaatidel ja hüpoteeside testimisel, vaid töötavad ja arenevad ka aastakümneid.

Tutvu kursusega lähemalt.

Allikas: habr.com