Ahojte kolegovia.
Dnes vám ponúkame na posúdenie preklad článku Tugberka Ugurlu, ktorý sa zaviazal v relatívne malom objeme načrtnúť princípy navrhovania moderných softvérových systémov. Tu je to, čo o sebe autor v súhrne hovorí:
Keďže je absolútne nemožné obsiahnuť v habro článku takú kolosálnu tému ako architektonické vzory + dizajnové vzory od roku 2019, odporúčame nielen samotný text pána Uruglu, ale aj početné odkazy, ktoré doň láskavo vložil. Ak sa vám bude páčiť, zverejníme užšie špecializovaný text o dizajne distribuovaných systémov.
momentka od Unsplash
Ak ste nikdy nemuseli čeliť takým výzvam, ako je návrh softvérového systému od nuly, potom pri začatí takejto práce niekedy ani nie je jasné, kde začať. Verím, že si najprv musíte načrtnúť hranice, aby ste mali viac či menej sebavedomú predstavu o tom, čo presne budete navrhovať, a potom si vyhrnúť rukávy a pracovať v rámci týchto hraníc. Ako východiskový bod si môžete vziať produkt alebo službu (ideálne takú, ktorá sa vám naozaj páči) a prísť na to, ako ju implementovať. Možno vás prekvapí, ako jednoducho tento produkt vyzerá a koľko zložitosti v skutočnosti obsahuje. Nezabudni: , a to je v poriadku.
Myslím, že najlepšia rada, ktorú môžem dať každému, kto začína navrhovať systém, je táto: nevytvárajte si žiadne predpoklady! Od samého začiatku je potrebné špecifikovať fakty známe o tomto systéme a očakávania s ním spojené. Tu je niekoľko dobrých otázok, ktoré 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 údajov budeme používať?
- Aké sú očakávané prípady zlyhania, ako ich budeme riešiť?
- Aké sú očakávania týkajúce sa konzistencie a dostupnosti systému?
- Musíte pri práci brať do úvahy nejaké požiadavky súvisiace s externým overovaním a reguláciou?
- Aké typy citlivých údajov budeme uchovávať?
To je len niekoľko otázok, ktoré boli za roky profesionálnej činnosti užitočné pre mňa aj pre tímy, v ktorých som pôsobil. Ak poznáte odpovede na tieto otázky (a všetky ďalšie, ktoré sú relevantné pre kontext, v ktorom musíte pracovať), môžete sa postupne ponoriť do technických detailov problému.
Nastavte počiatočnú úroveň
Čo tu myslím pod „základnou líniou“? V súčasnosti sa väčšina problémov v softvérovom priemysle „dá“ vyriešiť pomocou existujúcich metód a technológií. Navigáciou v tejto krajine teda získate určitý náskok, keď budete čeliť problémom, ktoré pred vami musel vyriešiť niekto iný. Nezabudnite, že programy sú napísané na riešenie obchodných a používateľských problémov, preto sa snažíme problém vyriešiť čo najpriamejším a najjednoduchším (z pohľadu používateľa) spôsobom. Prečo je dôležité si to pamätať? Možno vo svojom súradnicovom systéme radi hľadáte jedinečné riešenia pre všetky problémy, pretože si myslíte: „Čo som to za programátora, keď všade sledujem vzory“? V skutočnosti, umenie je robiť rozhodnutia o tom, kde a čo robiť. Samozrejme, každý z nás sa musí z času na čas potýkať s jedinečnými problémami, z ktorých každý je skutočnou výzvou. Ak je však naša počiatočná úroveň jasne definovaná, potom vieme, na čo vynaložiť energiu: hľadanie hotových možností riešenia problému, ktorý je pred nami, alebo jeho ďalšie štúdium a hlbšie pochopenie.
Myslím, že som vás dokázal presvedčiť, že ak odborník s istotou chápe, čo je architektonickou súčasťou niektorých úžasných softvérových systémov, potom budú tieto znalosti nevyhnutné na zvládnutie umenia architekta a vytvorenie pevného základu v tejto oblasti.
Dobre, tak kde začať? U Na GitHub existuje úložisko s názvom , z ktorej sa môžete naučiť navrhovať rozsiahle systémy, ako aj pripraviť sa na rozhovory na túto tému. Úložisko má časť s príkladmi , kde sa zvažuje najmä to, ako pristupujú k návrhu svojich systémov napr Twitter, Uber a pod.
Kým však prejdeme k tomuto materiálu, pozrime sa bližšie na najdôležitejšie architektonické výzvy, ktorým v praxi čelíme. Je to dôležité, pretože musíte špecifikovať MNOHÉ aspekty tvrdohlavého a mnohostranného problému a potom ho vyriešiť v rámci predpisov platných v danom systéme. napísal bývalý zamestnanec Facebooku , kde sa podelil o vlastné skúsenosti s preverovaním stoviek uchádzačov. Aj keď sa video výrazne zameriava na návrh veľkého systému a kritériá ú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 sú najdôležitejšie pri navrhovaní systémov. tiež navrhujem toto video.
Vybudujte si znalosti o ukladaní a získavaní údajov
Vaše rozhodnutie o tom, ako dlhodobo ukladáte a získavate údaje, má zvyčajne zásadný vplyv na výkon systému. Preto musíte najprv pochopiť očakávané charakteristiky zápisu a čítania vášho systému. Potom musíte byť schopní vyhodnotiť tieto ukazovatele a rozhodnúť sa na základe vykonaných hodnotení. S touto prácou sa však môžete efektívne vyrovnať iba vtedy, ak rozumiete existujúcim vzorcom ukladania údajov. V zásade to znamená solídne znalosti súvisiace s .
Databázy možno považovať za dátové štruktúry, ktoré sú mimoriadne škálovateľné a odolné. Znalosť dátových štruktúr by vám preto mala byť veľmi užitočná pri výbere konkrétnej databázy. Napríklad, je server so štruktúrou údajov, ktorý podporuje rôzne typy hodnôt. Umožňuje vám pracovať s dátovými štruktúrami, ako sú zoznamy a množiny, a čítať dáta pomocou známych algoritmov, napr. , organizovanie takejto práce v trvanlivom a vysoko prístupnom štýle.
momentka od Unsplash
Keď dostatočne porozumiete rôznym vzorcom ukladania údajov, prejdite na štúdium konzistencie a dostupnosti údajov. V prvom rade musíte pochopiť aspoň vo všeobecnosti a potom tieto poznatky vylepšiť bližším pohľadom na zavedené vzory и . Týmto spôsobom si rozviniete porozumenie tejto oblasti a pochopíte, že čítanie a zapisovanie údajov sú v skutočnosti dva veľmi odlišné problémy, z ktorých každý má svoje vlastné jedinečné výzvy. Vyzbrojení niekoľkými vzormi konzistencie a dostupnosti môžete výrazne zvýšiť výkon systému a zároveň zabezpečiť hladký tok údajov do vašich aplikácií.
Na záver rozhovoru o problémoch s ukladaním údajov by sme mali spomenúť aj ukladanie do vyrovnávacej pamäte. Mal by bežať súčasne na klientovi a serveri? Aké údaje budú vo vašej vyrovnávacej pamäti? A prečo? Ako organizujete zneplatnenie vyrovnávacej pamäte? Bude sa to robiť pravidelne, v určitých intervaloch? Ak áno, ako často? Odporúčam začať študovať tieto témy s už spomínaný základný náter na návrh systému.
Komunikačné vzory
Systémy pozostávajú z rôznych komponentov; môžu to byť rôzne procesy bežiace v rámci toho istého fyzického uzla alebo rôzne stroje bežiace na rôznych častiach vašej siete. Niektoré z týchto zdrojov vo vašej sieti môžu byť súkromné, ale iné by mali byť verejné a otvorené pre spotrebiteľov, ktorí k nim majú prístup zvonku.
Je potrebné zabezpečiť komunikáciu týchto zdrojov medzi sebou, ako aj výmenu informácií medzi celým systémom a vonkajším svetom. V kontexte projektovania systémov tu opäť stojíme pred súborom nových a jedinečných výziev. Pozrime sa, ako môžu byť užitočné , a čo p.
momentka od Unsplash
Pri organizovaní komunikácie s vonkajším svetom je to vždy veľmi dôležité , ktorého poskytovanie je tiež potrebné brať vážne a aktívne presadzovať.
Rozvod pripojenia
Nie som si istý, že zaradenie tejto témy do samostatnej sekcie sa bude zdať každému oprávnené. Napriek tomu tu tento pojem podrobne predstavím a verím, že materiál v tejto časti najpresnejšie vystihuje pojem „rozvody prípojok“.
Systémy sú tvorené správnym prepojením mnohých komponentov a ich vzájomná komunikácia je často organizovaná na základe zavedených protokolov, napríklad TCP a UDP. Tieto protokoly ako také však často nestačia na uspokojenie všetkých potrieb moderných systémov, ktoré sú často prevádzkované vo vysokej záťaži a sú tiež značne závislé od potrieb používateľov. Často je potrebné nájsť spôsoby, ako rozložiť pripojenia, aby ste zvládli také vysoké zaťaženie systému.
Táto distribúcia je založená na dobre známom (DNS). Takýto systém umožňuje transformácie názvov domén, ako sú vážené okružné metódy a metódy založené na latencii, ktoré pomáhajú rozložiť zaťaženie.
je zásadne dôležitý a prakticky každý veľký internetový systém, ktorým sa dnes zaoberáme, sa nachádza za jedným alebo viacerými vyrovnávačmi záťaže. Nástroje na vyrovnávanie záťaže pomáhajú distribuovať požiadavky klientov vo viacerých dostupných inštanciách. Load balancery sú hardvérové aj softvérové, v praxi však častejšie musíte riešiť napríklad softvérové и . koncepčne tiež veľmi podobné vyrovnávačom záťaže, aj keď medzi prvým a druhým je rozsah . Tieto rozdiely je potrebné vziať do úvahy pri navrhovaní systému na základe vašich potrieb.
Mali by ste tiež vedieť o (CDN). CDN je globálna distribuovaná sieť proxy serverov, ktorá doručuje informácie z uzlov, ktoré sú geograficky umiestnené bližšie ku konkrétnemu používateľovi. CDN je vhodnejšie použiť, ak pracujete so statickými súbormi napísanými v JavaScripte, CSS a HTML. Okrem toho sú dnes bežné cloudové služby, ktoré zabezpečujú manažérov prevádzky, napr. , vďaka čomu získate globálnu distribúciu a zníženú latenciu pri práci s dynamickým obsahom. Takéto služby sú však zvyčajne užitočné v prípadoch, keď musíte pracovať s webovými službami bez stavu.
Poďme sa porozprávať o obchodnej logike. Štruktúrovanie obchodnej logiky, tokov úloh a komponentov
Podarilo sa nám teda prediskutovať rôzne infraštruktúrne aspekty systému. S najväčšou pravdepodobnosťou používateľ ani nepremýšľa o všetkých týchto prvkoch vášho systému a úprimne povedané, vôbec sa o ne nestará. Používateľ sa zaujíma o to, aké to je s vaším systémom komunikovať, čo sa tým dá dosiahnuť, a tiež ako systém vykonáva príkazy používateľa, čo a ako robí s používateľskými údajmi.
Ako naznačuje názov tohto článku, chcel som hovoriť o architektúre softvéru a návrhu systému. V súlade s tým som neplánoval pokryť vzory návrhu softvéru, ktoré popisujú, ako sa softvérové komponenty vytvárajú. Čím viac o tom však premýšľam, tým viac sa mi zdá, že hranica medzi softvérovými návrhovými vzormi a architektonickými vzormi je veľmi nejasná a tieto dva pojmy spolu úzko súvisia. Vezmime si príklad (zdroj udalostí). Keď si osvojíte tento architektonický vzor, ovplyvní takmer každý aspekt vášho systému: dlhodobé ukladanie údajov, úroveň konzistencie prijatej vo vašom systéme, tvar komponentov v ňom atď., atď. Preto som sa rozhodol spomenúť niektoré architektonické vzory, ktoré sa priamo týkajú obchodnej logiky. Aj keď sa tento článok bude musieť obmedziť na jednoduchý zoznam, odporúčam vám, aby ste sa s ním zoznámili a zamysleli sa nad myšlienkami spojenými s týmito vzormi. Nech sa páči:
- Koncept , najmä ,
Kolaboratívne prístupy
Je extrémne nepravdepodobné, že sa ocitnete na projekte ako účastník, ktorý je výlučne zodpovedný za proces návrhu systému. Naopak, s najväčšou pravdepodobnosťou budete musieť komunikovať s kolegami pracujúcimi v rámci vašej úlohy aj mimo nej. V tomto prípade možno budete musieť zhodnotiť vybrané technologické riešenia s kolegami, identifikovať obchodné potreby a pochopiť, ako najlepšie paralelizovať úlohy.
momentka od Unsplash
Prvým krokom je vytvoriť presné a spoločné pochopenie toho, aký je obchodný cieľ, ktorý sa snažíte dosiahnuť, a s akými pohyblivými časťami sa budete musieť vysporiadať. Najmä techniky skupinového modelovania (event storming) pomáhajú výrazne urýchliť tento proces a zvýšiť vaše šance na úspech. Túto prácu je možné vykonať pred alebo po načrtnutí a potom ho prehĺbiť, keď produkt zreje. Na základe úrovne konzistencie, ktorá sa tu dosiahne, môžete tiež formulovať pre obmedzený kontext, v ktorom pracujete. Keď sa potrebujete porozprávať o architektúre vášho systému, môže sa vám to hodiť , navrhnuté , najmä pokiaľ ide o pochopenie toho, koľko budete musieť ísť do detailov o probléme, vizualizovať veci, ktoré chcete komunikovať.
Pravdepodobne existuje iná vyspelá technológia na túto tému, ktorá nie je menej užitočná ako Domain Driven Design. Akosi sa však vraciame k chápaniu predmetnej oblasti, teda vedomostiam a skúsenostiam v danej oblasti by vám malo byť užitočné.
Zdroj: hab.com