Përshëndetje të gjithëve! Kemi lajme të mrekullueshme, në qershor OTUS riban kursin , ndaj ne tradicionalisht ndajem me ju materiale të dobishme.
Nëse keni hasur në të gjithë këtë histori me mikrosherbimet pa asnjë kontekst, atëherë ju është falur ta konsideroni atë pak të çuditshme. Shkëputja e aplikacioneve në fragmente, të lidhura mes tyre me një rrjet, do të thotë patjetër shtimin e mënyrave komplekse të qëndrueshmërisë në sistemin e shpërndarë që ka rezultuar.
Megjithëse kjo 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 interaksionin me botën përreth, e cila në thelb është gjithashtu e shpërndarë. Jo në kuptimin teknik, por më shumë në kuptimin e ekosistemit, i cili përbëhet nga një numër njerëzish, grupesh, programesh, dhe secila nga këto pjesë duhet ndonjëherë të kryejnë punën e tyre.
Kompani, për shembull, përbëjnë një grup sistemesh të shpërndara, të cilat së bashku ndihmojnë në arritjen e një qëllimi të caktuar. Ne e injoruam këtë fakt për dekada, duke u përpjekur të arrijmë një bashkim, duke kaluar skedarë përmes FTP-së ose duke përdorur mjete integrimi korporativ, duke u fokusuar në qëllimet tona personale të izoluara. Por me ardhjen e shërbimeve, gjithçka ndryshoi. Shërbimet na ndihmuan të shikojmë përtej horizontit dhe të shohim një botë programash ndërvarëse që punojnë së bashku. Megjithatë, për të punuar me sukses, është e nevojshme të kuptohet dhe të projektohet dy botë themelore të ndryshme: bota e jashtme, ku ne jetojmë në një ekosistem të shumë shërbimeve të tjera, dhe bota jonë personale, të brendshme, ku sundojmë vetëm.
Kjo botë e shpërndarë është ndryshe nga ajo në të cilën kemi rritur dhe jemi mësuar. Parimet e ndërtimit të arkitekturës tradicionale monolite nuk qëndrojnë askund për kritikë. Prandaj, kuptimi i saktë i sistemeve të tilla është diçka më shumë se krijimi i një skeme të bukur në një tavolinë me marker të bardhë ose një provë të shkëlqyer koncepti. Bëhet fjalë për të pasur një sistem të tillë që funksionon me sukses për një kohë të gjatë. Fatmirësisht, shërbimet ekzistojnë tashmë mjaft kohë, ndonëse duken në mënyra të ndryshme. ende janë akoma të rëndësishme, edhe pse janë përzierë me Docker, Kubernetes dhe pak të brishta me mjekra hipster.
Pra, sot do të shikojmë se si janë ndërruar rregullat, pse na duhet të ripërshtasim qasjen tonë ndaj shërbimeve dhe të dhënave që ato transferojnë midis njëra-tjetrës, dhe pse për këtë na nevojitet një mjet krejtësisht tjetër.
Inkapcualizimi nuk do të jetë gjithmonë shoku juaj.
Mikrosherbimet mund të funksionojnë ç indipendente nga njëri-tjetri. Ky atribut është çelësi i vlerës së tyre. Ky vetë atribut i lejon shërbimet të shkallëzohen dhe të rriten. Jo aq në kuptimin e shkallëzimit deri në katër trilion përdorues ose petabajt të dhënash (ndonëse këtu ato mund të ndihmojnë), sa në kuptimin e shkallëzimit nga këndvështrimi i njerëzve, duke pasur parasysh që ekipet dhe organizatat vazhdojnë të rriten.
Megjithatë, pavarësia është një të dyja anët e monedhës. Kështu që shërbimi mund të funksionojë lehtë dhe natyrshëm në vetvete. Por nëse brenda shërbimit implementohet një funksionalitet që kërkon angazhimin e një shërbimi tjetër, atëherë përfundimisht na duhet të sjellim ndryshime në të dy shërbimet pothuajse njëkohësisht. Në një monolit, kjo është e lehtë, thjesht bëni ndryshimin dhe dërgojeni për 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 fleksibilitetin.
Brenda qasjes standarde, ndryshimet e pakëndshme të kalueshme zakonisht përpiqen të shmangen, duke ndarë qartë funksionalitetin midis shërbimeve. Një shërbim i vetëm hyrje në sistem këtu mund të jetë një shembull i mirë. Ai ka një rol të qartë të caktuar, i cili e dallon atë nga shërbimet e tjera. Kjo ndarje e qartë do të thotë se në një botë me kërkesa të shpejta që ndryshojnë ndaj shërbimeve përreth, shërbimi i vetëm hyrjes në sistem ka të ngjarë të mos ndryshojë. Ai ekziston brenda një konteksti shumë të kufizuar.
Problemi qëndron në faktin se në botën reale, shërbimet e biznesit nuk mund të ruajnë gjithmonë një ndarje të pastër të roleve. Për shembull, këto shërbime biznesi në masë të madhe punojnë me të dhënat që vijnë nga shërbime të tjera të ngjashme. Nëse jeni duke u marrë me tregtinë elektronike, përpunimi i rrymës së 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ë ketë nevojë për qasje në këto të dhëna për të funksionuar.
Shumica e shërbimeve të biznesit përdorin të njëjtën rrymë të të dhënave, prandaj puna e tyre përputhet gjithmonë.
Kështu kemi arritur në një moment të rëndësishëm që merret parasysh. Ndërsa shërbimet funksionojnë mirë për komponentët e infrastrukturës që operojnë në masë të madhe në mënyrë të veçantë, shumica e shërbimeve të biznesit përfundojnë duke u lidhur shumë më ngushtë.
Dihotomia e të dhënave
Qasjet që janë orientuar ndaj shërbimeve ndoshta tashmë ekzistojnë, megjithatë, ka ende pak informacion mbi atë si të shkëmbehen sasi të mëdha të të dhënave midis shërbimeve.
Problemi kryesor qëndron në atë se të dhënat dhe shërbimet janë të pat separueshme. Nga njëra anë, inkapsulimi na inkurajon të fshehim të dhënat që shërbimet të mund të ndahen njëri nga tjetri dhe të lehtësojnë rritjen dhe ndryshimin e tyre të mëtejshëm. Nga ana tjetër, na nevojitet të kemi mundësinë për të ndarë dhe zotëruar lirisht të dhënat e zakonshme, ashtu si çdo të dhëna tjetër. Bëhet fjalë për të pasur mundësinë që të fillosh menjëherë punën, ashtu siç e bën në çdo sistem tjetër informacioni.
Megjithatë, sistemet e informacionit kanë pak të përbashkët me inkapsulimin. Në të vërtetë, madje është e kundërta. Baza të dhënash bëjnë gjithçka që munden për të ofruar akses në të dhënat e ruajtura në to. Ato vijnë me një ndërfaqe të fuqishme deklarative që lejon modifikimin e të dhënave sipas nevojës suaj. Ky funksionalitet është i rëndësishëm në fazën e hetimeve paraprake, por jo për menaxhimin e kompleksitetit në rritje të një shërbimi që zhvillohet vazhdimisht.
Dhe këtu lind dilema. Kontradikta. Dihotomia. Sepse sistemet e informacionit janë për sigurimin e të dhënave, ndërsa shërbimet janë për fshehjen.
Këto dy forca janë thelbësore. Ato qëndrojnë në bazë të shumicës së punës sonë, duke u përballur vazhdimisht për supremaci në sistemet që krijojmë.
Me rritjen dhe evolucionin e sistemeve të shërbimeve, ne shohim manifestime të ndryshme të pasojave të dikohtomisë së të dhënave. Ose interfejsi i shërbimit do të rritet, duke ofruar një gamë më të gjerë funksionesh dhe do të fillojë të duket si një bazë të dhënash shumë e çuditshme e krijuar në shtëpi, ose do të përjetojmë zhgënjim dhe do të zbatojmë një mënyrë për të nxjerrë ose zhvendosur masa gjithëpërfshirëse të seteve të dhënash nga shërbimi në shërbim.
Nga ana tjetër, krijimi i ndonjë gjëje që duket si një bazë të dhënash e çuditshme e krijuar në shtëpi do të çojë në një mori problemesh. Nuk do të hyjmë në detaje se sa e rrezikshme është shared database, thjesht do të themi se ajo paraqet vështirësi të konsiderueshme inxhinierike dhe operacionale Me keqardhje, volumi i të dhënave shumfishon problemet me kufijtë e shërbimeve. Sa më shumë të dhëna të përbashkëta të jenë brenda shërbimit, aq më e komplikuar do të bëhet interfejsi dhe aq më e vështirë do të jetë të bashkohen setet e të dhënave që vinë nga shërbime të ndryshme.
Një qasje alternative me nxjerrjen dhe zhvendosjen e grupeve të të dhënave të tëra ka gjithashtu problemet e saj. Qasja më e zakonshme ndaj kësaj çështjeje duket si një nxjerrje e thjeshtë dhe ruajtje e të dhënave të tërësishme, dhe pastaj ruajtja e saj lokalizuar në çdo shërbim që e konsumon.
Problemi është se shërbime të ndryshme interpretojnë të dhënat që ata konsumojnë në mënyra të ndryshme. Këto të dhëna janë gjithmonë në dispozicion. Ato ndryshojnë dhe përpunohen lokal. Mjaft shpejt ato nuk kanë më asgjë të përbashkët me të dhënat në burim.
Sa më shumë që kopjet janë të ndryshueshme, aq më shumë të dhënat do të ndryshojnë me kalimin e kohës.
Çfarë është edhe më e keqe, është se ato të dhëna janë të vështira për t'u riparuar në retrospektivë (
MDM Për të gjetur një zgjidhje për këtë problem të të dhënave të përbashkëta, duhet të mendojmë ndryshe. Ato duhet të bëhen objekte të klasës së parë në arkitekrutë që ne ndërtojmë.
Pët Helland quonë këto të dhëna i quajnë "të jashtme", dhe kjo është një karakteristikë shumë e rëndësishme. Na nevojitet inkapsulimi për të mos zbuluar strukturën e brendshme të shërbimit, por gjithashtu duhet të lehtësojmë shërbimet në qasjen e të dhënave të përbashkëta në mënyrë që të mund të kryejnë punën e tyre siç duhet.
Problemi qëndron se asnjë nga qasjet e sotme nuk është më актуale, pasi as ndërfaqet e shërbimit, as shkëmbimi i mesazheve, as Shared Database nuk ofrojnë një zgjidhje të mirë për punën 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ë asnjë shkallë. Shkëmbimi i mesazheve lëviz të dhënat, por nuk ruan historinë e tyre, kështu që me kalimin e kohës të dhënat dëmtohen. Shared Databases përqendrohen shumë në një pikë, duke e penguar zhvillimin e progresit. Ne përfundojmë në një cikël dështimi të të dhënave.
Cikli i dështimit të të dhënave
Rrjedhat: një qasje decentralizuese ndaj të dhënave dhe shërbimeve
Në mënyrë ideale, na nevojitet të ndryshojmë qasjen ndaj mënyrës se si shërbimet punojnë me të dhëna të përbashkëta. Deri më tani, çfarëdo qasje has në dikotominë e mësipërme, pasi nuk ka asnjë magji që mund ta shpërndajë atë dhe ta bëjë të zhduket. Megjithatë, mund të riformulojmë problemin dhe të arrijmë në një kompromis.
Ky kompromis përfshin një shkallë të caktuar të qendrizimit. Ne mund të përfitojmë nga mekanizmi i regjistrave të shpërndarë, pasi ai ofron rrjedha të besueshme dhe të shkallëzueshme. Tani është e nevojshme që shërbimet të mund të lidhen dhe të punojnë me këto rrjedha të përbashkëta, megjithatë, ne duam të shmangim shërbimet e komplikuara qendrore të cilat kryejnë këtë përpunim. Prandaj, opsioni më i mirë është të integrojmë përpunimin në rrjedhë 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 siç iu nevojiten.
Një nga mënyrat për të arritur një qasje të tillë është përdorimi i një platforme të transmetimit. Ekzistojnë shumë mundësi, por sot do të shqyrtojmë pikërisht Kafka, pasi përdorimi i Përpunimit të Rrjedhave Stateful të saj lejon zgjidhjen efektive të problemit të paraqitur.
Përdorimi i mekanizmit të regjistrimit të shpërndarë na lejon të ndjekim një rrugë të paravendosur dhe të përdorim shkëmbimin e mesazheve për të punuar me . Ky qasje konsiderohet se ofron një shkallëzim dhe ndarje më të mirë se mekanizmi 'kërkesë-përgjigje', pasi i jep kontrollin e rrjedhës marrësit dhe jo dërguesit. Megjithatë, për gjithçka në këtë jetë duhet paguar, dhe këtu ju nevojitet një broker. Por për sistemet e mëdha, ky kompromis ia vlen (diçka që nuk mund të thuhet për aplikacionet tuaja mesatare web).
Nëse brokeri kujdeset për regjistrimin e shpërndarë, dhe jo një sistem të zakonshëm mesazhi, mund të shfrytëzoni karakteristika shtesë. Transporti mund të shkallëzohet linearisht pothuajse aq mirë sa një sistem të dhënash të shpërndara. Të dhënat mund të ruajnë në regjistra për një periudhë të gjatë, kështu që ne marrim jo vetëm shkëmbim mesazhesh, por gjithashtu një depo informacioni. Depo e shkallëzueshme pa frikë se do të merrni një gjendje të ndryshueshme të zakonshme.
Pastaj mund të përdorni mekanizmin e përpunimit të rrjedhave me ruajtje gjendjeje (stateful stream processing) për të shtuar mjete deklarative të bazës së të dhënave në shërbimet marrëse. Kjo është një mendim shumë i rëndësishëm. Deri në momentin kur të dhënat ruhen në rrjedhat e përbashkëta, të cilat mund të aksesohen nga të gjithë shërbimet, bashkimi dhe përpunimi që bën shërbimi është privat. Ata janë të izoluar brenda një konteksti të rreptë të kufizuar.
Shkëputni diku nga dikotomia e të dhënave duke ndarë rrjedhën e gjendjeve të pandryshueshme. Pastaj shtoni këtë funksion në çdo shërbim me anë të Përpunimit të Rrjedhave me Ruajtje Gjendjeje.
Kështu, nëse shërbimi juaj duhet të punojë me porosi, katalog produkte, magazinë, ai do të ketë qasje të plotë: vetëm ju do të vendosni se cilat të dhëna duhet të bashkohen, ku të përpunohen 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 bëhet brenda çdo shërbimi, në një botë ku gjithçka ndodh sipas rregullave tuaja.
Ndani të dhënat në mënyrë që integriteti i tyre të mos cenohet. Inkuadrojeni funksionin, dhe jo burimin, në çdo shërbim që i nevojitet.
Ndonjëherë ndodh që të dhënat të duhet të transferohen në masë. Herë pas here, shërbimi ka nevojë për një grup historik lokal të të dhënave në motorin e zgjedhur të bazës së të dhënave. Thelbi është se mund të sigurohet që nëse është e nevojshme, një kopje mund të rikthehet nga burimi duke iu referuar mekanizmit të regjistrimit të shpërndarë. Konektorët në Kafka përballen mjaft mirë me këtë detyrë.
Pra, qasja e diskutuar sot ka disa avantazhe:
- Të dhënat përdoren si rrjedha të përbashkëta, të cilat mund të ruhen për një kohë të gjatë në regjistrat, dhe mekanizmi i punës me të dhëna të përbashkëta është i kyçur në çdo kontekst të veçantë, duke lejuar shërbimet të punojnë lehtë dhe shpejt. Në këtë mënyrë, është e mundur të balancohet dikuimi 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 thjeshtë dhe zhduket nevoja për të mbajtur grupe të dhënash lokale në bazën e të dhënave.
- Stateful Stream Processing thjesht ruan të dhënat, ndërsa burimi i së vërtetës mbetet regjistrat e përbashkëta, prandaj problemi i dëmtimit të të dhënave me kalimin e kohës nuk është aq dukshëm.
- Në thelb, shërbimet menaxhohen nga të dhënat, që do të thotë se pavarësisht rritjes së vazhdueshme të volumit të të dhënave, shërbimet akoma mund të reagojnë shpejt ndaj ngjarjeve biznesore.
- Problemet e shkallëzueshmërisë bien në broker dhe jo në shërbime. Kështu, ndjeshëm ulet kompleksiteti i shkruarjes së shërbimeve, pasi nuk ka nevojë të mendojmë për shkallëzueshmërinë.
- Shtimi i shërbimeve të reja nuk kërkon të ndryshojë të vjetrat, ndaj lidhja e shërbimeve të reja bëhet më e lehtë.
Siç e shihni, kjo është më shumë se thjesht REST. Ne kemi marrë një grup mjetesh që lejojnë punën me të dhëna të përbashkëta në mënyrë decentralizuar.
Në artikullin e sotëm u zbuluan edhe më shumë aspekte. Ne ende duhet të përcaktojmë se si të balancojmë midis paradigmës 'kërkesë-përgjigje' dhe paradigmës të orientuar nga ngjarjet. Por me këtë do të merremi herën tjetër. Ka tema me të cilat duhet të njihemi më mirë, si p.sh. pse është kaq i mirë Stateful Stream Processing. Për këtë do të flasim në artikullin e tretë. Gjithashtu, ekzistojnë konstrukte të tjera të fuqishme që mund të shfrytëzojmë, nëse i qasemi atyre, për shembull, . Me ndihmën e saj, rregullat për sistemet e biznesit të shpërndarë ndryshojnë, pasi kjo strukturë siguron garanci transaksionesh për në një formë të shkallëzueshme. Këtë do ta diskutojmë në artikullin e katërt. Dhe përfundimisht, do të duhet të kalojmë nëpër detajet e implementimit të këtyre parimeve.
Por për tani, thjesht mbani mend këtë: dikotomia e të dhënave është forca me të cilën përballemi kur krijojmë shërbime biznesi. Dhe duhet ta kemi parasysh këtë. Fokusi është që të përmbysim gjithçka dhe të fillojmë të konsiderojmë të dhënat e përbashkëta si objekte të klasës së parë. Procesimi i rrymave me gjendje ofron një kompromis unik për këtë. Ai shmang "Komponentët Zot" qendrorë që frenojnë zhvillimin e përparimit. Më tej, ai siguron operativitet, shkallëzim dhe qëndrueshmëri të tubacioneve të rrymës së të dhënave dhe i integron ato në çdo shërbim. Prandaj, mund të përqendrohemi në rrjedhën e përbashkët të mendimeve, të cilit mund t'i bashkëngjitet çdo shërbim dhe të punojë me të dhënat e tij. 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ë tabelat e markimit dhe gjatë kontrollit të hipotezave, por gjithashtu do të funksionojnë dhe zhvillohen për dekada.
Burimi: habr.com
