Tere kõigile! Meil on häid uudiseid, OTUS käivitab juunis taas kursuse , millega seoses jagame teiega traditsiooniliselt kasulikku materjali.
Kui olete kogu selle mikroteenuste asjaga kokku puutunud ilma igasuguse kontekstita, antaks teile andeks, kui arvate, et see on veidi kummaline. Rakenduse jagamine võrguga ühendatud fragmentideks tähendab tingimata keerukate tõrketaluvuse režiimide lisamist saadud hajutatud süsteemile.
Kuigi see lähenemisviis hõlmab selle jaotamist paljudeks sõltumatuteks teenusteks, on lõppeesmärk palju enamat kui lihtsalt nende teenuste kasutamine erinevatel masinatel. Räägime siin suhtlemisest välismaailmaga, mis on samuti oma olemuselt hajutatud. Mitte tehnilises mõttes, vaid pigem ökosüsteemi mõttes, mis koosneb paljudest inimestest, meeskondadest, programmidest ja igaüks neist osadest peab kuidagi oma tööd tegema.
Näiteks ettevõtted on hajutatud süsteemide kogum, mis ühiselt aitavad kaasa mõne eesmärgi saavutamisele. Oleme seda fakti aastakümneid ignoreerinud, püüdes saavutada ühendamist FTP-failide abil või ettevõtte integratsioonitööriistade abil, keskendudes samal ajal oma eraldatud eesmärkidele. Kuid teenuste tulekuga muutus kõik. Teenused on aidanud meil vaadata horisondi taha ja näha vastastikku sõltuvate programmide maailma, mis töötavad koos. Edukaks tööks on aga vaja ära tunda ja kujundada kaks põhimõtteliselt erinevat maailma: välismaailm, kus elame paljude muude teenuste ökosüsteemis, ja meie isiklik, sisemaailm, kus valitseme üksi.
See hajutatud maailm erineb sellest, milles me üles kasvasime ja millega oleme harjunud. Traditsioonilise monoliitarhitektuuri konstrueerimise põhimõtted ei kannata kriitikat. Seega on nende süsteemide õigeks saamine midagi enamat kui laheda tahvli diagrammi või laheda kontseptsiooni tõestuse loomine. Eesmärk on tagada, et selline süsteem toimiks edukalt pika aja jooksul. Õnneks on teenused olnud juba mõnda aega, kuigi need näevad välja erinevad. on endiselt aktuaalsed, isegi maitsestatud Dockeri, Kubernetese ja veidi räbala hipsterihabemega.
Nii et täna vaatame, kuidas reeglid on muutunud, miks peame uuesti läbi mõtlema viisi, kuidas me teenustele läheneme ja milliseid andmeid nad üksteisele edastavad, ning miks vajame selleks täiesti erinevaid tööriistu.
Kapseldamine ei ole alati teie sõber
Mikroteenused võivad töötada üksteisest sõltumatult. Just see vara annab neile suurima väärtuse. See sama vara võimaldab teenuseid laiendada ja kasvada. Mitte niivõrd skaleerimise mõttes kvadriljonitele kasutajatele või petabaitidele andmemahtudele (kuigi need võivad ka seal abiks olla), vaid inimeste osas skaleerimise mõttes, kuna meeskonnad ja organisatsioonid kasvavad pidevalt.
Iseseisvus on aga kahe teraga mõõk. See tähendab, et teenus ise töötab lihtsalt ja loomulikult. Kuid kui funktsioon on rakendatud teenuse sees, mis nõuab mõne muu teenuse kasutamist, siis peame lõpuks tegema mõlemas teenuses muudatusi peaaegu samaaegselt. Monoliidis on seda lihtne teha, lihtsalt teete muudatuse ja saadate selle vabastamiseks, kuid sõltumatute teenuste sünkroonimise korral on probleeme rohkem. Koordineerimine meeskondade ja vabastamistsüklite vahel hävitab agility.
Tavalise lähenemisviisi osana püüavad nad lihtsalt vältida tüütuid täielikke muudatusi, jagades funktsioonid selgelt teenuste vahel. Ühekordse sisselogimise teenus võib siin olla hea näide. Sellel on selgelt määratletud roll, mis eristab seda teistest teenustest. See selge eraldamine tähendab, et maailmas, kus nõudmised ümbritsevatele teenustele on kiiresti muutumas, ei muutu ühekordse sisselogimise teenus tõenäoliselt. See eksisteerib rangelt piiratud kontekstis.
Probleem on selles, et reaalses maailmas ei suuda äriteenused kogu aeg säilitada sama puhast rollide lahusust. Näiteks töötavad samad äriteenused suuremal määral teistest sarnastest teenustest pärinevate andmetega. Kui tegelete veebijaemüügiga, muutub tellimuste voo, tootekataloogi või kasutajateabe töötlemine paljude teie teenuste jaoks kohustuslikuks. Kõik teenused vajavad toimimiseks juurdepääsu neile andmetele.
Enamik äriteenuseid jagavad sama andmevoogu, nii et nende töö on alati läbi põimunud.
Seega jõuame olulise punktini, millest tasub rääkida. Kuigi teenused toimivad hästi infrastruktuurikomponentide puhul, mis töötavad suures osas isoleeritult, on enamik äriteenuseid omavahel palju tihedamalt põimunud.
Andmete dihhotoomia
Teenusele orienteeritud lähenemisviisid võivad juba olemas olla, kuid neil puudub ikkagi ülevaade suurte andmemahtude jagamisest teenuste vahel.
Peamine probleem seisneb selles, et andmed ja teenused on lahutamatud. Ühest küljest julgustab kapseldamine meid andmeid peitma, et teenuseid saaks üksteisest eraldada ning hõlbustada nende kasvu ja edasisi muutusi. Teisest küljest peame saama jagatud andmeid vabalt jagada ja vallutada, nagu kõik muud andmed. Asi on selles, et saaks kohe tööle asuda, sama vabalt nagu igas teises infosüsteemis.
Infosüsteemidel on aga kapseldamisega vähe pistmist. Tegelikult on see täiesti vastupidine. Andmebaasid teevad kõik endast oleneva, et võimaldada juurdepääs salvestatud andmetele. Neil on võimas deklaratiivne liides, mis võimaldab teil andmeid vastavalt vajadusele muuta. Selline funktsionaalsus on oluline eeluuringute etapis, kuid mitte pidevalt areneva teenuse kasvava keerukuse juhtimiseks.
Ja siin tekib dilemma. Vastuolu. Dihhotoomia. Infosüsteemid on ju andmete pakkumiseks ja teenused peituvad.
Need kaks jõudu on põhilised. Need toetavad suurt osa meie tööst, võideldes pidevalt meie loodud süsteemide tipptaseme eest.
Kuna teenindussüsteemid kasvavad ja arenevad, näeme andmete dihhotoomia tagajärgi mitmel viisil. Kas teenuseliides kasvab, pakkudes järjest suuremat valikut funktsionaalsust ja hakkab välja nägema nagu väga uhke kodukasvatatud andmebaas, või siis oleme pettunud ja rakendame mingit viisi tervete andmekomplektide massiliseks hankimiseks või teisaldamiseks teenusest teenusesse.
Millegi loomine, mis näeb välja nagu väljamõeldud kodune andmebaas, toob omakorda kaasa hulga probleeme. Me ei hakka üksikasjalikult kirjeldama, miks see ohtlik on jagatud andmebaas, ütleme nii, et see on märkimisväärselt kulukas projekteerimine ja käitamine ettevõtte jaoks, kes üritab seda kasutada.
Veelgi hullem on see, et andmemahud suurendavad teenusepiiri probleeme. Mida rohkem jagatud andmeid on teenuse sees, seda keerulisemaks muutub liides ja seda keerulisem on erinevatest teenustest pärinevate andmekogumite kombineerimine.
Alternatiivsel lähenemisviisil tervete andmekogumite ekstraheerimiseks ja teisaldamiseks on samuti oma probleemid. Levinud lähenemine sellele küsimusele näeb välja nii, et kogu andmestiku lihtsalt otsitakse ja salvestatakse ning seejärel salvestatakse see igas tarbivas teenuses kohapeal.
Probleem on selles, et erinevad teenused tõlgendavad tarbitavaid andmeid erinevalt. Need andmed on alati käepärast. Neid muudetakse ja töödeldakse kohapeal. Üsna kiiresti lakkab neil allikas olevate andmetega midagi ühist olema.
Mida muutuvamad on koopiad, seda rohkem andmed aja jooksul muutuvad.
Asja teeb veelgi hullemaks see, et selliseid andmeid on tagantjärele raske parandada ( Siin võib see tõesti appi tulla). Tegelikult tekivad mõned ettevõtete silmitsi seisvad lahendamatud tehnoloogiaprobleemid erinevatest andmetest, mis korduvad rakenduseti.
Sellele probleemile lahenduse leidmiseks peame mõtlema jagatud andmetele teisiti. Nendest peavad saama meie ehitatavas arhitektuuris esmaklassilised objektid. nimetab selliseid andmeid "välisteks" ja see on väga oluline funktsioon. Vajame kapseldamist, et me ei paljastaks teenuse sisemisi toiminguid, kuid peame hõlbustama teenustele juurdepääsu jagatud andmetele, et nad saaksid oma tööd õigesti teha.
Probleem on selles, et kumbki lähenemine pole tänapäeval aktuaalne, kuna ei teenuseliidesed, sõnumivahetus ega jagatud andmebaas ei paku head lahendust väliste andmetega töötamiseks. Teenindusliidesed sobivad halvasti andmevahetuseks mis tahes ulatuses. Sõnumside teisaldab andmeid, kuid ei salvesta nende ajalugu, mistõttu andmed aja jooksul rikutakse. Jagatud andmebaasid keskenduvad liiga palju ühele punktile, mis pärsib edasiminekut. Me jääme paratamatult kinni andmetõrgete tsüklisse:
Andmete rikke tsükkel
Vood: detsentraliseeritud lähenemisviis andmetele ja teenustele
Ideaalis peame muutma viisi, kuidas teenused jagatud andmetega töötavad. Siinkohal seisab kumbki lähenemine silmitsi eelmainitud dihhotoomiaga, kuna pole maagilist tolmu, mida sellele puistata, et see kaoks. Siiski saame probleemi ümber mõelda ja kompromissile jõuda.
See kompromiss hõlmab teatud tsentraliseerimist. Saame kasutada hajutatud logimehhanismi, kuna see pakub usaldusväärseid, skaleeritavaid vooge. Nüüd tahame, et teenused saaksid nende jagatud lõimedega liituda ja nendega töötada, kuid me tahame vältida keerulisi tsentraliseeritud jumalateenistusi, mis seda töötlemist teevad. Seetõttu on parim valik lisada vootöötlus igasse tarbijateenusesse. Nii saavad teenused kombineerida erinevatest allikatest pärit andmekogumeid ja töötada nendega nii, nagu nad vajavad.
Üks viis selle lähenemisviisi saavutamiseks on voogedastusplatvormi kasutamine. Võimalusi on palju, kuid täna vaatame Kafkat, kuna selle Stateful Stream Processingi kasutamine võimaldab meil esitatud probleemi tõhusalt lahendada.
Hajutatud logimismehhanismi kasutamine võimaldab meil järgida sissetallatud rada ja kasutada töötamiseks sõnumivahetust . Seda lähenemisviisi peetakse parema skaleerimise ja jaotuse pakkumiseks kui päringu-vastuse mehhanism, kuna see annab voo kontrolli pigem vastuvõtjale kui saatjale. Kuid kõige eest siin elus peate maksma ja siin on vaja maaklerit. Kuid suurte süsteemide puhul on kompromiss seda väärt (mis ei pruugi teie keskmise veebirakenduse puhul nii olla).
Kui traditsioonilise sõnumsidesüsteemi asemel vastutab hajutatud logimise eest maakler, saate kasutada lisafunktsioone. Transporti saab lineaarselt skaleerida peaaegu sama hästi kui hajutatud failisüsteemi. Andmeid saab salvestada logidesse üsna pikka aega, nii et saame mitte ainult sõnumivahetuse, vaid ka teabe salvestamise. Skaleeritav salvestusruum, kartmata muutuvat jagatud olekut.
Seejärel saate kasutada olekupõhist vootöötlust, et lisada tarbimisteenustele deklaratiivseid andmebaasitööriistu. See on väga oluline idee. Kuigi andmed salvestatakse jagatud voogudesse, millele kõik teenused pääsevad juurde, on teenuse koondamine ja töötlemine privaatne. Nad leiavad end eraldatuna rangelt piiratud kontekstis.
Likvideerige andmete dihhotoomia, eraldades muutumatu olekuvoo. Seejärel lisage see funktsioon igale teenusele Stateful Stream Processing abil.
Seega, kui teie teenus peab töötama tellimuste, tootekataloogi, laoga, on sellel täielik juurdepääs: ainult teie otsustate, milliseid andmeid kombineerida, kus neid töödelda ja kuidas need aja jooksul muutuma peaksid. Vaatamata asjaolule, et andmeid jagatakse, on töö nendega täielikult detsentraliseeritud. Seda toodetakse igas teenuses maailmas, kus kõik käib teie reeglite järgi.
Jagage andmeid nende terviklikkust kahjustamata. Kapseldage funktsioon, mitte allikas, igas seda vajavas teenuses.
Juhtub, et andmeid tuleb massiliselt teisaldada. Mõnikord nõuab teenus valitud andmebaasimootoris kohalikku ajaloolist andmekogumit. Trikk on selles, et saate tagada, et vajadusel saab koopia allikast taastada, kasutades juurdepääsu hajutatud logimismehhanismile. Kafka konnektorid saavad sellega suurepäraselt hakkama.
Seega on täna käsitletud lähenemisviisil mitmeid eeliseid:
- Andmeid kasutatakse ühiste voogude kujul, mida saab pikka aega logides salvestada, ja ühiste andmetega töötamise mehhanism on igas individuaalses kontekstis ühendatud, mis võimaldab teenustel lihtsalt ja kiiresti töötada. Nii saab andmete dihhotoomiat tasakaalustada.
- Erinevatest teenustest pärinevaid andmeid saab hõlpsasti komplektideks kombineerida. See lihtsustab suhtlemist jagatud andmetega ja välistab vajaduse säilitada andmebaasis kohalikke andmekogumiid.
- Stateful Stream Processing salvestab andmed ainult vahemällu ja tõe allikaks jäävad üldised logid, seega pole andmete aja jooksul rikutud probleem nii terav.
- Teenused on oma põhiolemuselt andmepõhised, mis tähendab, et vaatamata üha suurenevale andmemahule suudavad teenused siiski ärisündmustele kiiresti reageerida.
- Skaleeritavusega seotud probleemid langevad maakleri, mitte teenuste õlule. See vähendab oluliselt kirjutamisteenuste keerukust, kuna pole vaja mõelda mastaapsuse peale.
- Uute teenuste lisamine ei nõua vanade vahetamist, seega muutub uute teenuste ühendamine lihtsamaks.
Nagu näete, on see midagi enamat kui lihtsalt PUHKUS. Oleme saanud tööriistakomplekti, mis võimaldab töötada jagatud andmetega detsentraliseeritud viisil.
Tänases artiklis ei käsitletud kõiki aspekte. Peame veel välja mõtlema, kuidas tasakaalustada päringu-vastuse paradigma ja sündmusepõhise paradigma vahel. Aga sellega tegeleme järgmine kord. On teemasid, mida tuleb paremini tundma õppida, näiteks miks Stateful Stream Processing on nii hea. Sellest räägime kolmandas artiklis. Ja on ka teisi võimsaid konstruktsioone, mida saame ära kasutada, kui me neid kasutame, näiteks . See on hajutatud ärisüsteemide mänguvahetaja, kuna see pakub tehingutagatisi skaleeritaval kujul. Seda arutatakse neljandas artiklis. Lõpuks peame läbi vaatama nende põhimõtete rakendamise üksikasjad.
Kuid praegu pidage meeles seda: andmete dihhotoomia on jõud, millega äriteenuste loomisel silmitsi seisame. Ja me peame seda meeles pidama. Nipp seisneb selles, et keeratakse kõik pea peale ja hakatakse jagatud andmeid käsitlema kui esmaklassilisi objekte. Stateful Stream Processing pakub selleks ainulaadset kompromissi. See väldib tsentraliseeritud "Jumala komponente", mis takistavad arengut. Lisaks tagab see andmevoogesituse torujuhtmete paindlikkuse, mastaapsuse ja vastupidavuse ning lisab need igale teenusele. Seetõttu saame keskenduda üldisele teadvusevoolule, millega iga teenus saab ühenduse luua ja oma andmetega töötada. See muudab teenused skaleeritavamaks, vahetatavamaks ja autonoomsemaks. Nii et need ei näe head välja mitte ainult tahvlitel ja hüpoteeside testimisel, vaid ka töötavad ja arenevad aastakümneid.
Allikas: www.habr.com