Përshëndetje, kolegë.
Sot po ju paraqesim përkthimin e artikullit nga Tugberk Ugurlu, i cili ka marrë përsipër të përmbledhë në një vëllim të vogël parimet e projektimit të sistemeve moderne të softuerit. Këtu është çfarë thotë autori për veten e tij në mënyrë të përmbledhur:
Duke qenë të pamundur të përfshihet në një artikull të vetëm një temë kaq të gjerë si modelet arkitekturore + modelet e projektimit sipas vitit 2019, rekomandojmë jo vetëm tekstin e zotit Ugurlu, por edhe shumicën e linkeve që ai ka vendosur në të. Nëse ju pëlqen – do të publikojmë edhe një tekst më të specializuar për projektimin e sistemeve të shpërndara.
Fotografia nga faqja Unsplash
Nëse keni pasur ndonjëherë sfida si projektimi i një sistemi softuerik nga fillimi, ndonjëherë është e vështirë të dihet nga të fillosh. Unë mendoj se fillimisht duhet të trazoni kufijtë, në mënyrë që të keni një ide më të qartë se çfarë saktësisht po planifikoni të dizajnoni, dhe pastaj – rrolling up your sleeves dhe punoni pa dalë jashtë këtyre kufijve. Një pikënisje mund të jetë ndonjë produkt ose shërbim (idealisht, diçka që ju pëlqen shumë) dhe ta shqyrtoni implementimin e tij. Mund të habiteni se sa e thjeshtë duket ky produkt dhe sa kompleksitet i madh fshihet në të. Mos harroni: , dhe kjo është në rregull.
Mendoj se këshilla më e mirë që mund t’i jap atyre që po fillojnë të projektojnë një sistem është: mos bëni asnjë supozim! Që në fillim, duhet të saktësoni faktet e njohura mbi këtë sistem dhe pritshmëritë lidhur me të. Ja disa pyetje të mira, përgjigjet e të cilave do t’ju ndihmojnë të filloni procesin e projektimit:
- Cila është problemi që po përpiqemi të zgjidhim?
- Cili është numri maksimal i përdoruesve që do të ndërveprojnë me sistemin tonë?
- Cilat janë modelet e regjistrimit dhe leximit të të dhënave që do të përdoren?
- Cilat janë rastet e pritura të dështimeve, dhe si planifikojmë t'i menaxhojmë ato?
- Cilat janë pritjet për qëndrushmërinë dhe disponueshmërinë e sistemit?
- A duhet të merret parasysh ndonjë kërkesë në lidhje me verifikimin e jashtëm dhe rregulloren gjatë punës?
- Cilat lloje të të dhënave të ndjeshme planifikojmë të ruajmë?
Këto janë disa pyetje që kanë ndihmuar si mua ashtu edhe ekipet e tjera me të cilat kam punuar gjatë viteve të karrierës time. Nëse keni përgjigje për këto pyetje (dhe për çdo pyetje tjetër të lidhur me kontekstin në të cilin punoni), mund të filloni të thelloheni në detajet teknike të detyrës.
Përcaktojmë nivelin fillestar
Çfarë kuptoj këtu me "nivelin fillestar" (baseline)? Në të vërtetë, në kohët tona, shumicën e problemeve në industrinë e softuerit "mund" t'i zgjidhni me ndihmën e metodave dhe teknologjive që tashmë ekzistojnë. Duke u orientuar në këtë peizazh, ju fitoni një avantazh kur përballeni me sfida që dikush ka pasur për të zgjidhur para jush. Mos harroni se programet shkruhen për të zgjidhur problemet e biznesit dhe përdoruesve, ndaj ne përpiqemi të zgjidhim sfidën në mënyrën më të thjeshtë dhe më të drejtpërdrejtë (nga pikëpamja e përdoruesit). Pse është e nevojshme të kujtohet kjo? Ndoshta, në sistemin tuaj koordinues, ju pëlqen të kërkoni zgjidhje unike për çdo sfidë, pasi mendoni, "si mund të jem programues i mirë nëse gjithmonë ndjek modelet"? Në të vërtetë, artit këtu qëndron në marrjen e vendimeve për atë se ku dhe çfarë të bëni. Sigurisht, çdo nga ne herë pas here përballet me probleme unike, secili prej të cilave është një sfidë e vërtetë. Megjithatë, nëse niveli ynë fillestar është qartë i përcaktuar, atëherë ne e dimë se për çfarë ta shpenzojmë energjinë: për të kërkuar zgjidhje të gatshme për detyrën që na është paraqitur, ose për ta studiuar atë më thellë dhe për të kuptuar më mirë.
Mendoj se kam arritur t'ju bind, se nëse një specialist ka njohuri të thella për përbërjen arkitekturore të disa sistemeve të shkëlqyera softuerike, ato njohuri do të jenë të paçmueshme për të zotëruar artin e arkitektit dhe për të ndërtuar një bazë solide në këtë fushë.
Mirë, nga ku duhet të fillojmë? Në ka një depo në GitHub të titulluar , nga materiali i së cilës do të mund të mësoni dizajnimin e sistemeve të mëdha, si dhe të përgatiteni për intervista në këtë temë. Në depo ka një seksion me shembuj , ku, për shembull, shqyrtohet si disa kompani të njohura .
Megjithatë, para se të kalojmë në këtë material, le të shqyrtojmë në detaje sfidat më të rëndësishme arkitektonike me të cilat përballemi në praktikë. Kjo është e rëndësishme, pasi duhet të konkretizojmë SHUMË aspekte të një problemi të ngritur dhe shumëdimensionale, dhe pastaj ta zgjidhim atë brenda rregulloreve në fuqi në këtë sistem. , një ish-punonjës i Facebook, regjistroi , ku ndau përvojën e tij mbi përzgjedhjen e qindra kandidatëve. Megjithëse videoja trajton në mënyrë të veçantë dizajnimin e sistemeve të mëdha dhe kriteret e suksesit që janë të rëndësishme kur kërkoni një kandidat për një pozicion të tillë, ajo do të shërbejë ende si një burim tërësor mbi kujt janë gjërat më të rëndësishme në dizajnimin e sistemeve. Gjithashtu, sugjeroj të kësaj videoje.
Zhvilloni njohuri mbi ruajtjen dhe nxjerrjen e të dhënave.
Zakonisht, vendimi juaj se si do t'i ruani dhe t'i jepni të dhënat tuaja në mënyrë afatgjatë ka një ndikim kritik në performancën e sistemit. Prandaj, ju duhet së pari të kuptoni karakteristikat e pritshme të shkruajtjes dhe të leximit të të dhënave në sistemin tuaj. Më pas, duhet të jeni në gjendje të vlerësoni këto tregues dhe të bëni zgjedhje duke iu referuar vlerësimeve të bëra. Megjithatë, ju do të jeni në gjendje të përballoni këtë detyrë me efikasitet vetëm nëse keni njohuri rreth modeleve ekzistuese të ruajtjes së të dhënave. Në thelb, kjo nënkupton njohuri të sigurta në lidhje me .
Baza e të dhënave mund të konsiderohet si struktura të dhënash që kanë shkallëzim dhe qëndrushmëri të jashtëzakonshme. Prandaj, njohuria e strukturave të dhënash duhet të jetë shumë e dobishme për ju edhe në përzgjedhjen e bazës së të dhënave. Për shembull, – është një server strukturash të dhënash që mbështet lloje të ndryshme vlerash. Ai lejon të punoni me struktura të dhënash si lista dhe grupe, të lexoni të dhëna duke përdorur algoritme të njohura, siç është , duke e organizuar një punë të tillë në një stil të qëndrueshëm dhe me akses të lartë.
Fotografia nga faqja Unsplash
Kur të keni një kuptim të mjaftueshëm të pattern-eve të ndryshme të ruajtjes së të dhënave – kaloni në studimin e konsistencës dhe disponueshmërisë së të dhënave. E para, do t'ju nevojitet të kuptoni të paktën në terma të përgjithshëm, dhe pastaj të rafinoni këto njohuri duke shqyrtuar më në detaje pattern-et e konsistencës dhe disponueshmërisë. Kështu do të krijoni një perspektivë të gjerë në këtë fushë dhe do të kuptoni se leximi dhe shkruajtja e të dhënave janë vërtet dy probleme shumë të ndryshme, dhe secili nga ato ka sfidat e veta të veçanta. Duke u pajisur me disa pattern-e për të siguruar konsistencën dhe disponueshmërinë, do të jeni në gjendje të rrisni ndjeshëm performancën e sistemit, duke garantuar një furnizim të pandërprerë të të dhënave në aplikacionet tuaja. dhe . Në këtë mënyrë, do të zgjerojë njohuritë tuaja në këtë fushë dhe do të kuptoni se leximi dhe shk writing i të dhënave janë në të vërtetë dy probleme shumë të ndryshme, dhe secila ka sfidat e saja të veçanta. Duke u fuqizuar me disa modele për sigurimin e koherencës dhe disponueshmërisë, do të jeni në gjendje të rrisni ndjeshëm performancën e sistemit, duke garantuar kështu një qarkullim të pandërprerë të të dhënave në aplikacionet tuaja.
Së fundi, për të përmbyllur bisedën mbi çështjet e ruajtjes së të dhënave, duhet të përmendim edhe për shpërndarjen e caches. A duhet ajo të realizohet në të njëjtën kohë si në klient ashtu edhe në server? Cilat të dhëna do të jenë në cache tuaj? Dhe pse? Si do ta organizoni invalidimin e caches? A do të realizohet ajo rregullisht, në intervale të caktuara? Nëse po, sa shpesh? Këto tema rekomandoj të filloni nga të përmendurit e librit mbi projektimin e sistemeve.
Modelet e komunikimit
Sistemet përbëhen nga komponentë të ndryshëm; këto mund të jenë si procese të ndryshme që punojnë brenda të njëjtit nod fizike, ashtu edhe makina të ndryshme që veprojnë në pjesë të ndryshme të rrjetit tuaj. Disa nga këto burime brenda rrjetit tuaj mund të jenë private, por të tjera duhet të jenë publike dhe të hapura për konsumatorët që i drejtohen nga jashtë.
Është e nevojshme të sigurohet komunikimi i këtyre burimeve me njëri-tjetrin, si dhe shkëmbimi i informacionit midis tërë sistemit dhe botës së jashtme. Në kontekstin e projektimit të sistemeve, këtu, përsëri, përballen me një set të ri sfidash unik. , dhe cilat r.
Fotografia nga faqja Unsplash
Kur organizoni komunikimin me botën e jashtme, është gjithmonë shumë e rëndësishme , që sigurimin e saj gjithashtu duhet ta trajtoni me seriozitet të plotë dhe të angazhoheni aktivisht.
Distribuimi i lidhjeve
Nuk jam i sigurt se avancimi i kësaj teme në një seksion të pavarur do të duket i arsyeshëm për të gjithë. Megjithatë, do ta shpjegoj këtë koncept këtu në mënyrë të hollësishme, duke besuar se materiali i këtij seksioni përshkruhet më saktë me termin "distribuimi i lidhjeve".
Sistemat formohet nga lidhja e saktë e shumë komponentëve, dhe komunikimi i tyre shpesh organizohet mbi baza protokolesh të njohura, si TCP dhe UDP. Megjithatë, këto protokolle shpesh nuk mjaftojnë për të përmbushur të gjitha nevojat e sistemeve moderne, të cilat shpesh operojnë nën ngarkesa të larta dhe varen shumë nga kërkesat e përdoruesve. Shpesh është e nevojshme të kërkohen mënyra për shpërndarjen e lidhjeve, për të përballuar këto ngarkesa të larta në sistem.
Në themel të këtij shpërndarjeje qëndron (DNS). Ky sistem lejon të konvertohet emri i domeneve, për shembull, algoritmi me cikle të peshuara (weighted round robin) dhe metodat e bazuara në vonesa, të cilat ndihmojnë në shpërndarjen e ngarkesës.
është thelbësore, dhe pothuajse çdo sistem i madh në internet që hasim sot ndodhet pas një ose disa balancuesve të ngarkesës. Balancuesit e ngarkesës ndihmojnë në shpërndarjen e kërkesave të klientëve në shumë instanca të disponueshme. Balancuesit e ngarkesës mund të jenë si harduerik ashtu edhe softuerik, megjithatë, në praktikë, shpesh kemi të bëjmë me ato softuerike, për shembull me dhe . konceptualisht janë gjithashtu shumë të ngjashëm me balancuesit e ngarkesës, megjithatë, mes të parëve dhe të dytëve ka një seri . Këto dallime duhet të merren parasysh, kur projektoni një sistem të përshtatur sipas nevojave tuaja.
Gjithashtu duhet të dimë për (CDN). CDN – është një rrjet global i shpërndarë i serverëve proxy, i cili transporton informacionin nga ato nyje që janë gjeografikisht më afër përdoruesit të caktuar. Rrjetet CDN preferohen të përdoren nëse punoni me skedarë statikë, të shkruar në JavaScript, CSS dhe HTML. Për më tepër, sot janë të njohura shërbimet cloud, të cilat ofrojnë menaxherë trafiku, për shembull, , duke ju siguruar shpërndarje globale dhe vonesa të reduktuara kur punoni me përmbajtje dinamike. Megjithatë, këto shërbime zakonisht janë të dobishme në situatat kur duhet të punoni me shërbime web pa ruajtje gjendjeje.
Të flasim rreth logjikës biznesore. Strukturimi i logjikës biznesore, rrjedhave të detyrave dhe komponentëve
Pra ndërrmend, ne kemi arritur të diskutojmë aspekte të ndryshme të infrastrukturës së sistemit. Me siguri, përdoruesi madje nuk mendon për të gjithë këta elemente të sistemit tuaj dhe, sinqerisht, as nuk e shqetësohet për ta. Përdoruesit i intereson se si është të ndërveprosh me sistemin tuaj, çfarë mund të arrijë duke vepruar kështu, dhe gjithashtu se si sistemi përmbush komandat e përdoruesit, çfarë bën me të dhënat e përdoruesit.
Siç kuptohet nga titulli i këtij artikulli, unë doja të flas për arkitekturën e softuerit dhe projektimin e sistemeve. Prandaj, nuk e kisha planifikuar të trajtoja modelet e projektimit të softuerit që përshkruajnë si krijohen komponentët e programit. Sidoqoftë, sa më shumë mendoj për këtë, aq më shumë më duket se kufiri mes modeleve të projektimit të softuerit dhe modeleve architekturore është shumë i turbullt, dhe këto dy koncepte janë ngushtë të lidhura. Le të marrim, për shembull, (event sourcing). Pasi e merrni në armët tuaja këtë model arkitekturor – ai do të ndikojë praktikisht në të gjitha aspektet e sistemit tuaj: ruajtja afatgjatë e të dhënave, niveli i koherencës që pranohet në sistemin tuaj, konturet e komponentëve brenda tij, etj., etj. Prandaj, vendosa të përmend disa modele arkitekturore që lidhen menjeherë me logjikën e biznesit. Edhe nëse në këtë artikull duhet të kufizohem në një listë të thjeshtë, ju rekomandoj të njiheni me të dhe të reflektoni mbi idetë që lidhen me këto modele. Ja pra:
- Koncesioni , në veçanti, ,
Qasje bashkëpunuese
Është jashtëzakonisht e pamundur të jesh pjesëmarrësi që është përgjegjës i vetëm për procesin e projektimit të sistemit. Në të vërtetë, është shumë më e mundshme që të duhet të bashkëpunosh me kolegët që punojnë, si brenda asaj çfarë po bën, ashtu edhe përtej saj. Në këtë rast, mund të jetë e nevojshme të vlerësosh zgjidhjet teknologjike të zgjedhura së bashku me kolegët, të nxjerrësh nevojat e biznesit dhe të kuptosh si të ndash më mirë detyrat.
Fotografia nga faqja Unsplash
Para së gjithash, do të jetë e nevojshme të zhvillohet një përfytyrim i saktë dhe i njohur mirë për atë që është qëllimi biznesor që po përpiqesh të arrish dhe me cilat elemente lëvizëse do të duhej të kishit të bëni. Teknikat e modelimit grupor, në veçanti, (event storming) ndihmojnë shumë për të përshpejtuar këtë proces dhe rrisin shanset tuaja për sukses. Kjo punë mund të fillohet para apo pas përkufizimit të , dhe pastaj të thellohet ndërsa produkti zhvillohet. Duke u mbështetur në nivelin e koherencës që do të arrihet këtu, gjithashtu mund të formulosh në atë kontekst të kufizuar ku punoni. Kur do të ndiheni të nevojshëm të flisni për arkitekturën e sistemit tuaj, modeli C4 mund të jetë i dobishëm. i propozuar , veçanërisht kur kërkohet të kuptohet se sa thellë do të duhet të zhyteni në detajet e problemit, vizualizoni gjërat që dëshironi të komunikoni.
Me siguri, në këtë temë do të gjeni edhe teknologji të tjera të pjekura, po aq të dobishme sa dizajni i orientuar nga objekti. Megjithatë, ne në çdo rast kthehemi te kuptimi i domenit, kështu që njohuritë dhe përvoja në fushën e duhet t'ju dobisnin.
Burimi: habr.com
