Pozdravljeni kolegi.
Danes vam v razmislek ponujamo prevod članka Tugberka Ugurluja, ki se je zavezal, da bo v razmeroma majhnem obsegu orisal načela oblikovanja sodobnih programskih sistemov. Evo, kaj avtor na kratko pravi o sebi:
Ker je od leta 2019 absolutno nemogoče zajeti v habro članku tako gromozansko temo, kot so arhitekturni vzorci + oblikovalski vzorci, priporočamo ne le samo besedilo gospoda Urugluja, temveč tudi številne povezave, ki jih je prijazno vključil vanj. Če vam bo všeč, bomo objavili bolj specializirano besedilo o načrtovanju porazdeljenih sistemov.
Posnetek od Unsplash
Če se vam še nikoli ni bilo treba soočiti s takšnimi izzivi, kot je načrtovanje programskega sistema iz nič, potem ob začetku takšnega dela včasih sploh ni jasno, kje začeti. Menim, da je treba najprej začrtati meje, da imaš bolj ali manj prepričano predstavo, kaj točno boš oblikoval, potem pa zavihati rokave in delati znotraj teh meja. Za izhodišče lahko vzamete izdelek ali storitev (v idealnem primeru takšno, ki vam je res všeč) in ugotovite, kako jo implementirati. Morda boste presenečeni, kako preprost je videti ta izdelek in koliko zapletenosti dejansko vsebuje. Ne pozabi: , in to je v redu.
Mislim, da je najboljši nasvet, ki ga lahko dam vsakomur, ki začne načrtovati sistem, naslednji: ne delajte nobenih predpostavk! Že na samem začetku morate navesti znana dejstva o tem sistemu in pričakovanja, povezana z njim. Tukaj je nekaj dobrih vprašanj, ki vam bodo pomagala začeti z oblikovanjem:
- Kaj je problem, ki ga poskušamo rešiti?
- Kakšno je najvišje število uporabnikov, ki bodo komunicirali z našim sistemom?
- Kakšne vzorce pisanja in branja podatkov bomo uporabljali?
- Kakšni so pričakovani primeri neuspeha, kako jih bomo obravnavali?
- Kakšna so pričakovanja glede doslednosti in razpoložljivosti sistema?
- Ali morate pri delu upoštevati kakšne zahteve v zvezi z zunanjim preverjanjem in predpisi?
- Katere vrste občutljivih podatkov bomo hranili?
To je le nekaj vprašanj, ki so v letih poklicnega delovanja koristila tako meni kot ekipam, v katerih sem sodeloval. Če poznate odgovore na ta vprašanja (in vsa druga, ki so pomembna za kontekst, v katerem morate delati), potem se lahko postopoma poglobite v tehnične podrobnosti problema.
Nastavite začetno raven
Kaj tukaj mislim z "izhodiščem"? Pravzaprav je v našem času večino problemov v industriji programske opreme "mogoče" rešiti z obstoječimi metodami in tehnologijami. Zato s krmarjenjem po tej pokrajini dobite določeno prednost, ko se soočite s težavami, ki jih je moral rešiti nekdo drug pred vami. Ne pozabite, da so programi napisani za reševanje poslovnih in uporabniških problemov, zato se trudimo, da problem rešimo na najbolj enostaven in (z vidika uporabnika) način. Zakaj si je to pomembno zapomniti? Morda v svojem koordinatnem sistemu radi iščete unikatne rešitve za vse probleme, ker si mislite, »kakšen programer sem, če se povsod ravnam po vzorcih«? Pravzaprav, umetnost tukaj je odločanje o tem, kje in kaj narediti. Seveda se mora vsak od nas kdaj pa kdaj spopasti z edinstvenimi težavami, od katerih je vsaka pravi izziv. Če pa je naša začetna raven jasno definirana, potem vemo, za kaj porabiti svojo energijo: za iskanje že pripravljenih možnosti za rešitev postavljenega problema ali za njegovo nadaljnje preučevanje in globlje razumevanje.
Mislim, da sem vas lahko prepričal, da če strokovnjak samozavestno razume, kaj je arhitekturna komponenta nekaterih čudovitih programskih sistemov, potem bo to znanje nepogrešljivo za obvladovanje umetnosti arhitekta in razvoj trdne osnove na tem področju.
V redu, kje torej začeti? U Na GitHubu obstaja repozitorij, imenovan , iz katerega se lahko naučite načrtovanja velikih sistemov, pa tudi pripravite se na intervjuje na to temo. Repozitorij ima razdelek s primeri , kjer se predvsem pretehta, kako se lotevajo načrtovanja svojih sistemov npr. Twitter, Uber itd.
Preden pa preidemo na to gradivo, si poglejmo podrobneje najpomembnejše arhitekturne izzive, s katerimi se srečujemo v praksi. To je pomembno, ker moraš določiti ŠTEVIK vidikov trdovratnega in večplastnega problema in ga nato rešiti v okviru predpisov, ki veljajo v danem sistemu. , je zapisal nekdanji uslužbenec Facebooka , kjer je delil lastno izkušnjo s pregledom na stotine prosilcev. Medtem ko se videoposnetek močno osredotoča na načrtovanje velikih sistemov in merila uspeha, ki so pomembna pri iskanju kandidata za takšen položaj, bo še vedno služil kot obsežen vir o tem, kaj je najpomembnejše pri načrtovanju sistemov. tudi predlagam ta video.
Pridobite znanje o shranjevanju in pridobivanju podatkov
Običajno vaša odločitev o tem, kako dolgoročno shranjujete in pridobivate svoje podatke, kritično vpliva na delovanje sistema. Zato morate najprej razumeti pričakovane lastnosti pisanja in branja vašega sistema. Nato morate biti sposobni ovrednotiti te kazalnike in se odločiti na podlagi opravljenih ocen. Vendar se lahko s tem delom učinkovito spopadete le, če razumete obstoječe vzorce shranjevanja podatkov. To načeloma pomeni dobro znanje v zvezi z .
Podatkovne baze si lahko predstavljamo kot podatkovne strukture, ki so izjemno razširljive in trajne. Zato bi vam moralo biti poznavanje podatkovnih struktur zelo koristno pri izbiri določene podatkovne baze. na primer je strežnik podatkovne strukture, ki podpira različne vrste vrednosti. Omogoča vam delo s podatkovnimi strukturami, kot so seznami in nizi, ter branje podatkov z uporabo znanih algoritmov, na primer , organiziranje takega dela v trajnem in zelo dostopnem slogu.
Posnetek od Unsplash
Ko boste dovolj razumeli različne vzorce shranjevanja podatkov, nadaljujte s preučevanjem doslednosti in razpoložljivosti podatkov. Najprej morate razumeti vsaj na splošno, nato pa to znanje izpiliti s podrobnejšim ogledom ustaljenih vzorcev и . Na ta način boste razvili razumevanje področja in razumeli, da sta branje in pisanje podatkov pravzaprav dve zelo različni težavi, vsaka s svojimi edinstvenimi izzivi. Oboroženi z nekaj vzorci doslednosti in razpoložljivosti lahko znatno povečate zmogljivost sistema, hkrati pa zagotovite nemoten pretok podatkov v vaše aplikacije.
Na koncu, če zaključimo pogovor o težavah s shranjevanjem podatkov, je treba omeniti še predpomnjenje. Ali naj deluje istočasno na odjemalcu in strežniku? Kateri podatki bodo v vašem predpomnilniku? In zakaj? Kako organizirate razveljavitev predpomnilnika? Se bo to izvajalo redno, v določenih intervalih? Če da, kako pogosto? Priporočam, da te teme začnete preučevati z zgoraj omenjeni temelj za načrtovanje sistema.
Komunikacijski vzorci
Sistemi so sestavljeni iz različnih komponent; to so lahko različni procesi, ki se izvajajo znotraj istega fizičnega vozlišča, ali različni stroji, ki se izvajajo na različnih delih vašega omrežja. Nekateri od teh virov v vašem omrežju so lahko zasebni, drugi pa morajo biti javni in odprti za uporabnike, ki do njih dostopajo od zunaj.
Zagotoviti je treba komunikacijo teh virov med seboj, kakor tudi izmenjavo informacij med celotnim sistemom in zunanjim svetom. V kontekstu načrtovanja sistemov se tudi tu soočamo z vrsto novih in edinstvenih izzivov. Poglejmo, kako so lahko koristni , in kaj str.
Posnetek od Unsplash
Pri organizaciji komunikacije z zunanjim svetom je vedno zelo pomembno , katerega zagotavljanje je prav tako treba jemati resno in se aktivno lotiti.
Distribucija povezave
Nisem prepričan, da se bo umestitev te teme v ločen razdelek vsem zdela upravičena. Kljub temu bom ta koncept tukaj podrobno predstavil in menim, da je gradivo v tem razdelku najnatančneje opisano z izrazom »razporeditev povezav«.
Sistemi nastanejo s pravilnim povezovanjem številnih komponent, njihova medsebojna komunikacija pa je pogosto organizirana na podlagi uveljavljenih protokolov, na primer TCP in UDP. Vendar ti protokoli kot taki pogosto ne zadoščajo za vse potrebe sodobnih sistemov, ki pogosto delujejo pod velikimi obremenitvami in so tudi zelo odvisni od potreb uporabnikov. Pogosto je treba poiskati načine za porazdelitev povezav, da bi se spopadli s tako visokimi obremenitvami sistema.
Ta porazdelitev temelji na znanem (DNS). Takšen sistem omogoča transformacije domenskih imen, kot so tehtano kroženje in metode, ki temeljijo na zakasnitvah, za pomoč pri porazdelitvi obremenitve.
je bistveno pomemben in skoraj vsak velik internetni sistem, s katerim imamo opravka danes, se nahaja za enim ali več izravnalniki obremenitve. Izravnalniki obremenitve pomagajo porazdeliti zahteve odjemalcev med več razpoložljivih primerkov. Izravnalniki obremenitve so tako strojni kot programski, vendar se v praksi pogosteje srečujete s programskimi, npr. и . konceptualno tudi zelo podoben load balancerjem, čeprav je razpon med prvim in drugim . Te razlike je treba upoštevati pri načrtovanju sistema glede na vaše potrebe.
Vedeti bi morali tudi o (CDN). CDN je globalno porazdeljeno omrežje proxy strežnikov, ki dostavlja informacije iz vozlišč, ki so geografsko bližje določenemu uporabniku. CDN je bolje uporabiti, če delate s statičnimi datotekami, napisanimi v JavaScript, CSS in HTML. Poleg tega so storitve v oblaku, ki zagotavljajo upravljavce prometa, danes običajne, na primer , ki vam omogoča globalno distribucijo in zmanjšano zakasnitev pri delu z dinamično vsebino. Vendar so takšne storitve običajno uporabne v primerih, ko morate delati s spletnimi storitvami brez stanja.
Pogovorimo se o poslovni logiki. Strukturiranje poslovne logike, tokov nalog in komponent
Tako smo uspeli razpravljati o različnih infrastrukturnih vidikih sistema. Najverjetneje uporabnik sploh ne pomisli na vse te elemente vašega sistema in, odkrito povedano, jih sploh ne zanima. Uporabnika zanima, kakšna je interakcija z vašim sistemom, kaj lahko s tem doseže, pa tudi, kako sistem izvaja uporabniške ukaze, kaj in kako počne z uporabniškimi podatki.
Kot pove naslov tega članka, sem nameraval govoriti o arhitekturi programske opreme in načrtovanju sistema. Zato nisem nameraval obravnavati vzorcev načrtovanja programske opreme, ki opisujejo, kako so ustvarjene komponente programske opreme. Vendar bolj ko razmišljam o tem, bolj se mi zdi, da je meja med vzorci načrtovanja programske opreme in arhitekturnimi vzorci zelo zabrisana in da sta pojma tesno povezana. Vzemimo za primer (izvor dogodka). Ko sprejmete ta arhitekturni vzorec, bo to vplivalo na skoraj vse vidike vašega sistema: dolgoročno shranjevanje podatkov, raven skladnosti, sprejeto v vašem sistemu, obliko komponent v njem itd., itd. Zato sem se odločil omeniti nekaj arhitekturnih vzorcev, ki se neposredno nanašajo na poslovno logiko. Čeprav se bo moral ta članek omejiti na preprost seznam, vas spodbujam, da se z njim seznanite in razmislite o idejah, povezanih s temi vzorci. Tukaj si:
- Koncepti , še posebej, ,
Sodelovalni pristopi
Zelo malo verjetno je, da se boste znašli na projektu kot udeleženec, ki je edini odgovoren za proces načrtovanja sistema. Nasprotno, najverjetneje boste morali sodelovati s kolegi, ki delajo znotraj in zunaj vaše naloge. V tem primeru boste morda morali s sodelavci oceniti izbrane tehnološke rešitve, prepoznati poslovne potrebe in razumeti, kako najbolje vzporediti naloge.
Posnetek od Unsplash
Prvi korak je razviti natančno in skupno razumevanje tega, kaj je poslovni cilj, ki ga poskušate doseči, in s katerimi gibljivimi deli se boste morali ukvarjati. Zlasti tehnike skupinskega modeliranja (event storming) pomagajo znatno pospešiti ta proces in povečati vaše možnosti za uspeh. To delo lahko opravite pred ali po načrtovanju , nato pa jo poglobite, ko izdelek zori. Na podlagi ravni doslednosti, ki bo tukaj dosežena, lahko tudi oblikujete za omejen kontekst, v katerem delate. Ko se boste morali pogovarjati o arhitekturi svojega sistema, se vam bo morda zdelo koristno , predlagano , zlasti ko morate razumeti, koliko se boste morali poglobiti v podrobnosti problema in si predstavljati stvari, ki jih želite sporočiti.
Verjetno obstaja še ena zrela tehnologija na to temo, ki ni nič manj uporabna kot Domain Driven Design. Vendar se nekako vrnemo k razumevanju predmetnega področja, torej znanja in izkušenj na tem področju bi vam moralo biti koristno.
Vir: www.habr.com