Arkitektura e Softuerit dhe Dizajni i Sistemeve: Udhëzuesi i Fotografisë së Madhe dhe Burimeve

Pershendetje kolege.

Sot ne ofrojmë për shqyrtimin tuaj një përkthim të një artikulli nga Tugberk Ugurlu, i cili mori përsipër të përvijojë në një vëllim relativisht të vogël parimet e projektimit të sistemeve moderne softuerike. Ja çfarë thotë autori për veten e tij në mënyrë të përmbledhur:

Arkitektura e Softuerit dhe Dizajni i Sistemeve: Udhëzuesi i Fotografisë së Madhe dhe Burimeve
Meqenëse është absolutisht e pamundur të mbulohet në një artikull habro një temë kaq kolosale si modelet arkitekturore + modelet e dizajnit që nga viti 2019, ne rekomandojmë jo vetëm tekstin e vetë z. Uruglu, por edhe lidhjet e shumta që ai përfshiu me dashamirësi në të. Nëse ju pëlqen, ne do të publikojmë një tekst më të specializuar në lidhje me projektimin e sistemeve të shpërndara.

Arkitektura e Softuerit dhe Dizajni i Sistemeve: Udhëzuesi i Fotografisë së Madhe dhe Burimeve

fotografi i çastit Isaac Smith nga Unsplash

Nëse kurrë nuk ju është dashur të përballeni me sfida të tilla si dizajnimi i një sistemi softuerësh nga e para, atëherë kur filloni një punë të tillë, ndonjëherë nuk është as e qartë se ku të filloni. Unë besoj se fillimisht duhet të vizatoni kufijtë në mënyrë që të keni një ide pak a shumë të sigurt se çfarë saktësisht do të dizajnoni dhe më pas të përveshni mëngët dhe të punoni brenda atyre kufijve. Si pikënisje, ju mund të merrni një produkt ose shërbim (në mënyrë ideale një që ju pëlqen vërtet) dhe të kuptoni se si ta zbatoni atë. Ju mund të habiteni se sa i thjeshtë duket ky produkt dhe sa kompleksitet përmban në të vërtetë. Mos harro: e thjeshtë - zakonisht e ndërlikuar, dhe kjo është në rregull.

Mendoj se këshilla më e mirë që mund t'i jap kujtdo që fillon të projektojë një sistem është kjo: mos bëni asnjë supozim! Që në fillim, ju duhet të specifikoni faktet e njohura për këtë sistem dhe pritshmëritë që lidhen me të. Këtu janë disa pyetje të mira për t'ju ndihmuar të filloni me dizajnin tuaj:

  • Cili është problemi që po përpiqemi të zgjidhim?
  • Cili është numri maksimal i përdoruesve që do të ndërveprojnë me sistemin tonë?
  • Çfarë modelesh të shkrimit dhe leximit të të dhënave do të përdorim?
  • Cilat janë rastet e pritshme të dështimit, si do t'i trajtojmë ato?
  • Cilat janë pritshmëritë për qëndrueshmërinë dhe disponueshmërinë e sistemit?
  • A duhet të merrni parasysh ndonjë kërkesë që lidhet me verifikimin dhe rregullimin e jashtëm kur punoni?
  • Çfarë lloje të të dhënave të ndjeshme do të ruajmë?

Këto janë vetëm disa pyetje që kanë qenë të dobishme si për mua ashtu edhe për ekipet në të cilat kam marrë pjesë gjatë viteve të aktivitetit profesional. Nëse i dini përgjigjet e këtyre pyetjeve (dhe çdo pyetje tjetër që është e rëndësishme për kontekstin në të cilin duhet të punoni), atëherë gradualisht mund të thelloheni në detajet teknike të problemit.

Vendosni nivelin fillestar

Çfarë dua të them me "bazë" këtu? Në fakt, në kohët tona, shumica e problemeve në industrinë e softuerit "mund" të zgjidhen duke përdorur metoda dhe teknologji ekzistuese. Prandaj, duke lundruar në këtë peizazh, ju merrni një fillim të caktuar kur përballeni me probleme që dikush tjetër duhej t'i zgjidhte para jush. Mos harroni se programet janë shkruar për të zgjidhur problemet e biznesit dhe përdoruesit, ndaj ne përpiqemi ta zgjidhim problemin në mënyrën më të drejtpërdrejtë dhe të thjeshtë (nga këndvështrimi i përdoruesit). Pse është e rëndësishme të mbahet mend kjo? Ndoshta në sistemin tuaj të koordinatave ju pëlqen të kërkoni zgjidhje unike për të gjitha problemet, sepse mendoni, "çfarë programuesi jam unë nëse ndjek modele kudo"? Në fakt, arti këtu është të marrë vendime se ku dhe çfarë të bëhet. Sigurisht, secili prej nesh duhet të përballet herë pas here me probleme unike, secila prej të cilave është një sfidë e vërtetë. Megjithatë, nëse niveli ynë fillestar është i përcaktuar qartë, atëherë ne e dimë se për çfarë të shpenzojmë energjinë tonë: kërkimin e opsioneve të gatshme për zgjidhjen e problemit të vendosur para nesh, ose studimin e mëtejshëm të tij dhe arritjen e një kuptimi më të thellë.

Unë mendoj se kam qenë në gjendje t'ju bind se nëse një specialist e kupton me siguri se cili është komponenti arkitektonik i disa sistemeve të mrekullueshme softuerike, atëherë kjo njohuri do të jetë e domosdoshme për zotërimin e artit të një arkitekti dhe zhvillimin e një baze solide në këtë fushë.

Mirë, pra nga të filloni? U Donna Martina Ekziston një depo në GitHub që quhet sistem-projektim-primer, nga e cila mund të mësoni se si të dizajnoni sisteme në shkallë të gjerë, si dhe të përgatiteni për intervista mbi këtë temë. Depoja ka një seksion me shembuj arkitektura reale, ku, në veçanti, konsiderohet se si i qasen projektimit të sistemeve të tyre disa kompani të njohurap.sh. Twitter, Uber etj.

Megjithatë, përpara se të kalojmë te ky material, le të hedhim një vështrim më të afërt në sfidat më të rëndësishme arkitekturore me të cilat përballemi në praktikë. Kjo është e rëndësishme sepse ju duhet të specifikoni SHUMË aspekte të një problemi kokëfortë dhe shumëplanësh dhe më pas ta zgjidhni atë brenda kornizës së rregulloreve në fuqi në një sistem të caktuar. Jackson Gabbard, ka shkruar një ish-punonjës në Facebook Video 50-minutëshe rreth intervistave të projektimit të sistemeve, ku ai ndau përvojën e tij të shqyrtimit të qindra aplikantëve. Ndërsa video fokusohet shumë në dizajnin e sistemit të madh dhe kriteret e suksesit që janë të rëndësishme kur kërkoni një kandidat për një pozicion të tillë, ajo do të vazhdojë të shërbejë si një burim gjithëpërfshirës se cilat gjëra janë më të rëndësishme gjatë dizajnimit të sistemeve. Unë gjithashtu sugjeroj përmbledhje kjo video.

Ndërtoni njohuri për ruajtjen dhe marrjen e të dhënave

Në mënyrë tipike, vendimi juaj për mënyrën se si i ruani dhe rikuperoni të dhënat tuaja për një afat të gjatë ka një ndikim kritik në performancën e sistemit. Prandaj, së pari duhet të kuptoni karakteristikat e pritshme të shkrimit dhe leximit të sistemit tuaj. Atëherë ju duhet të jeni në gjendje t'i vlerësoni këta tregues dhe të bëni zgjedhje bazuar në vlerësimet e bëra. Megjithatë, ju mund ta përballoni në mënyrë efektive këtë punë vetëm nëse i kuptoni modelet ekzistuese të ruajtjes së të dhënave. Në parim, kjo nënkupton njohuri solide në lidhje me përzgjedhja e bazës së të dhënave.

Bazat e të dhënave mund të mendohen si struktura të dhënash që janë jashtëzakonisht të shkallëzueshme dhe të qëndrueshme. Prandaj, njohja e strukturave të të dhënave duhet të jetë shumë e dobishme për ju kur zgjidhni një bazë të dhënash të veçantë. Për shembull, Redis është një server i strukturës së të dhënave që mbështet lloje të ndryshme vlerash. Kjo ju lejon të punoni me struktura të dhënash si listat dhe grupet, dhe të lexoni të dhëna duke përdorur algoritme të njohura, për shembull, LRU, duke organizuar një punë të tillë në një stil të qëndrueshëm dhe shumë të aksesueshëm.

Arkitektura e Softuerit dhe Dizajni i Sistemeve: Udhëzuesi i Fotografisë së Madhe dhe Burimeve

fotografi i çastit Samuel Zeller nga Unsplash

Pasi të keni një kuptim të mjaftueshëm të modeleve të ndryshme të ruajtjes së të dhënave, kaloni në studimin e konsistencës dhe disponueshmërisë së të dhënave. Para së gjithash, ju duhet të kuptoni Teorema CAP të paktën në terma të përgjithshëm, dhe më pas lëmoni këtë njohuri duke i hedhur një vështrim më të afërt modeleve të vendosura qëndrueshmëri и aksesueshmërisë. Në këtë mënyrë, ju do të zhvilloni një kuptim të fushës dhe do të kuptoni se leximi dhe shkrimi i të dhënave janë në fakt dy probleme shumë të ndryshme, secila me sfidat e veta unike. Të armatosur me disa modele qëndrueshmërie dhe disponueshmërie, ju mund të rrisni ndjeshëm performancën e sistemit duke siguruar rrjedhën e qetë të të dhënave në aplikacionet tuaja.

Së fundi, duke përfunduar bisedën rreth çështjeve të ruajtjes së të dhënave, duhet të përmendim edhe caching. A duhet të funksionojë njëkohësisht në klient dhe server? Cilat të dhëna do të jenë në cache-in tuaj? Dhe pse? Si e organizoni anulimin e cache-it? A do të bëhet rregullisht, në intervale të caktuara? Nëse po, sa shpesh? Unë rekomandoj të filloni të studioni këto tema me seksioni tjetër abetarja e lartpërmendur e projektimit të sistemit.

Modelet e komunikimit

Sistemet përbëhen nga komponentë të ndryshëm; këto mund të jenë procese të ndryshme që ekzekutohen brenda së njëjtës nyje fizike, ose makina të ndryshme që funksionojnë në pjesë të ndryshme të rrjetit tuaj. Disa nga këto burime brenda rrjetit tuaj mund të jenë private, por të tjerat duhet të jenë publike dhe të hapura për konsumatorët që i qasen nga jashtë.

Është e nevojshme të sigurohet komunikimi i këtyre burimeve me njëri-tjetrin, si dhe shkëmbimi i informacionit ndërmjet të gjithë sistemit dhe botës së jashtme. Në kontekstin e dizajnimit të sistemeve, këtu përsëri përballemi me një sërë sfidash të reja dhe unike. Le të shohim se si ato mund të jenë të dobishme rrjedhat asinkrone të detyrave, dhe çfarë pEkzistojnë një larmi modelesh komunikimi.

Arkitektura e Softuerit dhe Dizajni i Sistemeve: Udhëzuesi i Fotografisë së Madhe dhe Burimeve

fotografi i çastit Tony Stoddard nga Unsplash

Kur organizoni komunikim me botën e jashtme, është gjithmonë shumë e rëndësishme безопасность, sigurimi i të cilit gjithashtu duhet të merret seriozisht dhe të ndiqet në mënyrë aktive.

Shpërndarja e lidhjes

Nuk jam i sigurt se vendosja e kësaj teme në një seksion të veçantë do të duket e justifikuar për të gjithë. Megjithatë, unë do ta paraqes këtë koncept në detaje këtu dhe besoj se materiali në këtë seksion përshkruhet më saktë me termin "shpërndarje lidhjeje".

Sistemet formohen duke lidhur siç duhet shumë komponentë, dhe komunikimi i tyre me njëri-tjetrin shpesh organizohet në bazë të protokolleve të vendosura, për shembull, TCP dhe UDP. Megjithatë, këto protokolle si të tilla shpesh janë të pamjaftueshme për të përmbushur të gjitha nevojat e sistemeve moderne, të cilat shpesh operohen nën ngarkesë të lartë dhe gjithashtu varen shumë nga nevojat e përdoruesve. Shpesh është e nevojshme të gjenden mënyra për të shpërndarë lidhjet për të përballuar ngarkesa kaq të larta në sistem.

Kjo shpërndarje bazohet në të njohurit sistemi i emrave të domenit (DNS). Një sistem i tillë lejon transformimet e emrave të domenit, si p.sh. metoda të peshuara të rrumbullakëta dhe të bazuara në vonesë, për të ndihmuar në shpërndarjen e ngarkesës.

Balancimi i ngarkesës është thelbësisht i rëndësishëm dhe praktikisht çdo sistem i madh interneti me të cilin përballemi sot ndodhet prapa një ose më shumë balancuesve të ngarkesës. Balancuesit e ngarkesës ndihmojnë në shpërndarjen e kërkesave të klientit nëpër instanca të shumta të disponueshme. Balancuesit e ngarkesës vijnë si në harduer ashtu edhe në softuer, megjithatë, në praktikë, më shpesh duhet të merreni me ato softuerike, për shembull HAProxy и ELB. Përfaqësuesit e kundërt Konceptualisht gjithashtu shumë i ngjashëm me balancuesit e ngarkesës, megjithëse ka një diapazon midis të parit dhe të dytës dallime të dallueshme. Këto dallime duhet të merren parasysh kur hartoni një sistem bazuar në nevojat tuaja.

Ju gjithashtu duhet të dini për rrjetet e shpërndarjes së përmbajtjes (CDN). Një CDN është një rrjet i shpërndarë global i serverëve proxy që jep informacion nga nyjet që ndodhen gjeografikisht më afër një përdoruesi specifik. CDN-të preferohen të përdoren nëse punoni me skedarë statikë të shkruar në JavaScript, CSS dhe HTML. Për më tepër, shërbimet cloud që ofrojnë menaxherët e trafikut janë të zakonshme sot, për shembull, Menaxheri i Trafikut Azure, duke ju dhënë shpërndarje globale dhe vonesë të reduktuar kur punoni me përmbajtje dinamike. Sidoqoftë, shërbime të tilla zakonisht janë të dobishme në rastet kur duhet të punoni me shërbime të internetit pa shtetësi.

Le të flasim për logjikën e biznesit. Strukturimi i logjikës së biznesit, flukseve të detyrave dhe komponentëve

Pra, arritëm të diskutojmë aspekte të ndryshme infrastrukturore të sistemit. Me shumë mundësi, përdoruesi as nuk mendon për të gjithë këta elementë të sistemit tuaj dhe, sinqerisht, nuk kujdeset fare për to. Përdoruesi është i interesuar se si është të ndërveprosh me sistemin tënd, çfarë mund të arrihet duke bërë këtë, dhe gjithashtu se si sistemi ekzekuton komandat e përdoruesit, çfarë dhe si bën me të dhënat e përdoruesit.

Siç sugjeron titulli i këtij artikulli, unë do të flisja për arkitekturën e softuerit dhe dizajnin e sistemit. Prandaj, nuk kam planifikuar të mbuloj modelet e dizajnit të softuerit që përshkruajnë se si krijohen komponentët e softuerit. Megjithatë, sa më shumë që mendoj për këtë, aq më shumë më duket se linja midis modeleve të dizajnit të softuerit dhe modeleve arkitekturore është shumë e paqartë dhe të dy konceptet janë të lidhura ngushtë. Le të marrim për shembull regjistrimi i ngjarjes (burimi i ngjarjeve). Sapo të adoptoni këtë model arkitektonik, ai do të ndikojë pothuajse në çdo aspekt të sistemit tuaj: ruajtjen afatgjatë të të dhënave, nivelin e konsistencës të miratuar në sistemin tuaj, formën e përbërësve në të, etj., etj. Prandaj, vendosa të përmend disa modele arkitekturore që lidhen drejtpërdrejt me logjikën e biznesit. Edhe pse ky artikull do të duhet të kufizohet në një listë të thjeshtë, unë ju inkurajoj që të njiheni me të dhe të mendoni për idetë që lidhen me këto modele. Këtu jeni:

Qasjet bashkëpunuese

Është jashtëzakonisht e pamundur që ju të gjeni veten në një projekt si pjesëmarrës që është i vetmi përgjegjës për procesin e projektimit të sistemit. Përkundrazi, me shumë mundësi do t'ju duhet të ndërveproni me kolegët që punojnë brenda dhe jashtë detyrës suaj. Në këtë rast, mund t'ju duhet të vlerësoni zgjidhjet e përzgjedhura të teknologjisë me kolegët, të identifikoni nevojat e biznesit dhe të kuptoni se si të paralelizoni më mirë detyrat.

Arkitektura e Softuerit dhe Dizajni i Sistemeve: Udhëzuesi i Fotografisë së Madhe dhe Burimeve

fotografi i çastit Kaleidico nga Unsplash

Hapi i parë është të zhvilloni një kuptim të saktë dhe të përbashkët se cili është qëllimi i biznesit që po përpiqeni të arrini dhe me cilat pjesë lëvizëse do të duhet të përballeni. Teknikat e modelimit në grup, në veçanti ngjarje stuhie (stuhia e ngjarjeve) ndihmojnë për të shpejtuar ndjeshëm këtë proces dhe për të rritur shanset tuaja për sukses. Kjo punë mund të bëhet para ose pasi të përshkruani kufijtë e shërbimeve tuaja, dhe më pas thelloni atë ndërsa produkti maturohet. Bazuar në nivelin e konsistencës që do të arrihet këtu, mund të formuloni gjithashtu gjuha e përbashkët për kontekstin e kufizuar në të cilin punoni. Kur duhet të flisni për arkitekturën e sistemit tuaj, mund t'ju duket e dobishme modeli C4, propozuar Simon Brown, veçanërisht kur duhet të kuptoni se sa shumë do t'ju duhet të futeni në detajet e problemit, duke vizualizuar gjërat që dëshironi të komunikoni.

Ndoshta ekziston një teknologji tjetër e pjekur për këtë temë që nuk është më pak e dobishme sesa Dizajni i Drejtuar nga Domain. Megjithatë, ne disi i kthehemi të kuptuarit të fushës lëndore, pra njohurive dhe përvojës në këtë fushë Dizajn i drejtuar nga domeni duhet të jetë e dobishme për ju.

Burimi: www.habr.com

Shto një koment