Pozdravljeni, kolegi.
Danes vam predstavljamo prevod članka Tugberka Ugurla, ki se je odločil v primerljivo kratkem obsegu predstaviti principe projektiranja sodobnih programske opreme. Tukaj je, kar avtor sporoča o sebi v kratkem:
Ker je nemogoče obravnavati tako obširno temo, kot so arhitekturni vzorci + vzorci projektiranja ob koncu leta 2019, priporočamo ne samo besedilo gospoda Ugurla, ampak tudi številne povezave, ki jih je prijazno dodal. Če vam bo všeč, bomo objavili še bolj specializirano besedilo o projektiranju razdeljenih sistemov.
Slika s spletne strani Unsplash
Če se nikoli niste srečali z izzivi, kot je projektiranje programske opreme od začetka, potem ob začetku takšnega dela včasih sploh ne veste, kje začeti. Menim, da je najprej potrebno opredeliti meje, da boste bolj ali manj prepričani, kaj točno nameravate projektirati, nato pa - zavihajte rokave in delajte, ne da bi presegli te meje. Kot izhodišče lahko vzamete kak izdelek ali storitev (idealen je tak, ki vam je zelo všeč) in se podrobneje seznanite z njegovo izvedbo. Morda vas bo presenetilo, kako preprosto se zdi ta izdelek, in kakšna ogromna kompleksnost je v resnici skrita v njem. Ne pozabite: , in to je povsem normalno.
Menim, da je najboljši nasvet, ki ga lahko dam tistim, ki pričenjajo z načrtovanjem sistema, naslednji: ne domnevajte! Od samega začetka je treba konkretizirati dejstva, znana o tem sistemu, in pričakovanja, povezana z njim. Tukaj je nekaj dobrih vprašanj, katerih odgovori vam bodo pomagali pri pristopu k projektiranju:
- Kakšen je problem, ki ga želimo rešiti?
- Koliko uporabnikov se bo hkrati povezalo z našim sistemom?
- Kateri vzorci zapisa in branja podatkov se bodo uporabljali?
- Kateri so pričakovani scenariji napak, kako se nameravamo spoprijeti z njimi?
- Kakšna so pričakovanja glede doslednosti in dostopnosti sistema?
- Je treba upoštevati kakšne zahteve, povezane z zunanjo preveritvijo in regulacijo?
- Kakšne vrste zaupnih podatkov nameravamo shraniti?
To je le nekaj vprašanj, ki so bila koristna tako meni kot tudi ekipam, v katerih sem sodeloval skozi leta svoje poklicne kariere. Če poznate odgovore na ta vprašanja (in na katerakoli druga, relevantna v kontekstu, v katerem delate), se lahko postopoma poglobite v tehnične podrobnosti naloge.
Določimo izhodiščno raven
Kaj tukaj razumem pod 'izhodiščno raven' (baseline)? V današnjih časih je mogoče večino težav v programski industriji rešiti z obstoječimi metodami in tehnologijami. Tako, ko se orientirate v tem okolju, dobite določeno prednost, ko se srečujete z nalogami, ki so jih nekateri že rešili pred vami. Ne pozabite, da se programi ustvarjajo za reševanje težav podjetij in uporabnikov, zato si prizadevamo rešiti nalogo na kar najpreprostejši (z vidika uporabnika) način. Zakaj je to pomembno? Morda se vam v vašem sistemu dopadno zdi iskati edinstvene rešitve za vse naloge, ker mislite: 'Kakšen programer bi bil, če bi povsod sledil vzorcem'? V resnici, umetnost leži v sprejemanju odločitev o tem, kje in kaj storiti. Seveda se vsak izmed nas občasno srečuje z edinstvenimi težavami, vsaka od njih je pravi izziv. Vendar pa, če je naš izhodiščni nivo jasno opredeljen, točno vemo, na kaj usmeriti svoja prizadevanja: na iskanje že pripravljenih rešitev zastavljene naloge ali na njeno nadaljnje raziskovanje in globlje razumevanje.
Mislim, da vam je uspelo prepričati, da bodo, če se strokovnjak dobro spozna na arhitekturne vidike nekaterih izjemnih programski sistemov, te vednosti neprecenljive pri obvladovanju umetnosti arhitekta in razvoju trdne osnove na tem področju.
No, od kod začeti? Pri je repozitorij na GitHubu z imenom , s katerim se lahko naučite oblikovanja obsežnih sistemov ter se pripravite na vprašanja pri razgovorih na to temo. V repozitoriju je razdelek z zgledi , kjer se, med drugim, obravnava, kako se nekatere dobro znane družbe , lotevajo oblikovanja svojih sistemov. Vendar pa, preden preidemo na ta material, poglejmo podrobneje nekatere od najpomembnejših arhitekturnih izzivov, s katerimi se srečujemo v praksi. To je pomembno, saj je potrebno natančno določiti ŠTEVILNE vidike te zahtevne in kompleksne težave ter jo nato rešiti v okviru regulacije, ki velja v tem sistemu.
Jackson Gabbard 50-minutni video o razgovorih, posvečenih oblikovanju sistemov kratko vsebino Pridobite znanje o shranjevanju in pridobivanju podatkov
Kot pravilo velja, da vaša odločitev o tem, kako boste dolgoročno shranjevali in posredovali svoje podatke, kritično vpliva na zmogljivost sistema. Zato morate v prvi vrsti razumeti pričakovane karakteristike zapisovanja in branja podatkov v vašem sistemu. Nato morate biti sposobni oceniti te kazalnike in izbrati na podlagi teh ocen. Vendar pa boste učinkovito opravili to nalogo le, če boste obvladali obstoječe vzorce shranjevanja podatkov. V osnovi to pomeni, da imate trdno znanje, povezano s
izbiro baze podatkov .
Baze podatkov lahko obravnavamo kot podatkovne strukture, ki se ponašajo z izjemno skalabilnostjo in trajnostjo. Zato vam mora poznavanje podatkovnih struktur dobro priti prav tudi pri izbiri te ali one baze podatkov. Na primer, – je strežnik podatkovnih struktur, ki podpira različne vrste vrednosti. Omogoča delo s takimi podatkovnimi strukturami, kot so seznami in množice, ter branje podatkov s pomočjo splošno znanih algoritmov, na primer, , organizira to delo na trajnosten in visoko dostopen način.
Slika s spletne strani Unsplash
Ko se dovolj dobro orientirate v različnih vzorcih shranjevanja podatkov, nadaljujte z učenjem o skladnosti in dostopnosti podatkov. Najprej se boste morali seznaniti z vsaj na splošni ravni, nato pa poglobiti svoje znanje, ko se boste podrobneje seznanili s priznanimi vzorci in . Tako boste razširili svoja obzorja na tem področju in razumeli, da sta branje in pisanje podatkov v resnici dve zelo različni težavi, pri obeh pa se pojavijo svoje posebne izzive. Opremljeni z nekaterimi vzorci zagotavljanja skladnosti in dostopnosti boste lahko znatno povečali učinkovitost sistema, hkrati pa zagotovili nemoteno oskrbo podatkov z vašimi aplikacijami.
Nazadnje, ko zaključujemo pogovor o vprašanjih shranjevanja podatkov, je treba omeniti tudi predpomnjenje. Ali bi moralo potekati hkrati na odjemalcu in na strežniku? Katere podatke boste imeli v predpomnilniku? In zakaj? Kako boste organizirali invalidacijo predpomnilnika? Bo ta potekala redno, v določenih časovnih intervalih? Če ja – kako pogosto? Te teme priporočam, da začnete obravnavati s omenjene knjižice o načrtovanju sistemov.
Komunikacijski vzorci
Sistemi sestavljajo različne komponente; to so lahko različni procesi, ki delujejo znotraj istega fizičnega vozlišča, ali različni stroji, ki delujejo na različnih delih vaše mreže. Nekateri od teh virov znotraj vaše mreže so lahko zasebni, drugi pa morajo biti javni in odprti za potrošnike, ki se nanje obračajo od zunaj.
Zagotavljati je treba komunikacijo teh virov med seboj, pa tudi izmenjavo informacij med celotnim sistemom in zunanjim svetom. V kontekstu načrtovanja sistemov se ponovno srečujemo s sklopom novih edinstvenih izzivov. Raziskujemo, kako so lahko , in kateri r.
Slika s spletne strani Unsplash
Pri organizaciji komunikacije z zunanjim svetom je vedno zelo pomembno , kar zahteva resen pristop in aktivno ukvarjanje z njo.
Porazdelitev povezav
Nisem prepričan, da bo nekaterim razumljivo izpostaviti to temo kot samostojen razdelek. Kljub temu pa bom tukaj podrobno predstavil to koncept, pri čemer menim, da material tega razdelka najlepše opisuje izraz „porazdelitev povezav“ (connection distribution).
Sistemi se oblikujejo s pravilnim povezovanjem številnih komponent, njihova komunikacija pa se pogosto organizira na podlagi ustaljenih protokolov, kot sta TCP in UDP. Vendar ti protokoli pogosto ne zadostujejo potrebam sodobnih sistemov, ki pogosto delujejo pod visokimi obremenitvami in so močno odvisni od potreb uporabnikov. Pogosto je treba iskati načine za porazdelitev povezav, da bi se spoprijeli s takšnimi visoko obremenjenimi sistemi.
Osnova take porazdelitve je dobro znani (DNS). Ta sistem omogoča pretvorbo domenskega imena, kot sta ponderirana krožna metoda (weighted round robin) in metode, temelječe na zamudah, ki pomagajo pri porazdelitvi bremena.
je bistvenega pomena, in skoraj vsak večji sistem na spletu, s katerim se danes srečujemo, je lociran za enim ali več porazdelitvenimi ohišji. Porazdelitvena ohišja pomagajo razporediti uporabniške zahteve med številne dostopne instance. Porazdelitvena ohišja so lahko tako strojna kot programska, a v praksi se pogosteje srečujemo s programskimi, na primer z in . konceptualno tudi zelo podobni porazdelitvenim ohišjem, vendar med njima obstaja vrsta . Te razlike je treba upoštevati pri načrtovanju sistema, prilagojenega vašim potrebam.
Prav tako je treba vedeti o (CDN). CDN – to je globalna distribuirana mreža proxy strežnikov, ki dostavlja informacije iz tistih vozlišč, ki so geografsko bližje določenemu uporabniku. Uporaba CDN je bolj zaželena, če delate s statičnimi datotekami, napisanimi v JavaScriptu, CSS-ju in HTML-ju. Poleg tega so danes razširjene tudi takšne oblačne storitve, ki ponujajo upravljalce prometa, na primer, , ki vam zagotavlja globalno distribucijo in zmanjšane zamude pri delu z dinamično vsebino. Vendar pa so te storitve običajno koristne v primerih, ko delate z brezstanjskimi spletnimi storitvami.
Pogovorimo se o poslovni logiki. Strukturiranje poslovne logike, tokov nalog in komponent
Torej, uspeli smo razpravljati o različnih infrastrukturnih vidikih sistema. Verjetno se uporabnik sploh ne sprašuje o vseh teh elementih vašega sistema in, iskreno, se zanje povsem nič ne obremenjuje. Uporabnika zanima, kakšna je interoperabilnost z vašim sistemom, kaj lahko doseže, če ravna tako, pa tudi na kakšen način sistem izvaja uporabniške ukaze in kaj počne z uporabniškimi podatki.
Kot je razvidno iz naslova tega članka, sem nameraval govoriti o programski arhitekturi in oblikovanju sistemov. Zato nisem nameraval obravnavati vzorcev oblikovanja programske opreme, ki opisujejo, kako nastajajo programske komponente. Vendar, čim več razmišljam o tem, bolj se mi zdi, da je meja med vzorci oblikovanja programske opreme in arhitekturnimi vzorci zelo zamegljena, in ti dve koncepti sta tesno povezani. Vzemimo na primer, (event sourcing). Ko enkrat obvladate ta arhitekturni vzorec, vpliva skoraj na vse vidike vašega sistema: dolgoročno shranjevanje podatkov, raven doslednosti, sprejeto v vašem sistemu, oblike komponent v njem, itd. Zato sem se odločil omeniti nekatere arhitekturne vzorce, ki se neposredno nanašajo na poslovno logiko. Čeprav se bom v tem članku moral omejiti na preprost seznam, vam priporočam, da se z njim seznanite in razmislite o idejah, povezanih s temi vzorci. Tukaj so:
- Koncepcije , posebno ,
Kollaborativni pristupi
Izuzetno je malo vjerovatno da ćete na projektu biti jedini koji snosi odgovornost za proces dizajniranja sustava. Naprotiv, vjerojatno ćete surađivati s ekipom koja radi unutar vašeg zadatka, kao i izvan njega. U tom će slučaju možda biti potrebno zajednički procijeniti odabrana tehnološka rješenja s kolegama, istaknuti poslovne potrebe i razumjeti kako najbolje paralelizirati zadatke.
Slika s spletne strani Unsplash
Prvo je potrebno razviti preciznu i opće prihvaćenu predstavu o poslovnom cilju koji pokušavate postići i o kojim se promjenjivim elementima radi. Tehnike grupnog modeliranja, posebno (event storming) značajno pomažu ubrzati ovaj proces i povećavaju vaše šanse za uspjeh. Ovim radom možete se baviti prije ili nakon što definirate , a zatim ga produbljivati kako proizvod sazrijeva. Oslanjajući se na razinu suglasnosti koja će ovdje biti postignuta, također možete formulirati za onaj ograničeni kontekst u kojem radite. Kada bude potrebno govoriti o arhitekturi vašeg sustava, može vam pomoći , koji je predložio , posebno kada je potrebno razumjeti koliko duboko ćete morati ući u detalje problema, vizualizirajući stvari koje želite prenijeti.
Vjerojatno u ovoj temi postoji i druga zrela tehnologija, koja nije manje korisna od projektiranja usmjerenog na predmet. Ipak, na neki način se vraćamo razumijevanju predmetne oblasti, pa će vam znanje i iskustvo u području biti korisni.
Izvor: habr.com
