64,464 irakurketak

Software-sistemak diseinatzerakoan konplexutasunari nola aurre egin

arabera Aleksei23m2024/02/05

IDMore

Luzeegia; Irakurri

Konplexutasuna da etsaia! Ikas dezagun horri nola aurre egin!

featured image - Software-sistemak diseinatzerakoan konplexutasunari nola aurre egin

Zertan datza dena?

Egunero, gure ingeniaritza karrerako une bakoitzean, konplexutasun eta egoera ezberdinetako hainbat arazorekin topo egiten dugu, non datuen faltagatik erabaki bat hartu edo atzeratu behar dugun. Zerbitzu berriak eraikitzen ditugunean, azpiegiturak eraikitzen ditugunean edo garapen prozesuak osatzen ditugunean, hainbat erronka dituen mundu erraldoia ukitzen dugu.

Erronka da, eta agian ezinezkoa, arazo guztiak zerrendatzea. Arazo horietako batzuk aurkituko dituzu nitxo zehatz batean lan egiten baduzu. Bestalde, asko dira denok konpontzen ulertu behar ditugunak, funtsezkoak baitira informatika sistemak eraikitzeko. Probabilitate handiarekin, proiektu guztietan topatuko dituzu.

Artikulu honetan, nire esperientziak partekatuko ditut software programak sortzean aurkitu ditudan arazo batzuekin.

Zer da Zeharkako Kezka?

Wikipedian begiratuz gero, honako definizio hau aurkituko dugu

Alderdietara bideratutako softwarearen garapenean, zeharkako kezkak hainbat moduluri eragiten dioten programa baten alderdiak dira, haietako batean kapsulatzeko aukerarik gabe. Kezka hauek sarritan ezin dira sistemaren gainerakoetatik garbi deskonposatu bai diseinuan bai inplementazioan, eta sakabanaketa (kodeen bikoizketa), korapilatzea (sistemen arteko mendekotasun handiak) edo biak eragin ditzakete.

Asko deskribatzen du zer den, baina pixka bat luzatu eta sinplifikatu nahi dut:

Zeharkako kezka beste hainbat ataletan eragiten duen (edo "ebakitzen") sistema/erakundearen kontzeptu edo osagai bat da.

Kezka horien adibiderik onenak sistemaren arkitektura, erregistroa, segurtasuna, transakzioen kudeaketa, telemetria, datu-baseen diseinua eta beste asko dira. Horietako asko landuko ditugu geroago artikulu honetan.

Kode mailan, zeharkako kezkak sarritan inplementatzen dira Aspect-Oriented Programming (AOP) bezalako teknikak erabiliz, non kezka horiek aplikazioan zehar aplika daitezkeen osagai bereizietan modulartzen diren. Honek negozio-logika kezka horietatik isolatuta mantentzen du, kodea irakurgarriagoa eta mantentzegarriagoa bihurtuz.

Alderdien Sailkapena

Alderdiak sailkatzeko modu posible asko daude propietate ezberdinekin segmentatuta, hala nola esparrua, tamaina, funtzionaltasuna, garrantzia, xedea eta beste batzuk, baina artikulu honetan esparruaren sailkapen sinple bat erabiliko dut. Honekin, alderdi zehatz hori nora bideratzen den esan nahi dut erakunde osoa, sistema jakin bat edo sistema horren elementu zehatz bat dela.

Beraz, alderdiak makro eta mikrotan banatuko ditut.

Makro- alderdiarekin batez ere sistema osoarentzat jarraitzen ditugun gogoetak esan nahi dut, hala nola aukeratutako sistema-arkitektura eta bere diseinua (monolitikoa, mikrozerbitzuak, zerbitzuetara bideratutako arkitektura), teknologia-pila, antolaketa-egitura, etab. Makro- alderdiak estrategiko eta goi-mailakoekin lotuta daude batez ere. erabakiak.

Bitartean, Mikro alderdia kode mailatik eta garapenetik askoz hurbilago dago. Adibidez, datu-basearekin elkarreragiteko zein esparru erabiltzen den, karpeten eta klaseen proiektuen egitura edo baita objektuen diseinu eredu zehatzak ere.

Sailkapen hau aproposa ez den arren, balizko arazoen ulermena eta haiei aplikatzen dizkiegun irtenbideen garrantzia eta eragina egituratzen laguntzen du.

Artikulu honetan, nire arreta nagusia makro alderdietan izango da.

Makro-alderdiak

Antolaketa egitura

Software-arkitekturari buruz ikasten hasi nintzenean, artikulu interesgarri asko irakurri nituen Conway-ren legeari eta erakunde-egituran duen eraginari buruz. Batez ere hau . Beraz, lege honek hala dio

Sistema bat diseinatzen duen edozein erakundek (modu zabalean definitu dena) diseinu bat egingo du, zeinaren egitura erakundearen komunikazio egituraren kopia bat den.

Beti uste izan dut kontzeptu hau oso unibertsala dela eta Urrezko Araua adierazten duela.

Orduan Eric Evansen Domain-Driven Design (DDD) sistemak modelatzeko ikuspegia ikasten hasi nintzen. Eric Evansek Testuinguru mugatuaren identifikazioaren garrantzia azpimarratzen du. Kontzeptu honek domeinu-eredu konplexu bat atal txikiago eta kudeatuagoetan banatzea dakar, bakoitzak bere ezagutza multzo mugatuarekin. Ikuspegi honek talde-komunikazio eraginkorra laguntzen du, domeinu osoaren ezagutza zabalaren beharra murrizten baitu eta testuinguru-aldaketa gutxitzen baitu, horrela elkarrizketak eraginkorragoak izan daitezen. Testuingurua aldatzea inoizko gauzarik txarrena eta gehien kontsumitzen duen gauza da. Ordenagailuak ere borrokan ari dira. Nahiz eta nekez lortuko den testuinguru-aldaketarik ez izatea, uste dut hori dela ahalegindu beharko genukeena.

Conwayren legera itzuliz, hainbat arazo aurkitu ditut.

Conway-ren Legearekin topatu dudan lehen alea , sistemaren diseinuak antolakuntza-egitura islatzen duela iradokitzen duena, Testuinguru mugatuak konplexu eta integralak osatzeko ahalmena da. Konplexutasun hori antolakuntza-egitura domeinu-mugekin lerrokatzen ez denean sortzen da, eta elkarren mendekotasun handia duten eta informazioz kargatutako Testuinguru mugatuak sortzen dira. Garapen-taldearentzat maiz testuinguru-aldaketa dakar.

Beste arazo bat da erakundearen terminologia kode mailara isurtzen dela. Antolakuntza-egiturak aldatzen direnean, kode-basearen aldaketak behar dira, baliabide baliotsuak kontsumituz.

Horrela, Inverse Conway Manieuver jarraitzeak nahi den software-arkitektura bultzatzen duen sistema eta antolakuntza eraikitzen laguntzen du. Dena den, azpimarratzekoa da planteamendu honek ez duela oso ondo funtzionatuko lehendik eratutako arkitektura eta egituretan, fase honetan aldaketak luzatzen direnez, baina salbuespenezko errendimendua du startupetan, aldaketak azkar sartzen baitira.

Lokatz Bola Handia

Eredu edo "anti-eredu" honek inolako arkitekturarik gabeko sistema bat eraikitzea bultzatzen du. Ez dago araurik, ez mugarik, eta ez dago estrategia saihestezina gero eta handiagoa den konplexutasuna kontrolatzeko. Konplexutasuna da software sistemak eraikitzeko bidaian etsairik ikaragarriena.

Sistema mota bat eraikitzea saihesteko, arau eta muga zehatzak jarraitu behar ditugu.

Sistemaren arkitektura

Software arkitekturarako definizio ugari daude. Horietako asko gustatzen zaizkit, alderdi desberdinak lantzen dituztelako. Dena den, arkitekturari buruz arrazoitu ahal izateko, naturaltasunez osatu behar ditugu horietako batzuk gure buruan. Eta aipagarria da definizio horrek eboluzionatu dezakeela esatea. Beraz, oraingoz behintzat, honako deskribapen hau daukat niretzat.

Softwarearen arkitektura eraikitako sisteman eragina duten egunero hartzen dituzun erabaki eta aukerei buruzkoa da.

Sortzen diren arazoak konpontzeko "poltsan" eduki behar dituzun erabakiak hartzeko, ezinbestekoa da eskakizunak ulertzea funtsezkoa dela enpresa batek behar duena eraikitzeko. Hala ere, batzuetan eskakizunak ez dira gardenak edo ez daude zehaztuta, kasu honetan, hobe da argitasun gehiago lortzeko itxarotea edo zure esperientzian fidatzea eta zure intuizioan fidatzea. Baina, dena den, ezin duzu erabaki behar bezala hartu printzipio eta ereduetan oinarritzeko ez baduzu. Horra nator Software Arkitektura Estiloaren definiziora.

Softwarearen arkitektura estiloa softwarea nola eraikitzen den adierazten duten printzipio eta eredu multzo bat da.

Planifikatutako arkitekturaren hainbat aldetara bideratutako arkitektura-estilo asko daude, eta horietako anitz aldi berean aplikatzea egoera normala da.

Adibidez, esaterako:

Arkitektura monolitikoa
Domeinuak gidatutako diseinua
Osagaietan oinarrituta
Mikrozerbitzuak
Hodia eta iragazkiak
Gertaerak bultzatuta
Mikrokernel
Zerbitzuetara bideratua

eta abar…

Noski, abantailak eta desabantailak dituzte, baina ikasi dudan gauzarik garrantzitsuena da arkitektura pixkanaka eboluzionatzen dela benetako arazoen arabera. Arkitektura monolitikoan hastea aukera bikaina da konplexutasun operatiboak murrizteko, oso litekeena da arkitektura hau zure beharretara egokitzea produktua eraikitzeko Produktu-merkatuaren egokitzapena (PMI) fasera iritsi eta gero ere. Eskala mailan, gertaeren ikuspegitik eta mikrozerbitzuetara joatea pentsa dezakezu, inplementazio independentea, teknologia-pilaketa ingurune heterogeneoa eta arkitektura gutxiago akoplatua lortzeko (eta, bien bitartean, gardentasun gutxiagokoa, gertaeren eta pub-sub ikuspegien izaera dela eta, baldin eta hauek hartzen dira). Sinpletasuna eta eraginkortasuna gertu daude eta eragin handia dute elkarrengan. Normalean, arkitektura konplikatuek funtzio berrien garapen-abiaduran eragina dute, lehendik daudenak onartzen eta mantenduz eta sistemaren bilakaera naturala zalantzan jartzen dute.

Hala ere, sistema konplexuek askotan arkitektura konplexu eta integrala behar dute, eta hori saihestezina da.

Nahiko, oso gai zabala da hau, eta eboluzio naturalerako sistemak egituratu eta eraikitzeko ideia bikain asko daude. Nire esperientzian oinarrituta, honako ikuspegi hau landu dut:

Ia beti arkitektura monolitiko estilotik hasten da, sistema banatuen izaeragatik sortzen diren arazo gehienak ezabatzen baititu. Zentzuzkoa da monolito modularra jarraitzea muga argiak dituzten osagaiak eraikitzeko. Osagaietan oinarritutako ikuspegia aplikatzeak elkarren artean komunikatzen lagun diezaieke gertaerak erabiliz, baina zuzeneko deiak (RPC) izateak gauzak errazten ditu hasieran. Hala ere, garrantzitsua da osagaien arteko mendekotasunak jarraitzea, izan ere, A osagaiak B osagaiari buruz asko badaki, agian, zentzuzkoa da horiek bakarrean batzea.
Zure garapena eta sistema eskalatu behar dituzun egoerara hurbiltzen zarenean, Sangler eredua jarraitzea kontuan hartu dezakezu modu independentean zabaldu edo eskakizun zehatzekin eskalatu behar diren osagaiak pixkanaka ateratzeko.
Orain, etorkizunaren ikuspegi argia baduzu, zorte ikaragarria dena, nahi duzun arkitektura erabaki dezakezu. Momentu honetan, mikrozerbitzuen arkitekturara joatea erabaki dezakezu, Orkestrazio eta Koreografia ikuspegiak ere aplikatuz, CQRS eredua sartuz eskala independenteko idazketa eta irakurketa eragiketetarako, edo baita arkitektura monolitikoarekin jarraitzea erabakiz zure beharretara egokitzen bada.

Era berean, ezinbestekoa da DAU (Eguneroko Erabiltzaile Aktiboak), MAU (Hileroko Erabiltzaile Aktiboak), RPC (Segundoko eskaera) eta TPC (Segundoko Transakzioa) bezalako zenbakiak eta neurketak ulertzea, aukerak egiten lagun zaitzakeelako arkitekturak. 100 erabiltzaile aktibo eta 100 milioi erabiltzaile aktibo desberdinak dira.

Azken ohar gisa, esango nuke arkitekturak eragin handia duela produktuaren arrakastan. Produktuentzako gaizki diseinatutako arkitektura behar da eskalatzean, eta horrek oso litekeena da porrota ekartzea, bezeroek ez baitute itxarongo sistema eskalatzen duzun bitartean, lehiakide bat aukeratuko dute, beraz, balizko eskalatzearen aurretik egon behar dugu. Onartzen dudan arren, batzuetan ezin dela planteamendu lean izan, ideia da sistema eskalagarria baina jada eskalatua ez izatea. Bestalde, bezerorik edo horietako asko lortzeko planik gabeko sistema oso konplikatua eta jada eskalatua izateak dirua kostatuko zaizu zure negozioan ezertarako.

Teknologia pila hautatzea

Pila teknologikoa hautatzea makro-mailako erabakia ere bada, kontratazioan, sistemaren bilakaera naturalaren ikuspegian, eskalagarritasunean eta sistemaren errendimenduan eragiten baitu.

Hau da teknologia pila bat aukeratzeko oinarrizko gogoeten zerrenda:

Proiektuaren baldintzak eta konplexutasuna. Esate baterako, web-aplikazio sinple bat eraiki daiteke Blazor esparruarekin zure garatzaileek esperientzia badute, baina WebAssembly-ren heldutasun falta dela eta, epe luzerako arrakasta izateko React eta Typescript aukeratzea erabaki hobea izan liteke.
Eskalagarritasuna eta errendimendu beharrak. Trafiko kopuru handia jasotzea aurreikusten baduzu, Django-ren ASP.NET Core aukeratzea aukera egokia izan liteke aldibereko eskaerak kudeatzeko errendimendu handia duelako. Hala ere, erabaki hori espero duzun trafiko-mailaren araberakoa da. Latentzia baxuarekin milaka milioi eskaera kudeatu behar badituzu, Zabor Bilketa egotea erronka izan liteke.
Kontratazioa, garapen denbora eta kostua. Kasu gehienetan, hauek dira zaindu behar ditugun faktoreak. Merkaturatzeko denborak, Mantentze-kostuak eta Kontratazio-egonkortasunak zure negozioaren beharrak oztoporik gabe bultzatzen ditu.
Taldearen esperientzia eta baliabideak. Zure garapen taldearen trebetasun multzoa faktore kritikoa da. Orokorrean eraginkorragoa da zure taldeak dagoeneko ezagutzen dituen teknologiak erabiltzea pila berri bat ikasten inbertitzeko arrazoi sendorik ez badago.
Heldutasuna. Komunitate sendo batek eta liburutegi eta tresnen ekosistema aberats batek garapen prozesua asko erraztu dezakete. Teknologia ezagunek sarritan komunitatearen laguntza hobea dute, eta hori ezinbestekoa izan daiteke arazoak konpontzeko eta baliabideak aurkitzeko. Horrela, baliabideak aurreztu ditzakezu eta produktuan zentratu batik bat.
Epe luzeko mantentze-lanak eta laguntzak. Kontuan izan teknologiaren epe luzerako bideragarritasuna. Askotan onartu eta onartzen diren teknologiak ez dira zaharkitu eta, oro har, eguneraketak eta hobekuntzak jasotzen dituztenak.

Nola eragin dezake enpresaren hazkuntzan hainbat teknologia pila edukitzeak?

Ikuspegi batetik, pila bat gehiago sartzeak zure kontratazioa eskala dezake, baina, bestetik, mantentze-kostu gehigarriak ekartzen ditu bi pilak onartu behar dituzulako. Beraz, lehen esan dudan bezala, nire ikuspuntutik, aparteko beharrak baino ez luke izan behar teknologia pila gehiago sartzeko argudio bat.

Baina zer da arazo zehatz baterako tresna onena hautatzeko printzipioa?

Batzuetan, arazo zehatz bat konpontzeko tresna berriak ekartzea beste aukerarik ez duzu lehen aipatutako gogoeta berdinetan oinarrituta, kasu horietan, zentzuzkoa da irtenbiderik onena hautatzea.

Teknologia zehatz batekin akoplamendu handirik gabeko sistemak sortzea erronka bat izan liteke. Hala eta guztiz ere, lagungarria da sistema teknologiarekin estuki lotuta ez dagoen egoera batean ahalegintzea, eta ez da hilko bihar, esparru edo tresna zehatz bat zaurgarri bihurtzen bada edo are zaharkituta geratzen bada.

Beste kontu garrantzitsu bat kode irekiko eta jabedun software menpekotasunekin lotuta dago. Software jabedunak malgutasun gutxiago eta pertsonalizatzeko aukera ematen dizu. Hala ere, faktore arriskutsuena saltzaileen blokeoa da, non saltzaile baten produktuen, prezioen, baldintzen eta bide-orriaren menpe bihurtzen zaren. Arriskutsua izan daiteke saltzaileak norabidea aldatzen badu, prezioak igotzen baditu edo produktua eten egiten badu. Kode irekiko softwareak arrisku hori murrizten du, entitate bakar batek ez baitu kontrolatzen. Maila guztietan hutsegite puntu bakarra ezabatzea gakoa da hazkunderako sistema fidagarriak eraikitzeko.

Huts-puntu bakarra (SPOF)

Hutsegite puntu bakar batek (SPOF) sistema baten edozein zatiri egiten dio erreferentzia, huts egiten badu, sistema osoa funtzionatzeari utziko dion. Maila guztietan SPOF ezabatzea erabakigarria da erabilgarritasun handia behar duen edozein sistemarentzat. Guztiak, ezagutzak, langileak, sistemaren osagaiak, hodeiko hornitzaileak eta Interneteko kableak barne, huts egin dezake.

Porrot puntu bakarrak kentzeko aplika genitzakeen oinarrizko teknika batzuk daude:

Erredundantzia. Osagai kritikoetarako erredundantzia ezartzea. Horrek esan nahi du osagai nagusiek huts egiten badute ordezko osagaiak izatea. Erredundantzia sistemaren geruza ezberdinetan aplika daiteke, hardwarea (zerbitzariak, diskoak), sareak (estekak, etengailuak) eta softwarea (datu-baseak, aplikazio-zerbitzariak) barne. Hodeiko hornitzaile batean dena ostatatzen ari bazara eta bertan babeskopiak badituzu ere, kontuan hartu ohiko babeskopia gehigarri bat eraikitzea beste batean, hondamendia gertatuz gero galdutako kostua murrizteko.
Datu Zentroak. Banatu zure sistema hainbat kokapen fisikotan, hala nola datu-zentroetan edo hodei-eskualdeetan. Planteamendu honek zure sistema babesten du kokapen zehatzeko hutsegiteetatik, hala nola, elektrizitate-eteteak edo hondamendi naturalak.
Hutsegitea. Aplikatu hutsegitearen ikuspegia zure osagai guztientzat (DNS, CDN, karga-orekatzaileak, Kubernetes, API Gateways eta Datu-baseak). Arazoak ustekabean sor daitezkeenez, funtsezkoa da babeskopia-plan bat edukitzea edozein osagai bere klonarekin azkar ordezkatzeko.
Erabilgarritasun handiko zerbitzuak. Ziurtatu zure zerbitzuak hasieratik horizontalki eskalagarriak izan daitezen eta oso erabilgarri izateko eraikita daudela, printzipio hauek betez:
- Praktikatu zerbitzuaren aberrigabetasuna eta saihestu erabiltzaileen saioak memoriako cacheetan gordetzea. Horren ordez, erabili banatutako cache-sistema bat, adibidez, Redis.
- Logika garatzean mezuen kontsumoaren ordena kronologikoan konfiantza izatea saihestu.
- Minimizatu aldaketa aldaketak API kontsumitzaileak etetea saihesteko. Ahal den neurrian, alderantziz bateragarriak diren aldaketak aukeratu. Gainera, kontuan hartu kostua, batzuetan, aldaketa haustura bat ezartzea kostu-eraginkorragoa izan daitekeelako.
- Sartu migrazioaren exekuzioa hedapen-bidean.
- Aldibereko eskaerak kudeatzeko estrategia bat ezartzea.
- Ezarri zerbitzuen aurkikuntza, jarraipena eta erregistroa fidagarritasuna eta behagarritasuna hobetzeko.
- Garatu negozio-logika idempotente izateko, sarearen hutsegiteak saihestezinak direla onartuz.
Mendekotasunaren berrikuspena. Kanpoko menpekotasunak aldizka berrikusi eta gutxitu. Kanpoko mendekotasun bakoitzak SPOF potentzialak sar ditzake, beraz, ezinbestekoa da arrisku horiek ulertzea eta arintzea.
Ezagutza erregularra partekatzea. Ez ahaztu inoiz zure erakundean ezagutza zabaltzearen garrantzia. Pertsonak ezustekoak izan daitezke, eta pertsona bakar batean konfiantza izatea arriskutsua da. Taldekideek euren ezagutzak dokumentazioaren bidez digitalizatzera bultzatu. Hala ere, kontutan izan gehiegi dokumentatzea. Erabili AI tresna ezberdinak prozesu hau errazteko.