Arhitektura softvera i dizajn sistema: Velika slika i vodič za resurse

Zdravo kolege.

Danas vam nudimo na razmatranje prijevod članka Tugberka Ugurlua, koji se obavezao da u relativno malom obimu iznese principe dizajniranja modernih softverskih sistema. Evo šta ukratko kaže autor o sebi:

Arhitektura softvera i dizajn sistema: Velika slika i vodič za resurse
Budući da je apsolutno nemoguće u habro članku pokriti tako kolosalnu temu kao što su arhitektonski obrasci + obrasci dizajna od 2019. godine, preporučujemo ne samo tekst g. Uruglua, već i brojne linkove koje je ljubazno uključio u njega. Ako vam se sviđa, objavićemo više specijalizovani tekst o dizajnu distribuiranih sistema.

Arhitektura softvera i dizajn sistema: Velika slika i vodič za resurse

Snimok Isaac Smith od Unsplash

Ako se nikada niste suočili sa izazovima kao što je dizajniranje softverskog sistema od nule, onda kada započnete takav posao, ponekad nije jasno odakle početi. Vjerujem da prvo trebate povući granice kako biste imali koliko-toliko sigurnu ideju o tome šta ćete točno dizajnirati, a zatim zasukati rukave i raditi u tim granicama. Kao polaznu tačku, možete uzeti proizvod ili uslugu (idealno onaj koji vam se zaista sviđa) i smisliti kako ga implementirati. Možda ćete biti zapanjeni koliko jednostavno ovaj proizvod izgleda i koliko složenosti zapravo sadrži. Nemoj zaboraviti: jednostavno - obično složeno, i to je u redu.

Mislim da je najbolji savjet koji mogu dati svakome ko počinje dizajnirati sistem: nemojte praviti nikakve pretpostavke! Od samog početka morate navesti poznate činjenice o ovom sistemu i očekivanja povezana s njim. Evo nekoliko dobrih pitanja koja vam mogu pomoći da započnete sa svojim dizajnom:

  • Koji je problem koji pokušavamo riješiti?
  • Koliki je najveći broj korisnika koji će komunicirati s našim sistemom?
  • Koje ćemo obrasce pisanja i čitanja podataka koristiti?
  • Koji su očekivani slučajevi neuspjeha, kako ćemo ih riješiti?
  • Koja su očekivanja u pogledu konzistentnosti i dostupnosti sistema?
  • Da li prilikom rada morate uzeti u obzir bilo kakve zahtjeve koji se odnose na eksternu verifikaciju i regulaciju?
  • Koje vrste osjetljivih podataka ćemo pohraniti?

Ovo su samo neka pitanja koja su bila korisna i meni i timovima u kojima sam učestvovao tokom godina profesionalnog djelovanja. Ako znate odgovore na ova pitanja (i sva druga koja su relevantna za kontekst u kojem morate raditi), onda možete postepeno ulaziti u tehničke detalje problema.

Postavite početni nivo

Šta ovdje mislim pod "osnovnom linijom"? Zapravo, u naše vrijeme većina problema u softverskoj industriji se „može“ riješiti korištenjem postojećih metoda i tehnologija. Shodno tome, navigacijom ovim krajolikom, dobijate određenu prednost kada se suočite sa problemima koje je neko drugi morao da reši pre vas. Ne zaboravite da su programi pisani za rješavanje poslovnih i korisničkih problema, pa nastojimo riješiti problem na što jednostavniji (iz ugla korisnika) način. Zašto je ovo važno zapamtiti? Možda u svom koordinatnom sistemu volite da tražite jedinstvena rešenja za sve probleme, jer mislite „kakav sam ja programer ako svuda pratim šablone“? Zapravo, umjetnost ovdje je donošenje odluka o tome gdje i šta raditi. Naravno, svako od nas se s vremena na vrijeme mora suočiti sa jedinstvenim problemima, od kojih je svaki pravi izazov. Međutim, ako je naš početni nivo jasno definiran, onda znamo na što potrošiti svoju energiju: traženje gotovih opcija za rješavanje problema koji je pred nama, ili njegovo dalje proučavanje i stjecanje dubljeg razumijevanja.

Mislim da sam uspeo da vas ubedim da ako stručnjak sa sigurnošću razume šta je arhitektonska komponenta nekih divnih softverskih sistema, onda će ovo znanje biti neophodno za ovladavanje umećem arhitekte i razvoj čvrste osnove u ovoj oblasti.

U redu, odakle početi? U Donna Martina Postoji spremište na GitHubu pod nazivom sistem-dizajn-prajmer, iz kojeg možete naučiti kako dizajnirati sisteme velikih razmjera, kao i pripremiti se za intervjue na ovu temu. Repozitorijum ima odeljak sa primerima stvarne arhitekture, gdje se posebno razmatra kako oni pristupaju dizajnu svojih sistema neke poznate kompanijenpr. Twitter, Uber, itd.

Međutim, prije nego što pređemo na ovaj materijal, pogledajmo pobliže najvažnije arhitektonske izazove s kojima se suočavamo u praksi. Ovo je važno jer morate specificirati MNOGE aspekte tvrdoglavog i višestrukog problema, a zatim ga riješiti u okviru propisa koji su na snazi ​​u datom sistemu. Jackson Gabbard, napisao je bivši zaposlenik Facebooka 50-minutni video o intervjuima za dizajn sistema, gdje je podijelio vlastito iskustvo skrininga stotina kandidata. Dok se video u velikoj mjeri fokusira na dizajn velikog sistema i kriterije uspjeha koji su važni kada se traži kandidat za takvu poziciju, on će i dalje služiti kao sveobuhvatan resurs o tome koje su stvari najvažnije pri dizajniranju sistema. Predlažem i ja sažetak ovaj video.

Izgradite znanje o pohranjivanju i preuzimanju podataka

Obično vaša odluka o tome kako pohranjujete i preuzimate svoje podatke na duži rok ima kritičan utjecaj na performanse sistema. Stoga, prvo morate razumjeti očekivane karakteristike pisanja i čitanja vašeg sistema. Zatim morate biti u mogućnosti da procijenite ove indikatore i napravite izbore na osnovu napravljenih procjena. Međutim, možete se efikasno nositi sa ovim poslom samo ako razumete postojeće obrasce skladištenja podataka. U principu, ovo podrazumijeva solidno znanje vezano za izbor baze podataka.

Baze podataka se mogu smatrati strukturama podataka koje su izuzetno skalabilne i izdržljive. Stoga bi vam poznavanje struktura podataka trebalo biti od velike koristi pri odabiru određene baze podataka. Na primjer, Redis je server strukture podataka koji podržava različite vrste vrijednosti. Omogućava vam da radite sa strukturama podataka kao što su liste i skupovi i čitate podatke koristeći dobro poznate algoritame, na primjer, LRU, organizirajući takav rad u trajnom i vrlo pristupačnom stilu.

Arhitektura softvera i dizajn sistema: Velika slika i vodič za resurse

Snimok Samuel Zeller od Unsplash

Nakon što ste dovoljno razumjeli različite obrasce pohrane podataka, prijeđite na proučavanje konzistentnosti i dostupnosti podataka. Prije svega, morate razumjeti CAP teorema barem općenito, a zatim usavršiti ovo znanje pažljivijim sagledavanjem utvrđenih obrazaca konzistentnost и pristupačnost. Na ovaj način ćete razviti razumijevanje polja i shvatiti da su čitanje i pisanje podataka zapravo dva vrlo različita problema, svaki sa svojim jedinstvenim izazovima. Naoružani sa nekoliko obrazaca konzistentnosti i dostupnosti, možete značajno povećati performanse sistema, istovremeno osiguravajući nesmetan protok podataka do vaših aplikacija.

Na kraju, zaključujući razgovor o problemima skladištenja podataka, treba spomenuti i keširanje. Da li treba da radi istovremeno na klijentu i serveru? Koji će podaci biti u vašoj keš memoriji? I zašto? Kako organizirate poništavanje keša? Hoće li se to raditi redovno, u određenim intervalima? Ako da, koliko često? Preporučujem da počnete sa proučavanjem ovih tema sljedeći odjeljak gore pomenuti temeljni premaz za dizajn sistema.

Komunikacijski obrasci

Sistemi se sastoje od različitih komponenti; to mogu biti različiti procesi koji se pokreću unutar istog fizičkog čvora ili različite mašine koje rade 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 za potrošače koji im pristupaju izvana.

Potrebno je osigurati međusobnu komunikaciju ovih resursa, kao i razmjenu informacija između cijelog sistema i vanjskog svijeta. U kontekstu projektovanja sistema, i ovde smo suočeni sa nizom novih i jedinstvenih izazova. Hajde da vidimo kako mogu biti korisni asinhroni tokovi zadataka, a šta strDostupni su različiti komunikacijski obrasci.

Arhitektura softvera i dizajn sistema: Velika slika i vodič za resurse

Snimok Tony Stoddard od Unsplash

Prilikom organizovanja komunikacije sa spoljnim svetom, to je uvek veoma važno sigurnostčiju odredbu također treba shvatiti ozbiljno i aktivno provoditi.

Distribucija priključaka

Nisam siguran da će stavljanje ove teme u poseban odjeljak svima izgledati opravdano. Ipak, ovaj koncept ću ovdje detaljno predstaviti i vjerujem da je materijal u ovom dijelu najpreciznije opisan terminom „distribucija veze“.

Sistemi se formiraju pravilnim povezivanjem mnogih komponenti, a njihova međusobna komunikacija se često organizuje na osnovu uspostavljenih protokola, na primjer, TCP i UDP. Međutim, ovi protokoli kao takvi često nisu dovoljni da zadovolje sve potrebe savremenih sistema, koji često rade pod velikim opterećenjem i takođe u velikoj meri ovise o potrebama korisnika. Često je potrebno pronaći načine za distribuciju veza kako bi se nosila sa tako velikim opterećenjima sistema.

Ova distribucija se zasniva na dobro poznatim sistem naziva domena (DNS). Takav sistem omogućava transformacije imena domena, kao što su ponderisani round robin i metode zasnovane na kašnjenju da pomognu u raspodeli opterećenja.

Balansiranje opterećenja je fundamentalno važno, i gotovo svaki veliki internet sistem s kojim se danas bavimo 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 u hardveru i u softveru, međutim, u praksi, češće morate imati posla sa softverskim, npr. HAProxy и ELB. Obrnuti proksiji konceptualno također vrlo sličan balansatorima opterećenja, iako postoji raspon između prvog i drugog izrazite razlike. Ove razlike se moraju uzeti u obzir prilikom dizajniranja sistema zasnovanog na vašim potrebama.

Trebalo bi da znate i o mreže za isporuku sadržaja (CDN). CDN je globalna distribuirana mreža proxy servera koja isporučuje informacije sa čvorova koji su geografski locirani bliže određenom korisniku. CDN-ove je poželjno koristiti ako radite sa statičkim datotekama napisanim u JavaScript-u, CSS-u i HTML-u. Osim toga, usluge u oblaku koje pružaju upravitelje saobraćaja danas su uobičajene, npr. Azure Traffic Manager, što vam daje globalnu distribuciju i smanjeno kašnjenje pri radu s dinamičkim sadržajem. Međutim, takve usluge su obično korisne u slučajevima kada morate raditi s web uslugama bez državljanstva.

Hajde da pričamo o poslovnoj logici. Strukturiranje poslovne logike, tokova zadataka i komponenti

Dakle, uspjeli smo da razgovaramo o različitim infrastrukturnim aspektima sistema. Najvjerovatnije, korisnik i ne razmišlja o svim ovim elementima vašeg sistema i, iskreno, uopće ne mari za njih. Korisnika zanima kakva je interakcija sa vašim sistemom, šta se time može postići, kao i kako sistem izvršava korisničke komande, šta i kako radi sa korisničkim podacima.

Kao što naslov ovog članka sugerira, htio sam govoriti o arhitekturi softvera i dizajnu sistema. Shodno tome, nisam planirao da pokrivam obrasce dizajna softvera koji opisuju kako se softverske komponente kreiraju. Međutim, što više razmišljam o tome, sve mi se više čini da je granica između šablona softverskog dizajna i arhitektonskih obrazaca veoma zamagljena, a dva koncepta su usko povezana. Uzmimo za primjer registracija događaja (izvor događaja). Jednom kada usvojite ovaj arhitektonski obrazac, on će uticati na skoro svaki aspekt vašeg sistema: dugoročno skladištenje podataka, nivo konzistentnosti usvojen u vašem sistemu, oblik komponenti u njemu, itd, itd. Stoga sam odlučio spomenuti neke arhitektonske obrasce koji se direktno odnose na poslovnu logiku. Iako će se ovaj članak morati ograničiti na jednostavnu listu, ohrabrujem vas da se upoznate s njim i razmislite o idejama povezanim s ovim obrascima. Tu si:

Kolaborativni pristupi

Izuzetno je malo vjerovatno da ćete se naći na projektu kao učesnik koji je isključivo odgovoran za proces dizajna sistema. Naprotiv, najvjerovatnije ćete morati komunicirati sa kolegama koji rade i unutar i izvan vašeg zadatka. U ovom slučaju, možda ćete trebati sa kolegama procijeniti odabrana tehnološka rješenja, identificirati poslovne potrebe i razumjeti kako najbolje paralelizirati zadatke.

Arhitektura softvera i dizajn sistema: Velika slika i vodič za resurse

Snimok Kaleidico od Unsplash

Prvi korak je da razvijete tačno i zajedničko razumevanje onoga što je poslovni cilj koji pokušavate da postignete i sa kojim pokretnim delovima ćete morati da se nosite. Tehnike grupnog modeliranja, posebno olujni događaji (oluja događaja) pomažu značajno ubrzati ovaj proces i povećati vaše šanse za uspjeh. Ovaj rad se može obaviti prije ili nakon izrade nacrta granice vaših usluga, a zatim produbljuje kako proizvod sazrijeva. Na osnovu nivoa konzistentnosti koji će se ovde postići, možete i formulisati zajednički jezik za ograničen kontekst u kojem radite. Kada trebate razgovarati o arhitekturi vašeg sistema, možda će vam biti od koristi model C4, predloženo Simon Brown, posebno kada treba da shvatite koliko ćete morati da ulazite u detalje problema, vizualizujući stvari koje želite da komunicirate.

Vjerovatno postoji još jedna zrela tehnologija na ovu temu koja nije ništa manje korisna od Domain Driven Design. Ipak, nekako se vraćamo razumijevanju predmetne oblasti, dakle znanju i iskustvu u toj oblasti Dizajn vođen domenom trebalo bi da vam bude od koristi.

izvor: www.habr.com

Dodajte komentar