Sveiki visi! Turime puikių naujienų – birželio mėnesį OTUS vėl pradeda kursus , su kuriuo mes tradiciškai dalijamės naudinga medžiaga.
Jei susidūrėte su šiuo mikro paslaugų dalyku be jokio konteksto, jums bus atleista, kad manote, kad tai šiek tiek keista. Programos padalijimas į fragmentus, sujungtus tinklu, būtinai reiškia sudėtingų gedimų tolerancijos režimų įtraukimą į gautą paskirstytą sistemą.
Nors šis metodas apima jo suskirstymą į daugybę nepriklausomų paslaugų, galutinis tikslas yra daug daugiau nei tik tų paslaugų teikimas skirtinguose įrenginiuose. Čia kalbame apie sąveiką su išoriniu pasauliu, kuri taip pat yra paskirstyta savo esme. Ne technine prasme, o ekosistemos, kurią sudaro daugybė žmonių, komandų, programų, ir kiekviena iš šių dalių kažkaip turi atlikti savo darbą, prasme.
Pavyzdžiui, įmonės yra paskirstytų sistemų rinkinys, kuris kartu prisideda prie kokio nors tikslo pasiekimo. Dešimtmečius ignoravome šį faktą, bandydami pasiekti suvienodinimą naudodami FTP failus arba naudodami įmonės integravimo įrankius, sutelkdami dėmesį į savo atskirus tikslus. Tačiau atsiradus paslaugoms viskas pasikeitė. Paslaugos padėjo mums pažvelgti už horizonto ir pamatyti tarpusavyje susijusių programų, veikiančių kartu, pasaulį. Tačiau norint sėkmingai dirbti, būtina atpažinti ir suprojektuoti du iš esmės skirtingus pasaulius: išorinį pasaulį, kuriame gyvename daugelio kitų paslaugų ekosistemoje, ir savo asmeninį, vidinį pasaulį, kuriame valdome vieni.
Šis paskirstytas pasaulis skiriasi nuo to, kuriame užaugome ir esame įpratę. Tradicinės monolitinės architektūros konstravimo principai neatlaiko kritikos. Taigi, norint tinkamai sukurti šias sistemas, reikia daugiau nei sukurti šaunią lentos diagramą ar puikų koncepcijos įrodymą. Esmė – užtikrinti, kad tokia sistema sėkmingai veiktų ilgą laiką. Laimei, paslaugos egzistuoja jau gana seniai, nors atrodo kitaip. tebėra aktualūs, net pagardinti Docker, Kubernetes ir šiek tiek nušiurusiomis hipsteriškomis barzdomis.
Taigi šiandien pažvelgsime į tai, kaip pasikeitė taisyklės, kodėl turime permąstyti požiūrį į paslaugas ir duomenis, kuriuos jos perduoda viena kitai, ir kodėl mums reikės visiškai skirtingų įrankių.
Inkapsuliacija ne visada bus jūsų draugas
Mikropaslaugos gali veikti nepriklausomai viena nuo kitos. Būtent šis turtas suteikia jiems didžiausią vertę. Ta pati nuosavybė leidžia paslaugoms plėsti ir augti. Ne tiek mastelio keitimas iki kvadrilijonų vartotojų ar petabaitų duomenų (nors jie taip pat gali padėti), bet ir žmonių mastelio keitimas, kai komandos ir organizacijos nuolat auga.
Tačiau nepriklausomybė yra dviašmenis kardas. Tai yra, pati paslauga gali veikti lengvai ir natūraliai. Bet jei funkcija yra įdiegta paslaugoje, kuriai reikia naudoti kitą paslaugą, galiausiai turime atlikti abiejų paslaugų pakeitimus beveik vienu metu. Monolite tai padaryti lengva, tereikia atlikti pakeitimą ir išsiųsti jį išleisti, tačiau sinchronizuojant nepriklausomas paslaugas kils daugiau problemų. Komandų ir išleidimo ciklų koordinavimas naikina judrumą.
Taikant standartinį metodą, jie tiesiog stengiasi išvengti erzinančių galutinių pakeitimų, aiškiai paskirstydami funkcionalumą tarp paslaugų. Vieno prisijungimo paslauga gali būti geras pavyzdys. Jis turi aiškiai apibrėžtą vaidmenį, kuris išskiria jį iš kitų paslaugų. Šis aiškus atskyrimas reiškia, kad pasaulyje, kai aplinkinių paslaugų poreikiai greitai kinta, vieno prisijungimo paslauga greičiausiai nepasikeis. Jis egzistuoja griežtai ribotame kontekste.
Problema ta, kad realiame pasaulyje verslo paslaugos negali visą laiką išlaikyti tokio paties gryno vaidmenų atskyrimo. Pavyzdžiui, tos pačios verslo paslaugos labiau veikia su duomenimis, gaunamais iš kitų panašių paslaugų. Jei užsiimate mažmenine prekyba internetu, užsakymų srauto, produktų katalogo ar vartotojo informacijos apdorojimas taps daugelio jūsų paslaugų reikalavimu. Kiekvienai paslaugai reikės prieigos prie šių duomenų, kad veiktų.
Dauguma verslo paslaugų naudoja tą patį duomenų srautą, todėl jų darbas visada yra susipynęs.
Taigi mes priėjome prie svarbaus dalyko, apie kurį verta kalbėti. Nors paslaugos gerai veikia infrastruktūros komponentams, kurie daugiausia veikia atskirai, dauguma verslo paslaugų yra daug glaudžiau susipynusios.
Duomenų dichotomija
Į paslaugas orientuotų metodų jau gali būti, tačiau jiems vis dar trūksta supratimo, kaip dalytis dideliais duomenų kiekiais tarp paslaugų.
Pagrindinė problema yra ta, kad duomenys ir paslaugos yra neatsiejami. Viena vertus, inkapsuliavimas skatina slėpti duomenis, kad paslaugos būtų atskirtos viena nuo kitos ir palengvintų jų augimą bei tolimesnius pokyčius. Kita vertus, turime turėti galimybę laisvai dalyti ir užkariauti bendrinamus duomenis, kaip ir bet kuriuos kitus duomenis. Esmė ta, kad būtų galima iš karto pradėti dirbti taip pat laisvai, kaip ir bet kurioje kitoje informacinėje sistemoje.
Tačiau informacinės sistemos turi mažai ką bendro su inkapsuliavimu. Tiesą sakant, yra visiškai priešingai. Duomenų bazės daro viską, ką gali, kad suteiktų prieigą prie saugomų duomenų. Juose yra galinga deklaratyvi sąsaja, leidžianti keisti duomenis pagal poreikį. Toks funkcionalumas yra svarbus preliminaraus tyrimo etape, bet ne siekiant valdyti didėjantį nuolat besikeičiančios paslaugos sudėtingumą.
Ir čia iškyla dilema. Prieštaravimas. Dichotomija. Juk informacinės sistemos – tai duomenų teikimas, o paslaugos – slėpimas.
Šios dvi jėgos yra pagrindinės. Jie yra mūsų darbo pagrindas, nuolat kovodami už mūsų kuriamų sistemų tobulumą.
Paslaugų sistemoms augant ir tobulėjant, duomenų dichotomijos pasekmes matome įvairiais būdais. Arba paslaugų sąsaja išaugs, teikdama vis didesnį funkcionalumą ir pradės atrodyti kaip labai prašmatni naminė duomenų bazė, arba nusivilsime ir įgyvendinsime kokį nors būdą masiškai atkurti ar perkelti ištisus duomenų rinkinius iš paslaugos į paslaugą.
Savo ruožtu kuriant kažką, kas atrodo kaip išgalvota namų duomenų bazė, kils daugybė problemų. Mes nesigilinsime į detales, kodėl tai pavojinga bendra duomenų bazė, sakykime, kad tai labai brangiai kainuojanti inžinerija ir eksploatacija įmonei, kuri bando juo naudotis.
Dar blogiau yra tai, kad duomenų kiekiai padidina paslaugų ribų problemas. Kuo daugiau bendrinamų duomenų yra paslaugoje, tuo sudėtingesnė bus sąsaja ir tuo sunkiau bus sujungti iš skirtingų paslaugų gaunamus duomenų rinkinius.
Alternatyvus būdas išgauti ir perkelti visus duomenų rinkinius taip pat turi savo problemų. Įprastas požiūris į šį klausimą atrodo taip, kad paprasčiausiai reikia gauti ir išsaugoti visą duomenų rinkinį, o tada saugoti jį vietoje kiekvienoje naudojančioje paslaugoje.
Problema ta, kad skirtingos tarnybos skirtingai interpretuoja sunaudojamus duomenis. Šie duomenys visada yra po ranka. Jie modifikuojami ir apdorojami vietoje. Gana greitai jie nustoja turėti nieko bendro su šaltinio duomenimis.
Kuo kintamesnės kopijos, tuo labiau laikui bėgant duomenys skirsis.
Dar blogiau, tokius duomenis retrospektyviai ištaisyti sunku ( Čia jis tikrai gali padėti). Tiesą sakant, kai kurios sunkiai įveikiamos technologijų problemos, su kuriomis susiduria įmonės, kyla dėl skirtingų duomenų, kurie dauginasi įvairiose programose.
Norėdami rasti šios problemos sprendimą, turime kitaip galvoti apie bendrinamus duomenis. Jie turi tapti aukščiausios klasės objektais mūsų kuriamose architektūrose. tokius duomenis vadina „išoriniais“, ir tai yra labai svarbi savybė. Mums reikia inkapsuliacijos, kad neatskleistume vidinio paslaugos veikimo, bet turime palengvinti tarnybų prieigą prie bendrinamų duomenų, kad jos galėtų tinkamai atlikti savo darbą.
Problema ta, kad nei vienas, nei kitas požiūris šiandien nėra aktualus, nes nei paslaugų sąsajos, nei pranešimų siuntimas, nei bendrinama duomenų bazė nėra geras sprendimas darbui su išoriniais duomenimis. Paslaugų sąsajos yra prastai pritaikytos keistis duomenimis bet kokiu mastu. Susirašinėjimas perkelia duomenis, bet nesaugo jų istorijos, todėl laikui bėgant duomenys sugadinami. Bendrinamos duomenų bazės per daug sutelkia dėmesį į vieną tašką, o tai stabdo pažangą. Neišvengiamai įstringame duomenų gedimo cikle:
Duomenų gedimo ciklas
Srautai: decentralizuotas požiūris į duomenis ir paslaugas
Idealiu atveju turime pakeisti paslaugų veikimo būdą su bendrai naudojamais duomenimis. Šiuo metu bet kuris požiūris susiduria su anksčiau minėtu dichotomija, nes ant jo nėra jokių stebuklingų dulkių, kurias būtų galima pabarstyti, kad jos išnyktų. Tačiau galime permąstyti problemą ir pasiekti kompromisą.
Šis kompromisas apima tam tikrą centralizaciją. Galime naudoti paskirstytą žurnalo mechanizmą, nes jis užtikrina patikimus, keičiamo dydžio srautus. Dabar norime, kad tarnybos galėtų prisijungti prie šių bendrų gijų ir veikti jose, tačiau norime išvengti sudėtingų centralizuotų Dievo tarnybų, kurios atlieka šį apdorojimą. Todėl geriausias pasirinkimas yra įtraukti srauto apdorojimą į kiekvieną vartotojų paslaugą. Tokiu būdu paslaugos galės sujungti duomenų rinkinius iš skirtingų šaltinių ir dirbti su jais taip, kaip reikia.
Vienas iš būdų pasiekti šį metodą yra naudoti srautinio perdavimo platformą. Yra daug variantų, tačiau šiandien pažvelgsime į Kafką, nes naudojant jos būsenos srauto apdorojimą galime efektyviai išspręsti pateiktą problemą.
Naudodami paskirstytą registravimo mechanizmą galime sekti numintą kelią ir dirbti su pranešimais . Manoma, kad šis metodas suteikia geresnį mastelio keitimą ir skaidymą nei užklausos-atsakymo mechanizmas, nes jis suteikia srauto kontrolę gavėjui, o ne siuntėjui. Tačiau už viską šiame gyvenime reikia mokėti, o čia reikia brokerio. Tačiau didelėms sistemoms kompromisas yra vertas (kas gali būti ne jūsų vidutinės žiniatinklio programos atveju).
Jei tarpininkas yra atsakingas už paskirstytą registravimą, o ne tradicinę pranešimų sistemą, galite pasinaudoti papildomomis funkcijomis. Transporto mastelis gali būti tiesinis beveik taip pat, kaip paskirstyta failų sistema. Duomenys žurnaluose gali būti saugomi gana ilgai, todėl gauname ne tik apsikeitimą žinutėmis, bet ir informacijos saugojimą. Keičiama saugykla, nebijant keičiamos bendros būsenos.
Tada galite naudoti būsenos srauto apdorojimą, kad įtrauktumėte deklaratyvius duomenų bazės įrankius prie naudojamų paslaugų. Tai labai svarbi mintis. Nors duomenys saugomi bendrinamuose srautuose, kuriuos gali pasiekti visos paslaugos, paslaugos kaupimas ir apdorojimas yra privatus. Jie atsiduria izoliuoti griežtai ribotame kontekste.
Pašalinkite duomenų dichotomiją, atskirdami nekintamą būsenos srautą. Tada pridėkite šią funkciją prie kiekvienos paslaugos naudodami būsenos srauto apdorojimą.
Taigi, jei jūsų tarnybai reikės dirbti su užsakymais, prekių katalogu, sandėliu, ji turės pilną prieigą: tik jūs nuspręsite, kokius duomenis sujungti, kur apdoroti ir kaip laikui bėgant jie turėtų keistis. Nepaisant to, kad duomenys yra bendrinami, darbas su jais yra visiškai decentralizuotas. Jis gaminamas kiekvienoje tarnyboje, pasaulyje, kuriame viskas vyksta pagal jūsų taisykles.
Bendrinkite duomenis nepažeisdami jų vientisumo. Kiekvienoje paslaugoje, kuriai jos reikia, įtraukite funkciją, o ne šaltinį.
Pasitaiko, kad duomenis reikia perkelti masiškai. Kartais paslaugai reikalingas vietinis istorinis duomenų rinkinys pasirinktame duomenų bazės variklyje. Apgaulė yra ta, kad galite garantuoti, kad prireikus kopiją galima atkurti iš šaltinio, naudojant paskirstytą registravimo mechanizmą. Kafkos jungtys puikiai tai atlieka.
Taigi šiandien aptartas metodas turi keletą privalumų:
- Duomenys naudojami bendrų srautų pavidalu, kurie gali būti saugomi žurnaluose ilgą laiką, o darbo su bendrais duomenimis mechanizmas yra prijungtas prie kiekvieno individualaus konteksto, o tai leidžia paslaugoms dirbti lengvai ir greitai. Tokiu būdu galima subalansuoti duomenų dichotomiją.
- Duomenys, gaunami iš skirtingų paslaugų, gali būti lengvai sujungti į rinkinius. Tai supaprastina sąveiką su bendrai naudojamais duomenimis ir pašalina poreikį duomenų bazėje išlaikyti vietinius duomenų rinkinius.
- „Stateful Stream Processing“ tik kaupia duomenis talpykloje, o tiesos šaltiniu išlieka bendrieji žurnalai, todėl laikui bėgant duomenų sugadinimo problema nėra tokia opi.
- Iš esmės paslaugos yra pagrįstos duomenimis, o tai reiškia, kad nepaisant nuolat didėjančio duomenų kiekio, paslaugos vis tiek gali greitai reaguoti į verslo įvykius.
- Mastelio keitimo problemos tenka brokeriui, o ne paslaugoms. Tai žymiai sumažina rašymo paslaugų sudėtingumą, nes nereikia galvoti apie mastelio keitimą.
- Pridedant naujas paslaugas nereikia keisti senųjų, todėl prisijungti prie naujų paslaugų tampa lengviau.
Kaip matote, tai daugiau nei tik POILSIS. Gavome įrankių rinkinį, leidžiantį dirbti su bendrai naudojamais duomenimis decentralizuotai.
Ne visi aspektai buvo aptarti šiandieniniame straipsnyje. Vis dar turime išsiaiškinti, kaip subalansuoti užklausos ir atsakymo paradigmą ir įvykiais pagrįstą paradigmą. Bet mes tai spręsime kitą kartą. Yra temų, kurias reikia geriau pažinti, pavyzdžiui, kodėl Stateful Stream Processing yra toks geras. Apie tai kalbėsime trečiame straipsnyje. Ir yra kitų galingų konstrukcijų, kuriomis galime pasinaudoti, jei jų pasinaudosime, pavyzdžiui, . Tai žaidimų keitiklis paskirstytoms verslo sistemoms, nes suteikia sandorių garantijas keičiamo dydžio formoje. Tai bus aptarta ketvirtame straipsnyje. Galiausiai turėsime peržvelgti šių principų įgyvendinimo detales.
Tačiau kol kas atminkite tai: duomenų dichotomija yra jėga, su kuria susiduriame kurdami verslo paslaugas. Ir mes turime tai atsiminti. Triukas yra viską apversti ant galvos ir pradėti bendrinamus duomenis laikyti pirmos klasės objektais. „Stateful Stream Processing“ yra unikalus kompromisas. Jis vengia centralizuotų „Dievo komponentų“, kurie stabdo pažangą. Be to, jis užtikrina duomenų srautinio perdavimo vamzdynų judrumą, mastelį ir atsparumą bei prideda juos prie kiekvienos paslaugos. Todėl galime sutelkti dėmesį į bendrą sąmonės srautą, prie kurio bet kuri tarnyba gali prisijungti ir dirbti su savo duomenimis. Dėl to paslaugos yra labiau keičiamos, keičiamos ir savarankiškesnės. Taigi jie ne tik gerai atrodys ant lentų ir hipotezių testų, bet ir veiks bei vystysis dešimtmečius.
Šaltinis: www.habr.com