Përshëndetje të gjithëve! Kemi lajme të shkëlqyera, në qershor OTUS do të nisë sërish kursin , ndaj në mënyrë tradicionale po ndajmë me ju materiale të dobishme.
Nëse ju keni hasur në të gjithë këtë histori me mikroshërbimet pa asnjë kontekst, është e kuptueshme të mendoni se është paksa e çuditshme. Ndërprerja e një aplikacioni në fragmente, të lidhura mes tyre me një rrjet, domosdoshmërisht do të thotë shtim të mënyrave komplekse të qëndrueshmërisë në sistemin e shpërndarë që rezulton.
Megjithëse ky qasje përfshin ndarjen në shumë shërbime të pavarura, qëllimi përfundimtar është shumë më i madh se thjesht funksionimi i këtyre shërbimeve në makina të ndryshme. Bëhet fjalë për ndërveprimin me botën përreth, e cila në thelb gjithashtu është e shpërndarë. Jo në kuptimin teknik, por më tepër në kuptimin e ekosistemit, i cili përbëhet nga shumë njerëz, ekipe, programe, dhe secila nga këto pjesë duhet në një farë mënyre të përmbushë detyrat e saj.
Kompani, për shembull, përbëjnë një grup sistemesh të shpërndara, të cilat së bashku kontribuojnë në arritjen e një qëllimi. Ne e kemi injoruar këtë fakt për dekada, duke u përpjekur të arrijmë bashkimin, duke transferuar skedarë përmes FTP ose duke përdorur mjete integrimi korporativ, ndërkohë që përqendroheshim në qëllimet tona individuale. Por, me ardhjen e shërbimeve, gjithçka u ndryshua. Shërbimet na ndihmuan të shohim përtej horizontit dhe të shohim një botë programesh të ndërvarura, të cilat punojnë së bashku. Megjithatë, për të punuar me sukses, është e nevojshme të kuptojmë dhe të projektojmë dy botë esencialisht të ndryshme: bota e jashtme, ku jetojmë në një ekosistem të shumë shërbimeve të tjera, dhe bota jonë personale, të brendshme, ku sundojmë vetëm.
Një botë e tillë e shpërndarë ndryshon nga ajo në të cilën jemi rritur dhe me të cilën jemi mësuar. Principet e ndërtimit të arkitekturës tradicionale monolitike nuk mbajnë asnjë kritikë. Prandaj, kuptimi i saktë i këtyre sistemeve është diçka më shumë se sa një skemë të bukur në një tabelë me markerë të bardhë ose një provë të shkëlqyer konceptuese. Bëhet fjalë për të siguruar që një sistem i tillë të funksionojë me sukses për një kohë të gjatë. Fatmirësisht, shërbimet ekzistojnë prej një kohe të konsiderueshme, ndonëse duken ndryshe. janë akoma të rëndësishme, edhe pse të përzhitura me Docker, Kubernetes dhe pak të përbuzura nga mjekrat hipster.
Kështu, sot do të shohim se si janë ndryshuar rregullat, pse duhet ta ripërkufizojmë qasjen tonë ndaj shërbimeve dhe të dhënave që ato shkëmbejnë me njëri-tjetrin, dhe pse do na nevojitet një mjet krejtësisht i ndryshëm për këtë.
Enkapsulimi nuk do të jetë gjithmonë miku juaj
Mikroservisët mund të funksionojnë pavarësisht njëri-tjetrit. Pikërisht kjo veçori u jep atyre vlerën më të madhe. Kjo veçori gjithashtu lejon shërbimet të shkallëzohen dhe të rriten. Jo aq sa në kuptimin e shkallëzimit deri në kuadrilion përdoruesish ose petabajt të dhënash (edhe pse këtu mund të ndihmojnë), por më shumë në kuptimin e shkallëzimit në aspektin e njerëzve, për shkak se ekipet dhe organizatat rriten në mënyrë të vazhdueshme.
Megjithatë, pavarësia është një thikë me dy presa. Kështu që shërbimi vetë mund të funksionojë lehtësisht dhe pa probleme. Por nëse brenda shërbimit implementohet një funksion që kërkon të angazhojë një shërbim tjetër, në fund të fundit na duhet të bëjmë ndryshime në të dy shërbimet pothuajse në të njëjtën kohë. Në një monolit është e lehtë ta bësh këtë, thjesht bën një ndryshim dhe e lanson, ndërsa 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 fleksibilitetin.
Një qasje standarde për të shmangur ndryshimet e padëshiruara shpesh i ndan qartë funksionet midis shërbimeve. Një shërbim i vetëm i hyrjes në sistem këtu mund të jetë një shembull i mirë. Ai ka një rol të qartë të caktuar, që e ndan atë nga shërbimet e tjera. Ky ndarje e qartë do të thotë se, në një botë me kërkesa që ndryshojnë me shpejtësi, shërbimi i hyrjes në sistem ndoshta nuk do të përjetohet një ndryshim. Ai ekziston brenda një konteksti të rreptë të kufizuar.
Problemi është se, në botën reale, shërbimet e biznesit nuk mund të ruajnë gjithmonë një ndarje të qartë të rolit. Për shembull, këto shërbime shpesh punojnë me të dhëna që vijnë nga shërbime të ngjashme. Nëse merret me tregtinë elektronike, përpunimi i fluksit të porosive, katalogut të produkteve ose informacionit mbi përdoruesit do të bëhet një kërkesë për shumë nga shërbimet tuaja. Çdo shërbim do t'i duhet qasje në këto të dhëna për të bërë punën e tij.
Shumica e shërbimeve të biznesit përdorin të njëjtin fluks të të dhënave, prandaj puna e tyre është gjithmonë e ndërthurur.
Kështu arritëm në një moment të rëndësishëm për të diskutuar. Ndërsa shërbimet funksionojnë mirë për komponentët e infrastrukturës që operojnë në mënyrë të veçuar, shumica e shërbimeve biznesore janë më shumë të ndërthurura.
Dihotomizmi i të dhënave
Qasjet e orientuara nga shërbimet mund të ekzistojnë tashmë, megjithatë ende ka pak informacion se si të shkëmbehen sasi të mëdha të të dhënave midis shërbimeve.
Problemi kryesor është se të dhënat dhe shërbimet janë të pandarë. Nga njëra anë, enkapsulimi na fton të fshehim të dhënat në mënyrë që shërbimet të mund të ndahen nga njëra-tjetra, duke lehtësuar rritjen dhe ndryshimet e tyre të mëvonshme. Nga ana tjetër, na nevojitet të kemi mundësinë për të ndarë dhe zotëruar të dhënat e përbashkëta me lehtësi, ashtu si çdo informacion tjetër. Kjo ka të bëjë me mundësinë për të nisur punën menjëherë, po aq lirshëm sa në çdo sistem tjetër informacioni.
Megjithatë, sistemet informative kanë pak të bëjnë me inkapsulimin. Në fakt, pikërisht e kundërta është e vërtetë. Të dhënat bëjnë çfarë të munden për të ofruar qasje në informacionin e ruajtur. Ato vijnë me një ndërfaqe të fuqishme deklarative që lejon modifikimin e të dhënave sipas nevojës tuaj. Ky funksionalitet është i rëndësishëm në fazën e hulumtimit paraprak, por jo për menaxhimin e kompleksitetit në rritje të një shërbimi që po zhvillohet vazhdimisht.
Dhe këtu shfaqet dilema. Kundërshtimi. Dihotomija. Sepse sistemet informative janë për ofrimin e të dhënave, ndërsa shërbimet janë për fshehjen e tyre.
Këto dy forca janë themelore. Ato qëndrojnë në bazë të shumicës së punës tonë, duke luftuar vazhdimisht për supremaci në sistemet që krijojmë.
Me ndihmën e rritjes dhe evoluimit të sistemeve të shërbimeve, ne shohim manifestime të ndryshme të pasojave të dikotomisë së të dhënave. Ose ndërfaqja e shërbimit do të rritet, duke ofruar një gamë gjithnjë e më të gjerë funksionesh dhe do të duket si një bazë të dhënash e errët e krijuar vetë, ose do të përballim zhgënjimin dhe do të realizojmë ndonjë mënyrë për të nxjerrë ose transferuar grupe të mëdha të dhënash nga një shërbim në tjetrin.
Nga ana tjetër, krijimi i diçkaje që duket si një bazë të dhënash e errët do të çojë në një sërë problemesh. Nuk do të thelloohemi në detajet e rreziqeve që paraqet shared database, thjesht do të themi se ajo përfaqëson vështirësi të konsiderueshme inxhinierike dhe operacionale për kompaninë që përpiqet ta përdorë atë.
Më keq akoma, volumi i të dhënave përkeqëson problemet me kufijtë e shërbimeve. Sa më shumë të dhëna të përbashkëta të ruhen brenda shërbimit, aq më e komplikuar do të bëhet ndërfaqja dhe aq më e vështirë do të jetë bashkimi i grupeve të dhënash që vijnë nga shërbime të ndryshme.
Një qasje alternative me nxjerrjen dhe zhvendosjen e grupeve të të dhënave të plota ka gjithashtu problemet e veta. Një qasje e zakonshme për këtë çështje duket si një nxjerrje e thjeshtë dhe ruajtje e grupeve të të dhënave në tërësi, dhe pastaj ruajtja e tij lokalisht në çdo shërbim që e konsumon.
Problemi është se shërbime të ndryshme e interpretojnë të dhënat që konsumojnë ndryshe. Këto të dhëna janë gjithmonë në dispozicion. Ato ndryshojnë dhe përpunohen lokalisht. Shpejt, ato ndalojnë së qeni të ngjashme me të dhënat në burim.
Sa më të mutabël të jenë kopjet, aq më shumë të dhënat do të ndryshojnë me kalimin e kohës.
Çfarë është edhe më e keqe, këto të dhëna janë të vështira për t'u korrigjuar në retrospektivë ( kjo mund të ndihmojë vërtet). Në fakt, disa nga problemet teknologjike të vështira që përballen bizneset ndodhin për shkak të të dhënave heterogjene që shumohen nga aplikacioni në aplikacion.
Për të gjetur një zgjidhje për këtë problem me të dhënat e zakonshme, duhet të mendojmë ndryshe. Ato duhet të bëhen objekte të klasës së parë në arkitekturën që po ndërtojmë. quese të dhënat "jashtme", dhe kjo është një veçori shumë e rëndësishme. Na nevojitet inkapsulimi për të mos zbuluar strukturën e brendshme të shërbimit, por duhet të lehtësojmë qasjen e shërbimeve në të dhënat e ndara, në mënyrë që ato të mund të kryejnë punën e tyre siç duhet.
Problemi qëndron në faktin se asnjëra nga qasjet e sotme nuk është më e aplikueshme, pasi as ndërfaqet e shërbimit, as shkëmbimi i mesazheve, as Databases të Ndara nuk ofrojnë një zgjidhje të mirë për të punuar me të dhënat jashtme. Ndërfaqet e shërbimit nuk janë të përshtatshme për shkëmbimin e të dhënave në asnjë shkallë. Shkëmbimi i mesazheve transferon të dhëna, por nuk ruan historinë e tyre, kështu që me kalimin e kohës, të dhënat dëmtohen. Databases të Ndara përqendrohen tepër shumë në një pikë, duke penguar përparimin. Ne përfundojmë në një cikël dështimi të të dhënave.
Cikli i dështimit të të dhënave
Flukset: një qasje e decentralizuar ndaj të dhënave dhe shërbimeve
Idealisht, duhet të ndryshojmë qasjen ndaj mënyrës se si shërbimet punojnë me të dhënat e përbashkëta. Aktualisht, çdo qasje përballet me të dyshimin e përmendur më sipër, pasi nuk ka asnjë pluhur magjik që mund ta heqë këtë problem. Megjithatë, mund ta ripërdorim këtë problem dhe të arrijmë një kompromis.
Ky kompromis përfshin një shkallë të caktuar centralizimi. Mund të përfitojmë nga mekanizmi i regjistrimeve të shpërndara, pasi ai ofron rrjedha të sigurta dhe të shkallëzuara. Tani, shërbimet duhet të mund të bashkohen dhe të punojnë me këto rrjedha të përbashkëta, megjithatë, dëshirojmë të shmangim shërbime të centralizuara të ndërlikuara që kryejnë këtë përpunim. Prandaj, zgjidhja më e mirë është të integrojmë përpunimin e rrjedhave në çdo shërbim përdorues. Kështu, shërbimet do të mund të bashkojnë grupe të dhënash nga burime të ndryshme dhe të punojnë me to ashtu siç u nevojitet.
Një nga mënyrat për të arritur një qasje të tillë është përdorimi i një platforme streaming. Ka shumë mundësi, por sot do të shqyrtojmë pikërisht Kafka, sepse përdorimi i saj të Procesimit të Fluksit Stateful lejon zgjidhjen efikase të problemit të paraqitur.
Përdorimi i mekanizmit të regjistrimit të shpërndarë na lejon të ndjekim një rrugë të ndjekur dhe të utilizojmë shkëmbimin e mesazheve për të punuar me . Ky qasje konsiderohet se siguron shkallëzim më të mirë dhe ndarje, sesa mekanizmi "kërkesë-përgjigje", pasi ia dorëzon kontrollin e fluksit marrësit, jo dërguesit. Megjithatë, për gjithçka në këtë jetë duhet të paguani, dhe këtu do t'ju nevojitet një broker. Por për sistemet e mëdha, ky kompromis ia vlen (çka nuk mund të thuhet për aplikacionet tuaja mesatare të uebit).
Nëse një broker përgjigjet për regjistrimin e shpërndarë dhe jo një sistem tradicional mesazhesh, mund të shfrytëzoni karakteristika shtesë. Transporti mund të shkallëzohet në mënyrë lineare pothuajse po aq mirë sa një sistem të shpërndarë skedari. Të dhënat mund të ruhen në regjistrat për një periudhë të gjatë, kështu që ne marrim jo vetëm shkëmbim mesazhesh, por edhe një depo informacioni. Një depo e shkallëzueshme pa frikën e përvetësimit të një gjendjeje të përbashkët të ndryshueshme.
Më pas, mund të përdorni mekanizmin e përpunimit të rrjedhës me ruajtje të gjendjes për të shtuar mjete deklarative të bazës së të dhënave në shërbimet konsumator. Kjo është një mendim shumë i rëndësishëm. Derisa të dhënat të ruhen në rrjedha të përbashkëta, të cilat mund të qasen nga të gjithë shërbimet, bashkimi dhe përpunimi që bën shërbimi është privat. Ato përfundojnë duke qenë të izoluar brenda një konteksti të kufizuar rreptësisht.
Shkëputni dikotominë e të dhënave duke ndarë rrjedhën e gjendjeve të pakthyeshme. Më pas, shtoni këtë funksion në çdo shërbim duke përdorur Përpunimin e Rrjedhës me Ruajtje të Gjendjes.
Pra të arrihet, nëse shërbimi juaj duhet të funksionojë me porosi, katalogun e produkteve, magazinën, do të ketë qasje 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. Megjithëse të dhënat janë të përbashkëta, puna me to është plotësisht e decentralizuar. Ajo zhvillohet brenda çdo shërbimi, në një botë ku gjithçka ndodh sipas rregullave tuaja.
Ndani të dhënat në një mënyrë që nuk dëmtohet integriteti i tyre. Inkapsuloni funksionin, jo burimin, në çdo shërbim që ka nevojë për të.
Ndonjëherë ndodh që të dhënat duhet të zhvendosen masivisht. Disa herë, një shërbim ka nevojë për një set historik lokal të të dhënave në motorin e zgjedhur të bazës së të dhënave. Fokusimi është që mund të garantohet se kur nevojitet, kopja mund të rikuperohet nga burimi me anë të thirrjes për mekanizmin e regjistrimit të shpërndarë. Konektorët në Kafka e kryejnë këtë detyrë shumë mirë.
Prandaj, qasja që po shqyrtojmë sot ka disa përparësi:
- Të dhënat përdoren si rrjedha të përgjithshme, të cilat mund të ruhen për një kohë të gjatë në log-e, dhe mekanizmi i punës me të dhënat e përbashkëta është i inkorporuar në çdo kontekst të veçantë, duke lejuar shërbimet të punojnë lehtësisht dhe shpejt. Në këtë mënyrë, mund të balancohet dikotomiumi i të dhënave.
- Të dhënat që vijnë nga shërbime të ndryshme mund të bashkohen lehtësisht në grupe. Kështu, ndërveprimi me të dhënat e përbashkëta bëhet më i lehtë dhe nevoja për të mbajtur grupe të dhënash lokale në database zhduket.
- Procesimi i Rrjedhjeve me Shtet vetëm ruan të dhënat, ndërsa burimi i së vërtetës mbetet log-et e përbashkëta, prandaj problemi i dëmtimit të të dhënave me kalimin e kohës nuk është aq i theksuar.
- Në thelb, shërbimet menaxhohen nga të dhënat, që do të thotë se përkundër rritjes së vazhdueshme të volumit të të dhënave, shërbimet akoma mund të reagojnë shpejt ndaj ngjarjeve të biznesit.
- Problemet e shkallëzimit bien mbi brokerin dhe jo mbi shërbimet. Kështu, reduktohet ndjeshëm kompleksiteti i shkruajtes së shërbimeve, pasi nuk ka nevojë të shqetësojnë për shkallëzimin.
- Shtimi i shërbimeve të reja nuk kërkon ndryshimin e atyre ekzistuese, kështu që lidhja e shërbimeve të reja bëhet më e lehtë.
Siç e shihni, kjo është më shumë se sa thjesht REST. Ne kemi marrë një set mjetesh që lejon punimin me të dhëna të përbashkëta në mënyrë decentralizuar.
Në artikullin e sotëm nuk u zbuluan të gjitha aspektet. Ne ende duhet të vendosim se si të balancojmë midis paradigmat ‘kërkesë-përgjigje’ dhe asaj të orientuar nga ngjarjet. Por për këtë do të merremi herën tjetër. Ka tema me të cilat duhet të njohim më mirë, për shembull, se si funksionon aq mirë procesimi i rrjedhave Stateful. Për këtë do të flasim në artikullin e tretë. Gjithashtu, ekzistojnë konstruksione të tjera të fuqishme që mund të përfitojmë, nëse i qasemi atyre, për shembull, . Me të, rregullat e lojës për sistemet e biznesit të shpërndara ndryshojnë, pasi ky konstruksion ofron garanci transaksionesh për në një formë të shkallëzueshme. Për këtë do të flasim në artikullin e katërt. Dhe në fund, do të duhet të kalojmë nëpër detajet e zbatimit të këtyre parimeve.
Por momentin, mbani mend se: dikotomia e të dhënave është fuqia me të cilën përballen shërbimet biznesore. Dhe ne duhet ta kujtojmë këtë. Fokusi është të përmbysim gjithçka dhe të fillojmë të shikojmë të dhënat e përgjithshme si objekte të klasës së parë. Procesimi i Dëmtuar i Shtresave ofron një kompromis unik për këtë. Ai shmang komponentët e centralizuar "God" që frenojnë zhvillimin e progresit. Më tepër, ai siguron shpejtësi, shkallëzueshmëri dhe qëndrueshmëri të pipeline-ve të të dhënave dhe i integron ato në çdo shërbim. Pra, ne mund të fokusohemi në rrjedhën e përgjithshme të mendimeve, të cilës mund t’i lidhet çdo shërbim dhe të punojë me të dhënat e saj. Kështu shërbimet bëhen më të shkallëzueshme, të ndërrueshme dhe autonome. Prandaj, ato do të duken jo vetëm mirë në bordin e shënimeve dhe gjatë testimit të hipotezave, por gjithashtu do të punojnë dhe zhvillohen për dekada.
Burimi: habr.com
