Kaixo lankideok.
Gaurkoan, Tugberk Ugurlu-ren artikulu baten itzulpena eskaintzen dizugu, software sistema modernoak diseinatzeko printzipioak bolumen txiki samarrean azaltzeko konpromisoa hartu baitzuen. Hona hemen egileak bere buruaz dioena laburbilduz:
Erabat ezinezkoa denez habro artikulu batean 2019tik aurrera eredu arkitektonikoak + diseinu ereduak bezalako gai kolosala azaltzea, Uruglu jaunaren testua ez ezik, hark atsegin handiz sartu zituen esteka ugari ere gomendatzen ditugu. Gustatzen bazaizu, sistema banatuen diseinuari buruzko testu espezializatuagoa argitaratuko dugu.
argazkiaren Unsplash-etik
Inoiz software-sistema bat hutsetik diseinatzea bezalako erronkei aurre egin behar izan ez bazaizu, lan hori hastean, batzuetan ez dago argi nondik hasi. Uste dut lehenik eta behin mugak marraztu behar dituzula, diseinatuko duzunaren ideia gehiago edo gutxiago ziur izateko, eta gero mahukak bildu eta muga horien barruan lan egin. Abiapuntu gisa, produktu edo zerbitzu bat hartu dezakezu (egokiena benetan gustatzen zaizuna) eta nola inplementatu asma dezakezu. Produktu honek zeinen sinplea den eta zenbat konplexutasun duen benetan harrituko zaitu. Ez ahaztu: , eta hori ondo dago.
Sistema bat diseinatzen hasten den edonori eman diezaiokedan aholkurik onena hau dela uste dut: ez egin hipotesirik! Hasiera-hasieratik, sistema honi buruz ezagutzen diren gertakariak eta harekin lotutako itxaropenak zehaztu behar dituzu. Hona hemen zure diseinuarekin hasten laguntzeko egin beharreko galdera on batzuk:
- Zein da konpontzen saiatzen ari garen arazoa?
- Zein da gure sistemarekin elkarreragina izango duen erabiltzaile kopururik handiena?
- Zer idazteko eta irakurtzeko datuak erabiliko ditugu?
- Zeintzuk dira espero diren hutsegite kasuak, nola kudeatuko ditugu?
- Zeintzuk dira sistemaren koherentziarako eta erabilgarritasunerako itxaropenak?
- Kanpoko egiaztapenarekin eta erregulazioarekin lotutako eskakizunik kontuan hartu behar duzu lan egiterakoan?
- Zer motatako datu sentikorrak gordeko ditugu?
Galdera batzuk besterik ez dira, bai niri eta bai lanbide-jardueran urte hauetan parte hartu dudan taldeei erabilgarriak izan zaizkidan galderak. Galdera hauen erantzunak (eta lan egin behar duzun testuinguruari dagozkion beste batzuk) ezagutzen badituzu, pixkanaka arazoaren xehetasun teknikoetan sakondu dezakezu.
Ezarri hasierako maila
Zer esan nahi dut hemen "oinarrizko" hitzarekin? Egia esan, gure garaian, softwarearen industriako arazo gehienak lehendik dauden metodo eta teknologien bidez konpondu daitezke. Ondorioz, paisaia honetan nabigatuz, nolabaiteko hasiera lortzen duzu beste norbaitek aurretik konpondu behar izan dituen arazoen aurrean. Ez ahaztu programak negozio eta erabiltzaileen arazoak konpontzeko idatzita daudela, beraz, arazoa modurik zuzen eta errazenean (erabiltzailetik) konpontzen ahalegintzen gara. Zergatik da garrantzitsua hau gogoratzea? Agian zure koordenatu-sisteman arazo guztietarako soluzio bereziak bilatzea gustatzen zaizu, pentsatzen duzulako: βnolako programatzailea naiz ni nonahi ereduak jarraitzen baditutβ? Izan ere, hemen artea non eta zer egin erabakitzen da. Noski, gutako bakoitzak arazo bereziei aurre egin behar die noizean behin, eta horietako bakoitza benetako erronka da. Dena den, gure hasierako maila argi eta garbi zehaztuta badago, badakigu zertan gastatu behar dugun energia: aurretik jarritako arazoa konpontzeko prest dauden aukerak bilatzea, edo gehiago aztertzea eta ulermen sakona lortzea.
Uste dut konbentzitzeko gai izan nintzela espezialista batek konfiantzaz ulertzen badu software-sistema zoragarri batzuen osagai arkitektonikoa zein den, orduan ezagutza hori ezinbestekoa izango dela arkitektoaren artea menperatzeko eta alor honetan oinarri sendo bat garatzeko.
Ados, nondik hasi? U GitHub-en deitzen den biltegi bat dago , eta bertatik eskala handiko sistemak diseinatzen ikas dezakezu, baita gai honi buruzko elkarrizketak prestatzen ere. Biltegiak adibideekin atal bat dauka , non, bereziki, beren sistemen diseinuari nola heltzen dioten aztertzen den adibidez Twitter, Uber, etab.
Hala ere, material honi ekin baino lehen, ikus ditzagun hurbilagotik praktikan ditugun erronka arkitektoniko garrantzitsuenak. Hau garrantzitsua da arazo burugogor eta anitzeko alderdi ASKO zehaztu behar dituzulako, eta gero sistema jakin batean indarrean dagoen araudiaren barruan konpondu. , Facebookeko langile ohiak idatzi zuen , non ehunka eskatzaile bahitatzeko bere esperientzia partekatu zuen. Bideoak sistema handien diseinuan eta horrelako postuetarako hautagai bat bilatzerakoan garrantzitsuak diren arrakasta-irizpideetan arreta handia jartzen badu ere, sistemak diseinatzerakoan garrantzitsuenak zein diren jakiteko baliabide integral gisa balioko du. Nik ere proposatzen dut bideo hau.
Datuak gordetzeari eta berreskuratzeari buruzko ezagutzak eraikitzea
Normalean, epe luzera zure datuak gordetzeko eta berreskuratzeko moduari buruzko erabakiak eragin handia du sistemaren errendimenduan. Hori dela eta, lehenik eta behin zure sistemaren idazketa- eta irakurketa-ezaugarriak ulertu behar dituzu. Ondoren, adierazle hauek ebaluatu eta egindako ebaluazioen arabera aukerak egiteko gai izan behar duzu. Hala ere, lan honi eraginkortasunez aurre egin diezaiokezu lehendik dauden datuak biltegiratzeko ereduak ulertzen badituzu soilik. Printzipioz, horrek zerikusia duen ezagutza sendoa dakar .
Datu-baseak oso eskalagarriak eta iraunkorrak diren datu-egituratzat har daitezke. Hori dela eta, datu-egituren ezagutza oso erabilgarria izan beharko zenuke datu-base jakin bat aukeratzerakoan. Adibidez, Hainbat balio mota onartzen dituen datu-egituraren zerbitzari bat da. Datu-egiturekin lan egiteko aukera ematen du, hala nola zerrendak eta multzoak, eta datuak irakurtzeko algoritmo ezagunak erabiliz, adibidez, , horrelako lanak estilo iraunkor eta oso eskuragarrian antolatuz.
argazkiaren Unsplash-etik
Datuak biltegiratzeko ereduak nahikoa ulertzen dituzunean, joan datuen koherentzia eta erabilgarritasuna aztertzera. Lehenik eta behin, ulertu behar duzu termino orokorrean behintzat, eta gero ezagutza hori leundu, ezarritako ereduak gertutik aztertuz ΠΈ . Horrela, eremuaren ulermena garatuko duzu eta ulertuko duzu irakurketa eta idazketa datuak bi arazo oso desberdinak direla, bakoitzak bere erronka bereziak dituela. Koherentzia- eta erabilgarritasun-eredu batzuekin armatuta, sistemaren errendimendua nabarmen handi dezakezu zure aplikazioetarako datu-fluxua bermatuz.
Azkenik, datuak biltegiratzeko arazoei buruzko elkarrizketa amaituz, cachea ere aipatu behar dugu. Bezeroan eta zerbitzarian aldi berean exekutatu beharko litzateke? Zein datu egongo dira zure cachean? Eta zergatik? Nola antolatzen duzu cachearen baliogabetzea? Aldizka egingo al da, tarte jakin batzuetan? Baiezkoa bada, zenbat aldiz? Gai hauek aztertzen hastea gomendatzen dut aipatutako sistema diseinatzeko hasiera.
Komunikazio ereduak
Sistemak hainbat osagaiz osatuta daude; hauek nodo fisiko berean exekutatzen diren prozesu desberdinak izan daitezke, edo zure sareko atal ezberdinetan exekutatzen diren makina desberdinak izan daitezke. Zure sareko baliabide horietako batzuk pribatuak izan daitezke, baina beste batzuk publikoak izan beharko lirateke eta kanpotik atzitzen dituzten kontsumitzaileentzat irekiak izan behar dira.
Beharrezkoa da baliabide horien arteko komunikazioa bermatzea, baita sistema osoaren eta kanpoko munduaren arteko informazio-trukea ere. Sistemen diseinuaren testuinguruan, hemen berriro ere erronka berri eta berezi batzuen aurrean gaude. Ikus dezagun nola izan daitezkeen erabilgarriak , eta zer or.
argazkiaren Unsplash-etik
Kanpoko munduarekin komunikazioa antolatzerakoan, beti da oso garrantzitsua , eta horren xedapena ere serio eta aktiboki jarraitu behar da.
Konexioen banaketa
Ez nago ziur gai hau aparteko atal batean jartzea denontzat justifikatua irudituko zaionik. Hala ere, kontzeptu hau zehatz-mehatz aurkeztuko dut hemen, eta uste dut atal honetako materiala "konexio banaketa" terminoarekin deskribatzen dela zehatzen.
Sistemak osagai asko behar bezala konektatuz eratzen dira, eta elkarren arteko komunikazioa sarritan ezarritako protokoloen arabera antolatzen da, adibidez, TCP eta UDP. Dena den, protokolo hauek, berez, ez dira nahikoak izaten sistema modernoen behar guztiak asetzeko, askotan karga handiarekin funtzionatzen duten eta erabiltzaileen beharren menpekotasun handia dutenak ere. Askotan beharrezkoa da konexioak banatzeko moduak bilatzea sistemaren halako karga handiei aurre egiteko.
Banaketa hau ezagunan oinarritzen da (DNS). Sistema horrek domeinu-izen eraldaketak ahalbidetzen ditu, hala nola round robin haztatua eta latentzian oinarritutako metodoak karga banatzen laguntzeko.
funtsezkoa da, eta gaur egun jorratzen ditugun Interneteko sistema handi ia guztiak karga-orekatzaile baten edo gehiagoren atzean daude. Karga-orekatzaileek bezeroen eskaerak eskuragarri dauden hainbat instantziatan banatzen laguntzen dute. Karga-orekatzaileak bai hardwarean bai softwarean datoz, hala ere, praktikan, maizago softwareekin egin behar duzu aurre, adibidez ΠΈ . kontzeptualki ere karga-orekatzaileen oso antzekoa da, nahiz eta lehenengoaren eta bigarrenaren artean tartea egon . Desberdintasun horiek kontuan hartu behar dira zure beharretan oinarritutako sistema bat diseinatzerakoan.
Hori ere jakin beharko zenuke (CDN). CDN bat proxy zerbitzarien sare global banatu bat da, geografikoki erabiltzaile jakin batetik gertuago dauden nodoetatik informazioa ematen duena. CDNak erabiltzea hobe da JavaScript, CSS eta HTMLn idatzitako fitxategi estatikoekin lan egiten baduzu. Gainera, trafiko-kudeatzaileak eskaintzen dituzten hodeiko zerbitzuak ohikoak dira gaur egun, adibidez, , banaketa globala eta latentzia murriztua eduki dinamikoarekin lan egitean. Hala ere, zerbitzu horiek normalean erabilgarriak izan ohi dira estaturik gabeko web zerbitzuekin lan egin behar duzun kasuetan.
Hitz egin dezagun negozio-logikari buruz. Negozio-logika, ataza-fluxuak eta osagaiak egituratzea
Beraz, sistemaren azpiegituraren hainbat alderdi eztabaidatzea lortu genuen. Seguruenik, erabiltzaileak ez du zure sistemako elementu guzti horietaz pentsatzen eta, egia esanda, ez die batere axola. Erabiltzaileari interesatzen zaio zer den zure sistemarekin elkarreragina, zer lor daitekeen hau eginez, eta sistemak erabiltzailearen komandoak nola exekutatzen dituen, zer eta nola egiten dituen erabiltzaileen datuekin.
Artikulu honen izenburuak dioen bezala, software arkitekturari eta sistemaren diseinuari buruz hitz egingo nuen. Horren arabera, ez nuen asmorik software osagaiak nola sortzen diren deskribatzen duten software diseinu-ereduak estaltzea. Hala ere, zenbat eta gehiago pentsatu, orduan eta gehiago iruditzen zait softwarearen diseinu-ereduen eta arkitektura-ereduen arteko muga oso lausoa dela, eta bi kontzeptuak estuki lotuta daudela. Har dezagun adibidez (gertaeraren iturria). Eredu arkitektoniko hau hartzen duzunean, zure sistemaren ia alderdi guztietan eragina izango du: datuen epe luzerako biltegiratzea, zure sisteman hartutako koherentzia maila, bertako osagaien forma, etab., etab. Hori dela eta, negozio-logikarekin zuzenean lotuta dauden arkitektura eredu batzuk aipatzea erabaki nuen. Artikulu honek zerrenda soil batera mugatu beharko duen arren, hura ezagutzera eta eredu hauekin lotutako ideietan pentsatzera animatzen zaituztet. Hemen zaude:
- kontzeptua , zehazki, ,
Elkarlaneko ikuspegiak
Oso zaila da sistemaren diseinu prozesuaren arduradun bakarra den parte-hartzaile gisa proiektu batean aurkitzea. Aitzitik, ziurrenik zure zereginaren barruan zein kanpoan lan egiten duten lankideekin elkarreragin beharko duzu. Kasu honetan, baliteke aukeratutako soluzio teknologikoak lankideekin ebaluatu behar izatea, negozioaren beharrak identifikatu eta zereginak paralelizatzeko modurik onena ulertzeko.
argazkiaren Unsplash-etik
Lehen urratsa da lortzen saiatzen ari zaren negozio-helburua zein den eta zer pieza mugikorrekin egin behar dituzun ulermen zehatza eta partekatua garatzea. Taldeak modelatzeko teknikak, bereziki (gertaera ekaitzak) prozesu hau nabarmen bizkortzen eta arrakasta izateko aukerak areagotzen laguntzen du. Lan hau eskema aurretik edo ondoren egin daiteke , eta gero sakondu produktua heldu ahala. Hemen lortuko den koherentzia mailaren arabera, ere formula dezakezu lan egiten duzun testuinguru mugatuagatik. Zure sistemaren arkitekturari buruz hitz egin behar duzunean, baliagarria irudituko zaizu , proposatu , batez ere arazoaren xehetasunetan zenbat sartu beharko duzun ulertu behar duzunean, komunikatu nahi dituzun gauzak ikusiz.
Seguruenik, gai honi buruzko beste teknologia heldu bat dago, Domain Driven Design baino erabilgarria ez dena. Hala ere, nolabait irakasgaia ulertzera itzultzen gara, beraz, arloko ezagutza eta esperientzia erabilgarria izan behar dizu.
Iturria: www.habr.com