Pozdrav kolege.
Danas vam na razmatranje nudimo prijevod članka Tugberka Ugurlua, koji se obvezao da će u relativno malom volumenu ocrtati principe dizajniranja modernih softverskih sustava. Evo što autor ukratko kaže o sebi:
Budući da je od 2019. apsolutno nemoguće u jednom habro članku obraditi tako kolosalnu temu kao što su arhitektonski uzorci + uzorci dizajna, preporučamo ne samo sam tekst gospodina Uruglua, već i brojne poveznice koje je ljubazno uključio u njega. Ako vam se svidi, objavit ćemo uže specijalizirani tekst o dizajnu distribuiranih sustava.
Snimak iz Unsplasha
Ako se nikada niste morali suočiti s takvim izazovima kao što je projektiranje softverskog sustava od nule, onda kada započnete takav posao, ponekad čak nije jasno odakle početi. Smatram da prvo treba povući granice kako biste imali koliko-toliko sigurnu ideju što ćete točno dizajnirati, a onda zasukati rukave i raditi unutar tih granica. Kao početnu točku možete uzeti proizvod ili uslugu (idealno onu koja vam se stvarno sviđa) i smisliti kako to implementirati. Možda ćete se iznenaditi koliko jednostavno ovaj proizvod izgleda i koliko složenosti zapravo sadrži. Ne zaboravi: , i to je u redu.
Mislim da je najbolji savjet koji mogu dati svakome tko počne dizajnirati sustav sljedeći: nemojte stvarati nikakve pretpostavke! Od samog početka morate navesti poznate činjenice o ovom sustavu i očekivanja povezana s njim. Evo nekoliko dobrih pitanja koja možete postaviti kako biste lakše počeli s dizajnom:
- Koji je problem koji pokušavamo riješiti?
- Koji je najveći broj korisnika koji će komunicirati s našim sustavom?
- Koje ćemo obrasce pisanja i čitanja podataka koristiti?
- Koji su očekivani slučajevi neuspjeha, kako ćemo se nositi s njima?
- Koja su očekivanja za dosljednost i dostupnost sustava?
- Morate li prilikom rada uzeti u obzir zahtjeve vezane uz vanjsku provjeru i propise?
- Koje vrste osjetljivih podataka ćemo pohraniti?
Ovo su samo neka od pitanja koja su bila od koristi i meni i timovima u kojima sam sudjelovao tijekom godina profesionalnog djelovanja. Ako znate odgovore na ova pitanja (i sva druga koja su relevantna za kontekst u kojem morate raditi), tada možete postupno ulaziti u tehničke detalje problema.
Postavite početnu razinu
Što ovdje mislim pod "osnovnom linijom"? Zapravo, u naše se vrijeme većina problema u softverskoj industriji "može" riješiti korištenjem postojećih metoda i tehnologija. U skladu s tim, navigacijom ovim krajolikom dobivate određenu prednost kada se suočite s problemima koje je netko drugi morao riješiti prije vas. Ne zaboravite da su programi napisani za rješavanje poslovnih i korisničkih problema, stoga nastojimo problem riješiti na najdirektniji i najjednostavniji (s korisnikove točke gledišta) način. Zašto je ovo važno zapamtiti? Možda u svom koordinatnom sustavu volite tražiti jedinstvena rješenja za sve probleme, jer mislite “kakav sam ja to programer ako posvuda slijedim šablone”? Zapravo, umjetnost je ovdje donošenje odluka o tome gdje i što učiniti. Naravno, svatko se od nas s vremena na vrijeme mora suočiti s jedinstvenim problemima od kojih je svaki pravi izazov. No, ako je naša početna razina jasno definirana, tada znamo na što trošiti svoju energiju: na traženje gotovih opcija za rješavanje problema koji se postavlja pred nas ili na njegovo daljnje proučavanje i dublje razumijevanje.
Mislim da sam vas uspio uvjeriti da će, ako stručnjak pouzdano razumije što je arhitektonska komponenta nekih prekrasnih softverskih sustava, to znanje biti neophodno za svladavanje umjetnosti arhitekta i razvoj čvrste osnove u ovom području.
U redu, odakle početi? U Na GitHubu postoji repozitorij pod nazivom , iz kojeg možete naučiti kako dizajnirati velike sustave, kao i pripremiti se za intervjue na ovu temu. Repozitorij ima dio s primjerima , gdje se posebno razmatra kako pristupaju projektiranju svojih sustava npr. Twitter, Uber itd.
Međutim, prije nego prijeđemo na ovaj materijal, pogledajmo pobliže najvažnije arhitektonske izazove s kojima se susrećemo u praksi. Ovo je važno jer morate specificirati MNOGE aspekte tvrdokornog i višestranog problema, a zatim ga riješiti u okviru propisa koji su na snazi u danom sustavu. , bivši zaposlenik Facebooka, napisao je , gdje je podijelio vlastito iskustvo provjere stotina kandidata. Iako se video usredotočuje na dizajn velikih sustava i kriterije uspjeha koji su važni pri traženju kandidata za takvu poziciju, on će ipak poslužiti kao sveobuhvatan izvor o tome što je najvažnije pri projektiranju sustava. Također predlažem ovaj video.
Steknite znanje o pohranjivanju i dohvaćanju podataka
Tipično, vaša odluka o tome kako dugoročno pohranjujete i dohvaćate svoje podatke ima kritičan utjecaj na performanse sustava. Stoga prvo morate razumjeti očekivane karakteristike pisanja i čitanja vašeg sustava. Zatim morate biti u mogućnosti procijeniti te pokazatelje i napraviti izbor na temelju napravljenih procjena. Međutim, možete se učinkovito nositi s ovim poslom samo ako razumijete postojeće obrasce pohrane podataka. U načelu, to podrazumijeva dobro znanje vezano uz .
Baze podataka mogu se smatrati strukturama podataka koje su izuzetno skalabilne i trajne. Stoga bi vam poznavanje struktura podataka trebalo biti od velike koristi pri odabiru određene baze podataka. Na primjer, je poslužitelj strukture podataka koji podržava različite vrste vrijednosti. Omogućuje vam rad s podatkovnim strukturama kao što su popisi i skupovi te čitanje podataka korištenjem dobro poznatih algoritama, na primjer, , organizirajući takav rad na izdržljiv i vrlo pristupačan način.
Snimak iz Unsplasha
Nakon što ste dovoljno razumjeli različite obrasce pohrane podataka, prijeđite na proučavanje dosljednosti i dostupnosti podataka. Prije svega, morate razumjeti barem u općim crtama, a zatim uglačati to znanje pomnijim proučavanjem utvrđenih obrazaca и . Na taj ćete način razviti razumijevanje polja i razumjeti da su čitanje i pisanje podataka zapravo dva vrlo različita problema, svaki sa svojim jedinstvenim izazovima. Naoružani s nekoliko obrazaca dosljednosti i dostupnosti, možete značajno povećati performanse sustava dok osiguravate glatki protok podataka svojim aplikacijama.
Na kraju, završavajući razgovor o problemima pohranjivanja podataka, spomenimo i predmemoriju. Treba li se izvoditi istovremeno na klijentu i poslužitelju? Koji će podaci biti u vašoj predmemorij? I zašto? Kako organizirati poništenje predmemorije? Hoće li se to raditi redovito, u određenim intervalima? Ako da, koliko često? Preporučujem da počnete proučavati ove teme s gore spomenuti primer dizajna sustava.
Komunikacijski obrasci
Sustavi se sastoje od različitih komponenti; to mogu biti različiti procesi koji se izvode unutar istog fizičkog čvora ili različiti strojevi koji se izvode na različitim dijelovima vaše mreže. Neki od ovih resursa unutar vaše mreže mogu biti privatni, ali drugi bi trebali biti javni i otvoreni korisnicima koji im pristupaju izvana.
Potrebno je osigurati međusobnu komunikaciju ovih resursa, kao i razmjenu informacija između cijelog sustava i vanjskog svijeta. U kontekstu projektiranja sustava, ovdje se ponovno suočavamo s nizom novih i jedinstvenih izazova. Pogledajmo kako mogu biti korisni , a što str.
Snimak iz Unsplasha
Kada organizirate komunikaciju s vanjskim svijetom, to je uvijek vrlo važno , čijem osiguravanju također treba pristupiti ozbiljno i aktivno se baviti.
Distribucija veze
Nisam siguran da će stavljanje ove teme u poseban odjeljak svima biti opravdano. Ipak, ovdje ću detaljno predstaviti ovaj koncept, a vjerujem da je materijal u ovom odjeljku najtočnije opisan terminom “distribucija veze”.
Sustavi nastaju pravilnim povezivanjem mnogih komponenti, a njihova međusobna komunikacija često je organizirana na temelju utvrđenih protokola, primjerice TCP i UDP. Međutim, ovi protokoli sami po sebi često nisu dovoljni da zadovolje sve potrebe modernih sustava, koji često rade pod velikim opterećenjem i također su jako ovisni o potrebama korisnika. Često je potrebno pronaći načine za distribuciju veza kako bi se nosilo s tako velikim opterećenjima sustava.
Ova raspodjela temelji se na dobro poznatoj (DNS). Takav sustav omogućuje transformacije imena domena kao što su ponderirani kružni postupak i metode temeljene na latenciji za pomoć pri raspodjeli opterećenja.
je fundamentalno važan i gotovo svaki veliki internetski sustav s kojim danas imamo posla nalazi se iza jednog ili više balansera opterećenja. Balanseri opterećenja pomažu u distribuciji zahtjeva klijenata na više dostupnih instanci. Balanseri opterećenja dolaze i hardverski i softverski, no u praksi se češće morate baviti softverskim, npr. и . konceptualno također vrlo sličan load balancer-ima, iako postoji raspon između prvog i drugog . Ove se razlike moraju uzeti u obzir pri projektiranju sustava prema vašim potrebama.
Također biste trebali znati o (CDN). CDN je globalna distribuirana mreža proxy poslužitelja koja isporučuje informacije iz čvorova koji su zemljopisno smješteni bliže određenom korisniku. CDN-ove je poželjno koristiti ako radite sa statičkim datotekama napisanim u JavaScriptu, CSS-u i HTML-u. Osim toga, usluge u oblaku koje pružaju upravitelje prometa danas su uobičajene, na primjer, , dajući vam globalnu distribuciju i smanjenu latenciju pri radu s dinamičkim sadržajem. Međutim, takve su usluge obično korisne u slučajevima kada morate raditi s web uslugama bez stanja.
Razgovarajmo o poslovnoj logici. Strukturiranje poslovne logike, tijekova zadataka i komponenti
Dakle, uspjeli smo razgovarati o različitim infrastrukturnim aspektima sustava. Najvjerojatnije, korisnik uopće ne razmišlja o svim tim elementima vašeg sustava i, iskreno, uopće ga nije briga za njih. Korisnika zanima kakva je interakcija s vašim sustavom, što se time može postići, te kako sustav izvršava korisničke naredbe, što i kako radi s korisničkim podacima.
Kao što naslov ovog članka sugerira, namjeravao sam govoriti o arhitekturi softvera i dizajnu sustava. U skladu s tim, nisam planirao pokriti obrasce dizajna softvera koji opisuju kako se softverske komponente stvaraju. Međutim, što više razmišljam o tome, to mi se više čini da je granica između obrazaca dizajna softvera i arhitektonskih obrazaca vrlo nejasna, a ta su dva pojma usko povezana. Uzmimo za primjer (izvor događaja). Jednom kada usvojite ovaj arhitektonski obrazac, on će utjecati na gotovo svaki aspekt vašeg sustava: dugoročnu pohranu podataka, razinu dosljednosti usvojenu u vašem sustavu, oblik komponenti u njemu, itd., itd. Stoga sam odlučio spomenuti neke arhitektonske obrasce koji se izravno odnose na poslovnu logiku. Iako će se ovaj članak morati ograničiti na jednostavan popis, potičem vas da se s njim upoznate i razmislite o idejama povezanim s tim uzorcima. Izvoli:
- koncept , posebno, ,
Suradnički pristupi
Vrlo je mala vjerojatnost da ćete se naći na projektu kao sudionik koji je jedini odgovoran za proces projektiranja sustava. Naprotiv, najvjerojatnije ćete morati komunicirati s kolegama koji rade unutar i izvan vašeg zadatka. U ovom slučaju, možda ćete morati procijeniti odabrana tehnološka rješenja s kolegama, identificirati poslovne potrebe i razumjeti kako najbolje paralelizirati zadatke.
Snimak iz Unsplasha
Prvi korak je razviti točno i zajedničko razumijevanje poslovnog cilja koji pokušavate postići i s kojim pokretnim dijelovima ćete morati raditi. Osobito tehnike grupnog modeliranja (event storming) pomažu značajno ubrzati ovaj proces i povećati vaše šanse za uspjeh. Ovaj se posao može obaviti prije ili nakon izrade nacrta , a zatim ga produbiti kako proizvod sazrijeva. Na temelju razine dosljednosti koja će se ovdje postići, možete i formulirati za ograničeni kontekst u kojem radite. Kada trebate razgovarati o arhitekturi vašeg sustava, moglo bi vam biti korisno , zaprosio , posebno kada trebate razumjeti koliko ćete morati ulaziti u detalje problema, vizualizirajući stvari koje želite komunicirati.
Vjerojatno postoji još jedna zrela tehnologija na ovu temu koja nije ništa manje korisna od Domain Driven Design-a. No, nekako se vraćamo razumijevanju predmetnog područja, dakle znanju i iskustvu na terenu trebalo bi vam biti korisno.
Izvor: www.habr.com