Dobrý deň, kolegovia.
Dnes vám predkladáme preklad článku Tugberka Ugurlu, ktorý sa vo vzťahu k relatívne malému objemu snaží prerozprávať princípy návrhu moderných softvérových systémov. Tu sú informácie, ktoré autor o sebe zanechal:
Keďže je absolútne nemožné pokryť v hubri takú ohromnú tému, ako sú architektonické vzory + vzory návrhu k roku 2019, odporúčame nielen samotný text pána Ugurlu, ale aj množstvo odkazov, ktoré v ňom s láskou uviedol. Ak vás to zaujme, zverejníme aj podrobnejší text o navrhovaní distribuovaných systémov.
Obrázok zo stránky Unsplash
Ak ste sa nikdy nestretli s takýmito výzvami, ako je návrh softvérového systému od nuly, môže byť na začiatku takého projektu niekedy ťažké rozhodnúť sa, kde začať. Myslím, že najprv je potrebné vyznačiť hranice, aby ste mali aspoň trochu jasnú predstavu o tom, čo plánujete navrhnúť, a potom si založiť rukávy a pracovať, pričom neprekročíte tieto hranice. Ako vychádzajúci bod môžete zobrať akýkoľvek produkt alebo službu (ideálne takú, ktorú máte veľmi radi) a preskúmať jej realizáciu. Možno budete prekvapení, ako jednoducho sa tento produkt javí, a aká obrovská zložitosti sa v ňom v skutočnosti skrýva. Nezabúdajte: , a to je v poriadku.
Myslím, že najlepší tip, ktorý môžem dať tým, ktorí sa púšťajú do návrhu systému, je: žiadne predpoklady! Od samého začiatku je potrebné konkretizovať fakty známe o tomto systéme a očakávania s ním spojené. Tu je niekoľko dobrých otázok, na ktoré odpovede vám pomôžu začať s návrhom:
- Aký je problém, ktorý sa snažíme vyriešiť?
- Aký je maximálny počet používateľov, ktorí budú interagovať s naším systémom?
- Aké vzory zápisu a čítania dát budeme používať?
- Aké sú očakávané prípady zlyhania a ako s nimi plánujeme naložiť?
- Aké očakávania sa uplatňujú na konzistenciu a dostupnosť systému?
- Je potrebné pri práci zohľadniť nejaké požiadavky týkajúce sa vonkajšieho overovania a regulácie?
- Aké druhy dôverných údajov máme v úmysle uchovávať?
Toto je len niekoľko otázok, ktoré sa ukázali byť užitočné v mojej práci i v tímoch, ktorých som sa zúčastnil počas svojej profesionálnej kariéry. Ak poznáte odpovede na tieto otázky (a na akékoľvek ďalšie, relevantné v kontexte, v ktorom pracujete), môžete sa postupne prehĺbiť do technických detailov úlohy.
Stanovujeme počiatočnú úroveň
Čo tu rozumiem pod „počiatočnou úrovňou“? V súčasnosti sa väčšina problémov v softvérovom priemysle „môže“ vyriešiť pomocou už existujúcich metód a technológií. Tým, že sa orientujete v tomto prostredí, získavate určité výhody, čelí výzvam, ktoré už pred vami niekto vyriešil. Nezabúdajme, že programy sa píšu na riešenie problémov podnikania a používateľov, a preto sa snažíme vyriešiť úlohu čo najpriamo a najjednoduchším spôsobom (z pohľadu používateľa). Prečo je dôležité si to pamätať? Možno vo vašom systéme preferujete hľadanie jedinečných riešení pre všetky úlohy, pretože si myslíte, „aký som programátor, ak všade dodržiavam vzory“? V skutočnosti umenie spočíva v rozhodovaní o tom, kde a čo robiť. Samozrejme, každý z nás sa občas stretáva s jedinečnými problémami, z ktorých každý je skutočnou výzvou. Avšak, ak je naša počiatočná úroveň jasne definovaná, vieme, na čo sústrediť svoje úsilie: na hľadanie existujúcich riešení stanovených úloh, alebo na jej ďalšie skúmanie a hlbšie pochopenie.
Myslím, že som vás presvedčil, že ak sa odborník dôveryhodne orientuje v architektonických aspektoch niektorých skvelých softvérových systémov, tieto vedomosti budú neoceniteľné pre ovládanie umenia architekta a budovanie solídneho základu v tejto oblasti.
Dobre, odkiaľ začať? má repozitár na GitHub s názvom , z ktorého sa môžete naučiť navrhovať rozsiahle systémy a tiež sa pripraviť na pohovory na túto tému. V repozitári nájdete sekciu s príkladmi , kde sa konkrétne skúma, ako pristupujú k dizajnu svojich systémov , napríklad Twitter, Uber atď.
Avšak predtým, ako prejdeme k tomuto materiálu, poďme podrobnejšie preskúmať najdôležitejšie architektonické výzvy, ktorým sa v praxi čelí. Je to dôležité, pretože je potrebné konkretizovať MNOŽSTVO aspektov nepoddajného a mnohorozmerného problému a následne ho riešiť v rámci regulácie, ktorá platí v tomto systéme. , bývalý zamestnanec Facebooku, natočil , kde sa podelil o svoje vlastné skúsenosti z posúdenia stoviek uchádzačov. Aj keď sa video výslovne zaoberá návrhom veľkých systémov a kritériami úspešnosti, ktoré sú dôležité pri hľadaní kandidáta na takúto pozíciu, stále bude slúžiť ako komplexný zdroj informácií o tom, čo je najdôležitejšie pri návrhu systémov. Taktiež navrhujem tohto videa.
Získavajte vedomosti o ukladaní a vyhľadávaní dát
Vo všeobecnosti vaše rozhodnutie o tom, ako dlhodobo uchováte a vydáte svoje dáta, výrazne ovplyvňuje výkon systému. Preto by ste mali najprv rozumieť očakávaným charakteristikám zápisu a čítania dát vo vašom systéme. Potom musíte vedieť hodnotiť tieto ukazovatele a robiť rozhodnutia na základe vykonaných hodnotení. Avšak efektívne zvládnuť túto prácu budete schopní len v prípade, ak rozumiete existujúcim vzorcom ukladania dát. V zásade to znamená mať isté vedomosti spojené s .
Databázy možno považovať za dátové štruktúry, ktoré majú výnimočnú škálovateľnosť a trvanlivosť. Preto vám znalosti o dátových štruktúrach budú veľmi užitočné aj pri výbere konkrétnej databázy. Napríklad, – je server dátových štruktúr, ktorý podporuje rôzne typy hodnôt. Umožňuje pracovať s takými dátovými štruktúrami ako sú zoznamy a množiny, čítať dáta pomocou známych algoritmov, napríklad, , organizujúc túto prácu v trvalom a vysoko dostupnom štýle.
Obrázok zo stránky Unsplash
Keď sa dostatočne oboznámite s rôznymi vzormi ukladania dát, môžete prejsť na štúdium konzistencie a dostupnosti dát. Spočiatku si budete musieť osvojiť , aspoň v obrysoch, a potom si tieto vedomosti upresniť podrobnejším preskúmaním ustálených vzorov a . Týmto spôsobom si rozšírite obzory v tejto oblasti a pochopíte, že čítanie a zápis dát sú v skutočnosti dve veľmi odlišné problémy, pričom každé z nich so sebou nesie svoje vlastné výzvy. S niekoľkými vzormi zabezpečenia konzistencie a dostupnosti môžete výrazne zvýšiť výkonnosť systému, pričom zaručíte plynulú dodávku dát do vašich aplikácií.
Nakoniec, v súvislosti s otázkami ukladania dát je potrebné spomenúť aj o kešovaní. Má sa vykonávať súčasne na kliente a na serveri? Aké dáta budete mať vo svojej keši? A prečo? Ako usporiadate invalidáciu kešov? Bude sa to robiť pravidelne, v určitých intervaloch? Ak áno - ako často? Odporúčam začať s touto problematikou z vyššie uvedenej príručky o projektovaní systémov.
Komunikačné vzory
Systémy sa skladajú z rôznych komponentov; to môžu byť rôzne procesy, ktoré fungujú v rámci rovnakého fyzického uzla, alebo rôzne stroje, ktoré pôsobia v rôznych častiach vašej siete. Niektoré z týchto zdrojov v rámci vašej siete môžu byť súkromné, ale iné musia byť verejné a otvorené pre spotrebiteľov, ktorí k nim pristupujú zvonku.
Je potrebné zabezpečiť komunikáciu týchto zdrojov navzájom, ako aj výmenu informácií medzi celým systémom a vonkajším svetom. V kontexte projektovania systémov sa opäť stretávame s novým súborom jedinečných výziev. Zisťujeme, čo môže byť užitočné pre , a aké rôznorodé.
Obrázok zo stránky Unsplash
Pri organizovaní komunikácie s vonkajším svetom je vždy veľmi dôležité , na čo je potrebné pristupovať s plnou vážnosťou a aktívne sa tým zabeerať.
Distribúcia pripojení
Nie som si istý, že vyčlenenie tejto témy do samostatnej sekcie sa každému bude zdať odôvodnené. Napriek tomu podrobne vysvetlím túto koncepciu a domnievam sa, že materiál tejto sekcie najpresnejšie vystihuje pojem „distribúcia pripojení“ (connection distribution).
Systémy sa formujú správnym spojením množstva komponentov a ich komunikácia medzi sebou sa často organizuje na základe ustálených protokolov, napríklad TCP a UDP. Avšak tieto protokoly sami o sebe často nestačia na uspokojenie všetkých potrieb súčasných systémov, ktoré sú často prevádzkované pri vysokých zaťaženiach a silno závisia od potrieb používateľov. Často je potrebné hľadať spôsoby distribúcie pripojení, aby sa zvládali takéto vysoké zaťaženia v systéme.
Na základe takejto distribúcie leží dobre známa (DNS). Tento systém umožňuje prevádzať doménové meno, napríklad vážený cyklický algoritmus (weighted round robin) a metódy založené na oneskoreniach, ktoré pomáhajú distribuovať záťaž.
je principiálne dôležité a takmer každý veľký systém na Internete, s ktorým dnes musíme mať do činenia, sa nachádza za jedným alebo viacerými vyvažovačmi záťaže. Vyvažovače záťaže pomáhajú distribuovať klientské požiadavky medzi množstvo dostupných inštancií. Vyvažovače záťaže môžu byť hardvérové aj softvérové, avšak v praxi sa častejšie stretávame so softvérovými, napríklad s a . konceptuálne tiež veľmi pripomínajú vyvažovače záťaže, hoci medzi prvými a druhými existuje niekoľko . Tieto rozdiely je potrebné zohľadniť pri navrhovaní systému s ohľadom na vaše potreby.
Taktiež by ste mali vedieť o (CDN). CDN – to je globálna distribuovaná sieť proxy serverov, ktorá dodáva informácie z tých uzlov, ktoré sú geograficky umiestnené bližšie k konkrétnemu používateľovi. CDN siete je preferované používať, ak pracujete so statickými súbormi napísanými v JavaScript, CSS a HTML. Okrem toho sú dnes rozšírené také cloudové služby, kde sú poskytovatelia traffic managers, napríklad, , ktoré vám zabezpečujú globálne rozloženie a znížené oneskorenia pri práci s dynamickým obsahom. Tieto služby sú obvykle užitočné v prípadoch, keď musíte pracovať s webovými službami bez uchovávania stavu.
Poďme hovoriť o biznis logike. Štruktúrovanie biznis logiky, pracovných tokov a komponentov.
Takže sme stihli prediskutovať rôzne infraštruktúrne aspekty systému. Pravdepodobne si používateľ ani neuvedomuje všetky tieto prvky vášho systému a úprimne, vôbec sa tým nezaoberá. Používateľa zaujíma, aké je to interagovať s vaším systémom, čo sa dá dosiahnuť postupom akýmkoľvek spôsobom, a ako systém vykonáva používateľské príkazy, čo a ako robí s používateľskými dátami.
Ako je jasné z názvu tohto článku, chcel som sa v ňom venovať softvérovej architektúre a navrhovaniu systémov. Preto som neplánoval pokrývať návrhové vzory softvéru, ktoré opisujú, ako sa vytvárajú softvérové komponenty. Avšak, čím viac o tom premýšľam, tým viac sa mi zdá, že hranica medzi návrhovými vzormi softvéru a architektonickými vzormi je veľmi rozmazaná, a tieto dve koncepcie sú úzko prepojené. Vezmime si napríklad, (event sourcing). Ak si osvojíte tento architektonický vzor – ovplyvní prakticky všetky aspekty vášho systému: dlhodobé uchovávanie dát, úroveň konzistencie, ktorá je prijatá vo vašom systéme, obrysy komponentov v ňom atď. Preto som sa rozhodol spomenúť niektoré architektonické vzory, ktoré sa priamo týkajú biznis logiky. Nech sa už v tomto článku budem obmedzovať na jednoduchý zoznam, odporúčam vám oboznámiť sa s ním a zamyslieť sa nad myšlienkami súvisiacimi s týmito vzormi. Tu sú, prosím:
- Koncepcie , konkrétne, ,
Kolaboratívne prístupy
Je veľmi nepravdepodobné, že sa na projekte ocitnete ako ten účastník, ktorý sám zodpovedá za proces návrhu systému. Naopak, pravdepodobne budete musieť spolupracovať s kolegami, ktorí pracujú ako v rámci vašich úloh, tak aj mimo nich. V takom prípade môže byť potrebné posúdiť zvolené technologické riešenia spoločne s kolegami, identifikovať obchodné potreby a pochopiť, ako najlepšie paralelizovať úlohy.
Obrázok zo stránky Unsplash
V prvom rade je potrebné vypracovať presné a všeobecne uznávané pochopenie toho, aký obchodný cieľ sa snažíte dosiahnuť, a s akými pohyblivými prvkami budete musieť pracovať. Techniky skupinového modelovania, predovšetkým, (event storming) pomáhajú značne urýchliť tento proces a zvyšujú vaše šance na úspech. Túto prácu môžete vykonať predtým alebo po tom, ako vymedzíte , a potom ich prehlbovať, ako produkt zreje. Odkazujúc na úroveň súhlasu, ktorú dosiahnete, môžete tiež formulovať pre ten obmedzený kontext, v ktorom pracujete. Keď príde čas hovoriť o architektúre vášho systému, môže vám pomôcť , ktorý navrhol , najmä keď je potrebné pochopiť, do akej miery sa budete musieť hlbšie zaoberať podrobnosťami problému, vizualizujúc veci, ktoré chcete komunikovať.
Pravdepodobne v tejto oblasti existuje aj iná zrelá technológia, ktorá je rovnako užitočná ako doménovo orientované navrhovanie. Avšak, aj tak sa vraciame k pochopeniu domény, takže znalosti a skúsenosti v oblasti by vám mali byť nápomocné.
Zdroj: habr.com
