Pershendetje te gjitheve! Kemi një lajm të shkëlqyeshëm, OTUS do të nisë përsëri kursin në qershor , në lidhje me të cilën ne tradicionalisht ndajmë materiale të dobishme me ju.
Nëse e keni hasur të gjithë këtë gjë të mikroshërbimeve pa ndonjë kontekst, do të faleshe të mendosh se është pak e çuditshme. Ndarja e një aplikacioni në fragmente të lidhura nga një rrjet do të thotë domosdoshmërisht shtimi i mënyrave komplekse të tolerancës së gabimeve në sistemin e shpërndarë që rezulton.
Edhe pse kjo qasje përfshin zbërthimin e saj në shumë shërbime të pavarura, qëllimi përfundimtar është shumë më tepër sesa thjesht ekzekutimi i këtyre shërbimeve në makina të ndryshme. Këtu po flasim për ndërveprim me botën e jashtme, i cili është i shpërndarë edhe në thelbin e tij. Jo në kuptimin teknik, por më tepër në kuptimin e një ekosistemi që përbëhet nga shumë njerëz, ekipe, programe dhe secila prej këtyre pjesëve duhet të bëjë disi punën e saj.
Kompanitë, për shembull, janë një koleksion sistemesh të shpërndara që kolektivisht kontribuojnë në arritjen e një qëllimi. Ne e kemi injoruar këtë fakt për dekada të tëra, duke u përpjekur të arrijmë unifikimin duke përdorur skedarë FTP ose duke përdorur mjetet e integrimit të ndërmarrjeve duke u fokusuar në qëllimet tona të izoluara. Por me ardhjen e shërbimeve, gjithçka ndryshoi. Shërbimet na kanë ndihmuar të shikojmë përtej horizontit dhe të shohim një botë programesh të ndërvarura që punojnë së bashku. Megjithatë, për të punuar me sukses, është e nevojshme të njihen dhe të dizajnohen dy botë thelbësisht të ndryshme: bota e jashtme, ku jetojmë në një ekosistem me shumë shërbime të tjera, dhe bota jonë personale, e brendshme, ku sundojmë të vetëm.
Kjo botë e shpërndarë është e ndryshme nga ajo në të cilën jemi rritur dhe jemi mësuar. Parimet e ndërtimit të arkitekturës tradicionale monolitike nuk i qëndrojnë kritikave. Pra, vendosja e duhur e këtyre sistemeve ka të bëjë më shumë sesa krijimi i një diagrami të lezetshëm të tabelës së bardhë ose një provë e mirë e konceptit. Çështja është të sigurohet që një sistem i tillë të funksionojë me sukses për një periudhë të gjatë kohore. Për fat të mirë, shërbimet kanë ekzistuar për mjaft kohë, megjithëse duken ndryshe. janë ende të rëndësishme, madje të kalitur me Docker, Kubernetes dhe mjekra pak të rreme hipster.
Kështu që sot do të shohim se si kanë ndryshuar rregullat, pse duhet të rimendojmë mënyrën se si i qasemi shërbimeve dhe të dhënave që ato i kalojnë njëri-tjetrit dhe pse do të na duhen mjete krejtësisht të ndryshme për ta bërë këtë.
Enkapsulimi nuk do të jetë gjithmonë miku juaj
Mikroshërbimet mund të funksionojnë në mënyrë të pavarur nga njëri-tjetri. Është kjo pronë që u jep vlerën më të madhe. E njëjta pronë lejon që shërbimet të rriten dhe të rriten. Jo aq shumë në kuptimin e shkallëzimit në katër miliarda përdorues ose petabajt të të dhënave (edhe pse ato mund të ndihmojnë edhe atje), por në kuptimin e shkallëzimit për sa i përket njerëzve pasi ekipet dhe organizatat rriten vazhdimisht.
Megjithatë, pavarësia është një thikë me dy tehe. Kjo do të thotë, vetë shërbimi mund të funksionojë lehtësisht dhe natyrshëm. Por nëse një funksion zbatohet brenda një shërbimi që kërkon përdorimin e një shërbimi tjetër, atëherë ne përfundojmë që të bëjmë ndryshime në të dy shërbimet pothuajse njëkohësisht. Në një monolit kjo është e lehtë për t'u bërë, thjesht bëni një ndryshim dhe dërgoni atë në lëshim, por në rastin e sinkronizimit të shërbimeve të pavarura do të ketë më shumë probleme. Koordinimi midis ekipeve dhe cikleve të lëshimit shkatërron shkathtësinë.
Si pjesë e qasjes standarde, ata thjesht përpiqen të shmangin ndryshimet e bezdisshme nga fundi në fund, duke ndarë qartë funksionalitetin midis shërbimeve. Shërbimi i hyrjes së vetme mund të jetë një shembull i mirë këtu. Ai ka një rol të përcaktuar qartë që e dallon atë nga shërbimet e tjera. Kjo ndarje e qartë do të thotë se në një botë me kërkesa që ndryshojnë me shpejtësi për shërbimet rreth tij, shërbimi i vetëm i hyrjes nuk ka gjasa të ndryshojë. Ai ekziston brenda një konteksti rreptësisht të kufizuar.
Problemi është se në botën reale, shërbimet e biznesit nuk mund të mbajnë të njëjtën ndarje të pastër të roleve gjatë gjithë kohës. Për shembull, të njëjtat shërbime biznesi funksionojnë në një masë më të madhe me të dhënat që vijnë nga shërbime të tjera të ngjashme. Nëse jeni i përfshirë në shitje me pakicë në internet, atëherë përpunimi i rrjedhës së porosive, katalogut të produkteve ose informacionit të përdoruesit do të bëhet një kërkesë për shumë nga shërbimet tuaja. Secili prej shërbimeve do të ketë nevojë për qasje në këto të dhëna për të funksionuar.
Shumica e shërbimeve të biznesit ndajnë të njëjtën rrjedhë të dhënash, kështu që puna e tyre është e ndërthurur pa ndryshim.
Kështu kemi ardhur në një pikë të rëndësishme për të cilën ia vlen të flasim. Ndërsa shërbimet funksionojnë mirë për komponentët e infrastrukturës që funksionojnë kryesisht në izolim, shumica e shërbimeve të biznesit përfundojnë duke u ndërthurur shumë më ngushtë.
Dikotomia e të dhënave
Qasjet e orientuara nga shërbimi mund të ekzistojnë tashmë, por ende nuk kanë njohuri se si të ndajnë sasi të mëdha të dhënash midis shërbimeve.
Problemi kryesor është se të dhënat dhe shërbimet janë të pandashme. Nga njëra anë, kapsulimi na inkurajon të fshehim të dhënat në mënyrë që shërbimet të mund të ndahen nga njëra-tjetra dhe të lehtësojnë rritjen e tyre dhe ndryshimet e mëtejshme. Nga ana tjetër, ne duhet të jemi në gjendje të ndajmë dhe të pushtojmë lirshëm të dhënat e përbashkëta, ashtu si çdo e dhënë tjetër. Çështja është që të mund të filloni punën menjëherë, aq lirshëm si në çdo sistem tjetër informacioni.
Megjithatë, sistemet e informacionit kanë pak të bëjnë me kapsulimin. Në fakt, është krejt e kundërta. Bazat e të dhënave bëjnë gjithçka që munden për të siguruar akses në të dhënat që ruajnë. Ato vijnë me një ndërfaqe të fuqishme deklarative që ju lejon të modifikoni të dhënat sipas nevojës. Një funksionalitet i tillë është i rëndësishëm në fazën paraprake të kërkimit, por jo për menaxhimin e kompleksitetit në rritje të një shërbimi vazhdimisht në zhvillim.
Dhe këtu lind një dilemë. Kontradikta. Dikotomia. Në fund të fundit, sistemet e informacionit kanë të bëjnë me sigurimin e të dhënave, dhe shërbimet kanë të bëjnë me fshehjen.
Këto dy forca janë themelore. Ata mbështesin pjesën më të madhe të punës sonë, duke luftuar vazhdimisht për përsosmëri në sistemet që ndërtojmë.
Ndërsa sistemet e shërbimeve rriten dhe evoluojnë, ne shohim pasojat e dikotomisë së të dhënave në shumë mënyra. Ose ndërfaqja e shërbimit do të rritet, duke ofruar një gamë funksionaliteti gjithnjë në rritje dhe do të fillojë të duket si një bazë të dhënash shumë e zbukuruar e krijuar nga shtëpia, ose ne do të zhgënjehemi dhe do të zbatojmë një mënyrë për të tërhequr ose zhvendosur në masë grupe të tëra të dhënash nga shërbimi në shërbim.
Nga ana tjetër, krijimi i diçkaje që duket si një bazë të dhënash të bukura shtëpiake do të çojë në një mori problemesh. Nuk do të hyjmë në detaje se pse është e rrezikshme bazën e të dhënave të përbashkët, le të themi vetëm se ai përfaqëson inxhinieri dhe funksionalitet të kushtueshëm për kompaninë që po përpiqet ta përdorë atë.
Ajo që është më e keqja është se vëllimet e të dhënave zmadhojnë problemet e kufirit të shërbimit. Sa më shumë të dhëna të përbashkëta të jenë brenda një shërbimi, aq më komplekse do të bëhet ndërfaqja dhe aq më e vështirë do të jetë kombinimi i grupeve të të dhënave që vijnë nga shërbime të ndryshme.
Qasja alternative e nxjerrjes dhe lëvizjes së të gjitha grupeve të të dhënave ka gjithashtu problemet e veta. Një qasje e zakonshme ndaj kësaj pyetjeje duket si thjesht marrja dhe ruajtja e të gjithë grupit të të dhënave, dhe më pas ruajtja e tij në nivel lokal në çdo shërbim konsumues.
Problemi është se shërbime të ndryshme interpretojnë ndryshe të dhënat që konsumojnë. Këto të dhëna janë gjithmonë pranë. Ato modifikohen dhe përpunohen në nivel lokal. Shumë shpejt ata pushojnë së paturi asgjë të përbashkët me të dhënat në burim.
Sa më të ndryshueshme të jenë kopjet, aq më shumë të dhënat do të ndryshojnë me kalimin e kohës.
Për t'i bërë gjërat edhe më keq, të dhëna të tilla është e vështirë të korrigjohen në retrospektivë ( Këtu mund të vijë me të vërtetë në shpëtim). Në fakt, disa nga problemet e pazgjidhshme të teknologjisë me të cilat përballen bizneset lindin nga të dhënat e ndryshme që shumohen nga aplikacioni në aplikim.
Për të gjetur një zgjidhje për këtë problem, duhet të mendojmë ndryshe për të dhënat e përbashkëta. Ato duhet të bëhen objekte të klasit të parë në arkitekturat që ne ndërtojmë. i quan të dhëna të tilla "të jashtme", dhe kjo është një veçori shumë e rëndësishme. Ne kemi nevojë për kapsulim në mënyrë që të mos ekspozojmë funksionimin e brendshëm të një shërbimi, por duhet t'ua bëjmë më të lehtë shërbimeve qasjen në të dhënat e përbashkëta në mënyrë që ata të mund të kryejnë punën e tyre në mënyrë korrekte.
Problemi është se asnjë qasje nuk është e rëndësishme sot, pasi as ndërfaqet e shërbimit, as mesazhet, as Baza e të dhënave të përbashkëta nuk ofrojnë një zgjidhje të mirë për të punuar me të dhëna të jashtme. Ndërfaqet e shërbimit nuk janë të përshtatshme për shkëmbimin e të dhënave në çdo shkallë. Mesazhimi lëviz të dhënat, por nuk ruan historinë e tyre, kështu që të dhënat korruptohen me kalimin e kohës. Bazat e përbashkëta të të dhënave fokusohen shumë në një pikë, gjë që pengon përparimin. Ne në mënyrë të pashmangshme ngecim në një cikël dështimi të të dhënave:
Cikli i dështimit të të dhënave
Rrjedhat: një qasje e decentralizuar ndaj të dhënave dhe shërbimeve
Në mënyrë ideale, ne duhet të ndryshojmë mënyrën se si funksionojnë shërbimet me të dhëna të përbashkëta. Në këtë pikë, çdo qasje përballet me dikotominë e lartpërmendur, pasi nuk ka pluhur magjik që mund të spërkatet mbi të për ta zhdukur. Megjithatë, ne mund ta rimendojmë problemin dhe të arrijmë një kompromis.
Ky kompromis përfshin një shkallë të caktuar të centralizimit. Ne mund të përdorim mekanizmin e regjistrit të shpërndarë sepse ofron transmetime të besueshme dhe të shkallëzueshme. Tani duam që shërbimet të jenë në gjendje të bashkohen dhe të funksionojnë në këto tema të përbashkëta, por duam të shmangim Shërbimet komplekse të centralizuara të Zotit që bëjnë këtë përpunim. Prandaj, alternativa më e mirë është të ndërtoni përpunimin e rrjedhës në çdo shërbim të konsumatorit. Në këtë mënyrë, shërbimet do të jenë në gjendje të kombinojnë grupe të dhënash nga burime të ndryshme dhe të punojnë me to sipas nevojës.
Një mënyrë për të arritur këtë qasje është përdorimi i një platforme transmetimi. Ka shumë opsione, por sot do të shikojmë Kafkën, pasi përdorimi i Përpunimit të Rrjedhës Shtetërore të tij na lejon të zgjidhim në mënyrë efektive problemin e paraqitur.
Përdorimi i një mekanizmi të prerjeve të shpërndara na lejon të ndjekim rrugën e shkelur mirë dhe të përdorim mesazhet për të punuar me . Kjo qasje konsiderohet të sigurojë shkallëzim dhe ndarje më të mirë sesa mekanizmi i përgjigjes së kërkesës, sepse i jep kontrollin e rrjedhës marrësit dhe jo dërguesit. Sidoqoftë, për gjithçka në këtë jetë duhet të paguani, dhe këtu keni nevojë për një ndërmjetës. Por për sistemet e mëdha, kompensimi ia vlen (gjë që mund të mos jetë rasti për aplikacionin tuaj mesatar në ueb).
Nëse një ndërmjetës është përgjegjës për prerjet e shpërndara në vend të një sistemi tradicional të mesazheve, ju mund të përfitoni nga veçori shtesë. Transporti mund të shkallëzohet në mënyrë lineare pothuajse si dhe një sistem skedari i shpërndarë. Të dhënat mund të ruhen në regjistra për një kohë mjaft të gjatë, kështu që ne marrim jo vetëm shkëmbimin e mesazheve, por edhe ruajtjen e informacionit. Ruajtje e shkallëzuar pa frikën e gjendjes së përbashkët të ndryshueshme.
Më pas mund të përdorni përpunimin e transmetimit të gjendjes për të shtuar mjete deklarative të bazës së të dhënave në shërbimet konsumuese. Kjo është një ide shumë e rëndësishme. Ndërsa të dhënat ruhen në transmetime të përbashkëta ku të gjitha shërbimet mund të kenë akses, grumbullimi dhe përpunimi që bën shërbimi është privat. Ata e gjejnë veten të izoluar brenda një konteksti rreptësisht të kufizuar.
Eliminoni dikotominë e të dhënave duke ndarë rrjedhën e gjendjes së pandryshueshme. Më pas shtojeni këtë funksionalitet në çdo shërbim duke përdorur Përpunimin Stream Stateful.
Kështu, nëse shërbimi juaj duhet të punojë me porosi, një katalog produktesh, një magazinë, ai do të ketë akses të plotë: vetëm ju do të vendosni se cilat të dhëna të kombinoni, ku t'i përpunoni dhe si duhet të ndryshojnë me kalimin e kohës. Përkundër faktit se të dhënat ndahen, puna me të është plotësisht e decentralizuar. Prodhohet brenda çdo shërbimi, në një botë ku gjithçka shkon sipas rregullave tuaja.
Ndani të dhënat pa cenuar integritetin e tyre. Përfshini funksionin, jo burimin, në çdo shërbim që ka nevojë për të.
Ndodh që të dhënat duhet të zhvendosen masivisht. Ndonjëherë një shërbim kërkon një grup të dhënash historike lokale në motorin e zgjedhur të bazës së të dhënave. Truku është se ju mund të garantoni që, nëse është e nevojshme, një kopje mund të rikthehet nga burimi duke hyrë në mekanizmin e prerjeve të shpërndara. Lidhësit në Kafka bëjnë një punë të shkëlqyer për këtë.
Pra, qasja e diskutuar sot ka disa përparësi:
- Të dhënat përdoren në formën e rrymave të zakonshme, të cilat mund të ruhen në regjistra për një kohë të gjatë, dhe mekanizmi për të punuar me të dhëna të zakonshme është i lidhur në çdo kontekst individual, gjë që lejon shërbimet të punojnë lehtësisht dhe shpejt. Në këtë mënyrë, dikotomia e të dhënave mund të balancohet.
- Të dhënat që vijnë nga shërbime të ndryshme mund të kombinohen lehtësisht në grupe. Kjo thjeshton ndërveprimin me të dhënat e përbashkëta dhe eliminon nevojën për të ruajtur grupet e të dhënave lokale në bazën e të dhënave.
- Stateful Stream Processing ruan vetëm të dhënat dhe burimi i së vërtetës mbeten regjistrat e përgjithshëm, kështu që problemi i prishjes së të dhënave me kalimin e kohës nuk është aq i mprehtë.
- Në thelbin e tyre, shërbimet drejtohen nga të dhënat, që do të thotë se pavarësisht vëllimeve gjithnjë në rritje të të dhënave, shërbimet ende mund t'i përgjigjen shpejt ngjarjeve të biznesit.
- Çështjet e shkallëzimit bien mbi ndërmjetësin, jo shërbimet. Kjo zvogëlon ndjeshëm kompleksitetin e shërbimeve të shkrimit, pasi nuk ka nevojë të mendoni për shkallëzueshmërinë.
- Shtimi i shërbimeve të reja nuk kërkon ndryshimin e të vjetrave, kështu që lidhja e shërbimeve të reja bëhet më e lehtë.
Siç mund ta shihni, kjo është më shumë sesa thjesht PJESË. Ne kemi marrë një grup mjetesh që ju lejojnë të punoni me të dhëna të përbashkëta në një mënyrë të decentralizuar.
Jo të gjitha aspektet u trajtuan në artikullin e sotëm. Ne ende duhet të kuptojmë se si të balancojmë midis paradigmës kërkesë-përgjigje dhe paradigmës së drejtuar nga ngjarjet. Por ne do të merremi me këtë herën tjetër. Ka tema që duhet t'i njihni më mirë, për shembull, pse përpunimi i rrjedhës shtetërore është kaq i mirë. Ne do të flasim për këtë në artikullin e tretë. Dhe ka konstruksione të tjera të fuqishme nga të cilat ne mund të përfitojmë nëse u drejtohemi atyre, për shembull, . Është një ndërrues i lojës për sistemet e biznesit të shpërndarë sepse ofron garanci transaksionale për në një formë të shkallëzuar. Kjo do të diskutohet në artikullin e katërt. Së fundi, do të na duhet të kalojmë në detajet e zbatimit të këtyre parimeve.
Por tani për tani, vetëm mbani mend këtë: dikotomia e të dhënave është një forcë me të cilën përballemi kur ndërtojmë shërbime biznesi. Dhe ne duhet ta kujtojmë këtë. Truku është të ktheni gjithçka në kokë dhe të filloni t'i trajtoni të dhënat e përbashkëta si objekte të klasit të parë. Përpunimi Stateful Stream ofron një kompromis unik për këtë. Ai shmang "Përbërësit e Zotit" të centralizuar që pengojnë përparimin. Për më tepër, ai siguron shkathtësinë, shkallëzimin dhe elasticitetin e tubacioneve të transmetimit të të dhënave dhe i shton ato në çdo shërbim. Prandaj, ne mund të përqendrohemi në rrjedhën e përgjithshme të vetëdijes me të cilën çdo shërbim mund të lidhet dhe të punojë me të dhënat e tij. Kjo i bën shërbimet më të shkallëzueshme, të këmbyeshme dhe autonome. Pra, ata jo vetëm që do të duken mirë në tabelat e bardha dhe testet e hipotezave, por gjithashtu do të funksionojnë dhe evoluojnë për dekada.
Burimi: www.habr.com