Kaixo guztioi! Berri bikaina dugu, OTUSek ekainean berriro martxan jarriko du ikastaroa , eta horri lotuta, tradizionalki material erabilgarria partekatzen dugu zurekin.
Inolako testuingururik gabe mikrozerbitzuen gauza osoa topatu baduzu, barkatuko zenuke arraro samarra dela pentsatzea. Aplikazio bat sare batek konektatutako zatitan zatitzeak, derrigorrez, ondoriozko sistema banatuari akatsen tolerantzia-modu konplexuak gehitzea esan nahi du.
Ikuspegi honek zerbitzu independente askotan zatikatzea dakar ere, azken helburua zerbitzu horiek makina ezberdinetan exekutatzen izatea baino askoz gehiago da. Kanpoko munduarekiko elkarrekintzaz ari gara hemen, hau ere bere funtsean banatuta dagoena. Ez zentzu teknikoan, pertsona, talde, programa eta zati horietako bakoitzak nolabait bere lana egin behar duen ekosistema baten zentzuan baizik.
Enpresak, adibidez, helbururen bat lortzen kolektiboki laguntzen duten sistema banatuen bilduma bat dira. Gertaera hori alde batera utzi dugu hamarkada luzez, FTP fitxategien bidez bateratzea lortu nahian edo enpresa integratzeko tresnak erabiliz, gure helburu isolatuetan zentratuz. Baina zerbitzuen etorrerarekin, dena aldatu zen. Zerbitzuek zerumugatik haratago begiratzen lagundu digute eta elkarrekin funtzionatzen duten programen mundu bat ikusten lagundu digu. Dena den, arrakastaz lan egiteko, funtsezko bi mundu ezagutu eta diseinatzea beharrezkoa da: kanpoko mundua, non beste zerbitzu askoren ekosistema batean bizi garen, eta gure mundu pertsonala, barnekoa, non bakarrik gobernatzen dugun.
Banatutako mundu hau hazi eta ohituta gaudenaren ezberdina da. Arkitektura monolitiko tradizionala eraikitzeko printzipioak ez dira kritikak jasaten. Beraz, sistema hauek ondo lortzea arbelaren diagrama polit bat edo kontzeptuaren froga polit bat sortzea baino gehiago da. Kontua da sistema horrek denbora luzez arrakastaz funtzionatzen duela ziurtatzea. Zorionez, zerbitzuek denbora dezente egon dira, nahiz eta itxura ezberdina duten. oraindik garrantzitsuak dira, Docker, Kubernetes eta hipster bizar apur batekin onduak ere.
Beraz, gaur aztertuko dugu nola aldatu diren arauak, zergatik birplanteatu behar dugun zerbitzuetara hurbiltzeko modua eta haiek elkarri helarazten dizkioten datuak, eta zergatik beharko ditugun tresna guztiz desberdinak horretarako.
Kapsulatzea ez da beti zure laguna izango
Mikrozerbitzuek elkarrengandik independentean funtziona dezakete. Jabetza hori da balio handiena ematen diena. Jabetza honek zerbitzuak eskalatzeko eta hazteko aukera ematen du. Ez hainbeste erabiltzaile kuatrilioi edo petabyte datuetara eskalatzeko zentzuan (nahiz eta horiek ere lagun dezaketen), baina talde eta erakundeak etengabe hazten diren heinean pertsonen aldetik eskalatzeko zentzuan.
Hala ere, independentzia aho biko ezpata da. Hau da, zerbitzua bera erraz eta naturaltasunez exekutatu daiteke. Baina beste zerbitzu bat erabiltzea eskatzen duen zerbitzu baten barruan funtzio bat inplementatzen bada, azkenean bi zerbitzuetan aldaketak egin behar izaten ditugu ia aldi berean. Monolito batean hau egitea erraza da, aldaketa bat egin eta kalera bidali besterik ez duzu, baina zerbitzu independenteak sinkronizatzearen kasuan arazo gehiago egongo dira. Taldeen eta kaleratze zikloen arteko koordinazioak arintasuna suntsitzen du.
Ikuspegi estandarraren zati gisa, amaierako aldaketa gogaikarria saihesten saiatzen dira, funtzionaltasuna zerbitzuen artean argi banatuz. Saioa hasteko zerbitzu bakarra adibide ona izan daiteke hemen. Argi eta garbi definitutako rola du, beste zerbitzuetatik bereizten duena. Bereizketa argi honek esan nahi du bere inguruko zerbitzuen eskakizun azkar aldatzen ari den munduan, saio-hasiera bakarreko zerbitzua nekez aldatuko dela. Testuinguru hertsiki mugatu baten barruan dago.
Arazoa da mundu errealean, negozio-zerbitzuek ezin dutela eginkizunen bereizketa huts bera mantendu denbora guztian. Esaterako, enpresa-zerbitzu berdinek neurri handiagoan funtzionatzen dute antzeko beste zerbitzu batzuetatik datozen datuekin. Lineako txikizkako merkataritzan parte hartzen baduzu, eskaera-fluxua, produktuen katalogoa edo erabiltzailearen informazioa prozesatzea zure zerbitzuetako askoren baldintza bihurtuko da. Zerbitzu bakoitzak datu horietarako sarbidea beharko du funtzionatzeko.
Enpresa-zerbitzu gehienek datu-jario bera partekatzen dute, beraz, haien lana beti elkarri lotuta dago.
Hortaz, hitz egitea merezi duen puntu garrantzitsu batera iritsiko gara. Zerbitzuek neurri handi batean isolatuta funtzionatzen duten azpiegitura-osagaietarako ondo funtzionatzen duten arren, negozio-zerbitzu gehienak askoz ere estuago lotzen dira.
Datuen dikotomia
Baliteke zerbitzuetara bideratutako planteamenduak jada existitzen, baina oraindik ez dute zerbitzuen artean datu kopuru handiak nola partekatu jakiteko.
Arazo nagusia da datuak eta zerbitzuak bereizezinak direla. Alde batetik, kapsulatzeak datuak ezkutatzera bultzatzen gaitu, zerbitzuak elkarrengandik bereiz daitezen eta haien hazkuntza eta aldaketa gehiago errazteko. Bestalde, partekatutako datuak askatasunez banatu eta konkistatzeko gai izan behar dugu, beste edozein datu bezala. Kontua da berehala lanean hasi ahal izatea, beste edozein informazio sistematan bezain libre.
Dena den, informazio-sistemek zerikusi gutxi dute kapsulazioarekin. Izan ere, guztiz kontrakoa da. Datu-baseek ahal duten guztia egiten dute gordetzen dituzten datuetarako sarbidea emateko. Adierazpen-interfaze indartsu batekin datoz, datuak behar duzun moduan aldatzeko aukera ematen duena. Funtzionalitate hori garrantzitsua da aurretiazko ikerketa fasean, baina ez etengabe garatzen ari den zerbitzu baten gero eta konplexutasuna kudeatzeko.
Eta hemen dilema bat sortzen da. Kontraesana. Dikotomia. Azken finean, informazio sistemak datuak ematea da, eta zerbitzuak ezkutatzea.
Bi indar hauek oinarrizkoak dira. Gure lanaren zati handi bat eusten dute, eraikitzen ditugun sistemetan bikaintasunaren alde etengabe borrokan.
Zerbitzu-sistemak hazi eta eboluzionatu ahala, datuen dikotomiaren ondorioak modu askotan ikusten ditugu. Edo zerbitzu-interfazea hazi egingo da, gero eta funtzionaltasun-aukera handiagoa eskainiz eta etxeko datu-base oso dotore baten itxura hartzen hasiko da, edo zapuztu egingo gara eta zerbitzutik zerbitzura datu-multzo osoak masiboki berreskuratu edo mugitzeko moduren bat ezarriko dugu.
Era berean, etxeko datu-base dotore baten itxura duen zerbait sortzeak arazo ugari ekarriko ditu. Ez dugu xehetasunetan sartuko zergatik den arriskutsua datu-base partekatua, demagun ingeniaritza garesti eta operatibo esanguratsua adierazten duela erabiltzen saiatzen ari den enpresarentzat.
Okerrena da datu-bolumenak zerbitzuaren muga-arazoak handitzen dituela. Zenbat eta datu partekatu gehiago egon zerbitzu baten barruan, orduan eta konplexuagoa izango da interfazea eta orduan eta zailagoa izango da zerbitzu ezberdinetatik datozen datu multzoak konbinatzea.
Datu-multzo osoak atera eta mugitzeko ikuspegi alternatiboak ere baditu bere arazoak. Galdera honetarako ohiko ikuspegi batek datu-multzo osoa berreskuratzea eta biltegiratzea besterik ez du dirudi, eta gero lokalean biltegiratzea kontsumitzaileen zerbitzu bakoitzean.
Arazoa da zerbitzu ezberdinek kontsumitzen dituzten datuak ezberdin interpretatzen dituztela. Datu hauek beti eskura daude. Lokalean aldatzen eta prozesatzen dira. Nahiko azkar uzten dute iturriko datuekin ezer komunean edukitzeari.
Kopiak zenbat eta aldagarriagoak izan, orduan eta gehiago aldatuko dira datuak denboran zehar.
Hori gutxi balitz, zaila da datu horiek atzera begira zuzentzea ( Hau da benetan erreskatean etor daiteke). Izan ere, enpresek jasaten dituzten teknologia-arazo konponezinetako batzuk aplikaziotik aplikaziora biderkatzen diren datu desberdinetatik sortzen dira.
Arazo honi irtenbidea aurkitzeko, datu partekatuei buruz ezberdin pentsatu behar dugu. Eraikitzen ditugun arkitekturan lehen mailako objektu bihurtu behar dira. βkanpoβ deitzen die horrelako datuei, eta hori oso ezaugarri garrantzitsua da. Kapsulatua behar dugu, zerbitzu baten barne funtzionamendua agerian ez jartzeko, baina zerbitzuei erraztu behar diegu partekatutako datuak atzitzea, beren lana behar bezala egin dezaten.
Arazoa da gaur egun bi ikuspegiak ez direla garrantzitsuak, ez zerbitzuen interfazeek, ββez mezularitzak, ez Partekatutako Datu Baseak ez baitute irtenbide onik eskaintzen kanpoko datuekin lan egiteko. Zerbitzu-interfazeak ez dira egokiak edozein eskalatan datuak trukatzeko. Mezularitzak datuak mugitzen ditu baina ez du bere historia gordetzen, beraz, datuak hondatu egiten dira denborarekin. Partekatutako datu-baseek puntu batean gehiegi jartzen dute arreta, eta horrek aurrerapena geldiarazten du. Ezinbestean datuen hutsegiteen ziklo batean trabatu egiten gara:
Datuen hutsegitearen zikloa
Korronteak: datuen eta zerbitzuen ikuspegi deszentralizatua
Egokiena, zerbitzuek partekatutako datuekin lan egiteko modua aldatu behar dugu. Puntu honetan, edozein ikuspegik aipatutako dikotomiari aurre egiten diote, ez baitago hauts magikorik bota daitekeenik desagertzeko. Hala ere, arazoa birplanteatu eta akordio batera iritsi gaitezke.
Konpromiso honek zentralizazio maila bat dakar. Banatutako erregistro-mekanismoa erabil dezakegu korronte fidagarriak eta eskalagarriak eskaintzen dituelako. Orain zerbitzuak partekatutako hari hauetan sartu eta funtzionatu ahal izatea nahi dugu, baina prozesamendu hori egiten duten Jainko Zerbitzu zentralizatu konplexuak saihestu nahi ditugu. Hori dela eta, aukerarik onena korronteen prozesamendua kontsumo-zerbitzu bakoitzean sartzea da. Horrela, zerbitzuek iturri ezberdinetako datu multzoak konbinatu eta haiekin behar duten moduan lan egin ahal izango dute.
Ikuspegi hori lortzeko modu bat streaming plataforma baten erabilera da. Aukera asko daude, baina gaur Kafka aztertuko dugu, bere Stateful Stream Processing-aren erabilerak aurkeztutako arazoa modu eraginkorrean konpontzeko aukera ematen baitu.
Banatutako erregistro-mekanismoa erabiltzeak ondo zapaldutako bidea jarraitzeko eta mezularitza erabiltzeko aukera ematen digu . Ikuspegi honek eskaera-erantzun mekanismoak baino eskalatze eta zatiketa hobeak eskaintzen dituela uste da, igorleari baino fluxuaren kontrola ematen diolako hartzaileak. Hala ere, bizitza honetan dena ordaindu behar duzu, eta hemen artekari bat behar duzu. Baina sistema handietarako, truke-offak merezi du (baliteke hori ez izatea zure batez besteko web aplikaziorako).
Agente bat mezularitza-sistema tradizionalaren ordez banatutako erregistroaz arduratzen bada, eginbide gehigarriak aprobetxa ditzakezu. Garraioa linealki eskala daiteke ia fitxategi-sistema banatu bat bezain ondo. Datuak erregistroetan denbora luzez gorde daitezke, beraz, mezuen trukea ez ezik, informazioa biltegiratzea ere lortzen dugu. Biltegiratze eskalagarria egoera partekatu aldagarriaren beldurrik gabe.
Ondoren, egoera-korronteen prozesamendua erabil dezakezu kontsumitzaileen zerbitzuei datu-base deklaratiboko tresnak gehitzeko. Hau oso ideia garrantzitsua da. Datuak zerbitzu guztiek atzi ditzaketen korronte partekatuetan gordetzen diren bitartean, zerbitzuak egiten duen batuketa eta prozesamendua pribatua da. Testuinguru hertsiki mugatu batean isolatuta aurkitzen dira.
Ezabatu datuen dikotomia aldaezina den egoera-jarioa bereiziz. Ondoren, gehitu funtzionalitate hau Stateful Stream Processing erabiliz zerbitzu guztietan.
Horrela, zure zerbitzuak eskaerekin, produktuen katalogo batekin, biltegi batekin lan egin behar badu, sarbide osoa izango du: zuk bakarrik erabakiko duzu zer datu konbinatu, non prozesatu eta denboran zehar nola aldatu behar diren. Datuak partekatzen diren arren, berarekin lana guztiz deszentralizatuta dago. Zerbitzu bakoitzaren barruan ekoizten da, dena zure arauen arabera doan mundu batean.
Partekatu datuak bere osotasuna arriskuan jarri gabe. Kapsulatu funtzioa, ez iturria, behar duten zerbitzu guztietan.
Gertatzen da datuak masiboki mugitu behar direla. Batzuetan, zerbitzu batek tokiko datu-multzo historiko bat behar du hautatutako datu-base-motorrean. Trikimailua da, beharrezkoa izanez gero, kopia bat iturburutik berreskuratu daitekeela bermatu dezakezula, banatutako erregistro-mekanismora sartuz. Kafkako konektoreek lan bikaina egiten dute.
Beraz, gaur eztabaidatutako ikuspegiak hainbat abantaila ditu:
- Datuak korronte arrunten moduan erabiltzen dira, erregistroetan gorde daitezke denbora luzez, eta datu komunekin lan egiteko mekanismoa testuinguru indibidual bakoitzean konfiguratuta dago, eta horri esker, zerbitzuek erraz eta azkar funtzionatzen dute. Horrela, datuen dikotomia orekatu daiteke.
- Zerbitzu ezberdinetatik datozen datuak erraz konbina daitezke multzotan. Horrek partekatutako datuekin elkarreragina errazten du eta datu-basean tokiko datu multzoak mantentzeko beharra ezabatzen du.
- Stateful Stream Processing datuak soilik gordetzen ditu, eta egiaren iturria erregistro orokorrak izaten jarraitzen du, beraz, denboran zehar datuak usteltzearen arazoa ez da hain larria.
- Funtsean, zerbitzuak datuetan oinarritzen dira, hau da, datu-bolumena gero eta handiagoa den arren, zerbitzuek oraindik azkar erantzuten diete negozio-gertaerei.
- Eskalagarritasun arazoak brokerrengan daude, ez zerbitzuetan. Horrek nabarmen murrizten du idazketa-zerbitzuen konplexutasuna, ez baitago eskalagarritasunari buruz pentsatu behar.
- Zerbitzu berriak gehitzeak ez du zaharrak aldatu behar, beraz, zerbitzu berriak konektatzea errazagoa da.
Ikus dezakezunez, hau ATSEDENA baino gehiago da. Partekatutako datuekin modu deszentralizatuan lan egiteko aukera ematen duten tresna multzo bat jaso dugu.
Gaurko artikuluan ez dira alderdi guztiak landu. Oraindik asmatu behar dugu nola orekatu eskaera-erantzun paradigma eta gertaerak bultzatutako paradigma. Baina hurrengoan honi aurre egingo diogu. Hobeto ezagutu behar dituzun gaiak daude, adibidez, Stateful Stream Processing zergatik den hain ona. Hirugarren artikuluan horri buruz hitz egingo dugu. Eta badaude beste konstruktu indartsu batzuk horietara jotzen badugu aprobetxatu ditzakegunak, adibidez, . Negozio sistema banatuentzako joko-aldaketa bat da, transakzio-bermeak eskaintzen dituelako forma eskalagarrian. Hau laugarren artikuluan eztabaidatuko da. Azkenik, printzipio horien ezarpenaren xehetasunak aztertu beharko ditugu.
Baina, oraingoz, gogoratu besterik ez dago hau: datuen dikotomia negozio-zerbitzuak eraikitzerakoan aurrean dugun indarra da. Eta hau gogoratu behar dugu. Trikimailua da dena buelta ematea eta partekatutako datuak lehen mailako objektu gisa tratatzen hastea. Stateful Stream Processing konpromezu berezia eskaintzen du horretarako. Aurrerapena geldiarazten duten "Jainkoaren osagai" zentralizatuak saihesten ditu. Gainera, datuen streaming kanalizazioen arintasuna, eskalagarritasuna eta erresilientzia bermatzen ditu eta zerbitzu guztietan gehitzen ditu. Hori dela eta, edozein zerbitzu konektatu eta bere datuekin lan egin dezakeen kontzientzia-korronte orokorrean zentratu gaitezke. Horrek zerbitzuak eskalagarriagoak, trukagarriagoak eta autonomoagoak bihurtzen ditu. Beraz, arbeletan eta hipotesi probetan itxura ona ez ezik, hamarkadetan ere funtzionatu eta eboluzionatuko dute.
Iturria: www.habr.com