Dobrý den, kolegové.
Dnes vám předkládáme překlad článku Tugberka Ugurlua, který se ve srovnatelně malém objemu pokouší přiblížit principy návrhu moderních softwarových systémů. Zde je to, co o sobě autor shrnuje:
Jelikož je naprosto nemožné obsáhnout v rychlém přehledu tak kolosální téma, jako jsou architektonické vzory + návrhové vzory k roku 2019, doporučujeme nejen samotný text pana Ugurlua, ale také mnohé odkazy, které v něm laskavě uvedl. Pokud se vám to bude líbit, zveřejníme i specializovanější text o návrhu distribuovaných systémů.
Fotografie z webu Unsplash
Pokud jste se nikdy nesetkali s takovými výzvami, jako je návrh softwarového systému od nuly, může být na začátku obtížné vědět, jak začít. Myslím, že prvním krokem je vytyčit hranice, abyste si mohli více méně jistě představit, co konkrétně se chystáte navrhnout, a poté si roll up sleeves a pracovat, aniž byste překročili tyto hranice. Jako výchozí bod můžete vzít nějaký produkt nebo službu (ideálně takovou, která se vám opravdu líbí) a podívat se na její implementaci. Možná vás překvapí, jak jednoduše tento produkt vypadá, a jaká obrovská složitost se v něm ve skutečnosti skrývá. Nezapomeňte: , a to je v pořádku.
Myslím, že nejlepší rada, kterou mohu dát těm, kteří se chystají navrhnout systém, zní: nedělejte žádné předpoklady! Od samého začátku je třeba konkretizovat fakta známá o tomto systému a s ním související očekávání. Zde je několik dobrých otázek, jejichž odpovědi vám pomohou začít s návrhem:
- Jaký je problém, který se snažíme vyřešit?
- Jaký je maximální počet uživatelů, kteří budou interagovat s naším systémem?
- Jaké vzory zápisu a čtení dat budeme používat?
- Jaké jsou očekávané případy selhání a jak se s nimi hodláme vypořádat?
- Jaká očekávání jsou kladena na konzistenci a dostupnost systému?
- Musíme při práci zohlednit nějaké požadavky týkající se externí kontroly a regulace?
- Jaké druhy důvěrných údajů plánujeme uchovávat?
To jsou jen některé otázky, které byly užitečné jak mně, tak i týmům, ve kterých jsem měl tu čest pracovat za léta své profesionální kariéry. Pokud znáte odpovědi na tyto otázky (a na jakékoli další relevantní v kontextu, ve kterém pracujete), můžete postupně proniknout do technických detailů úkolu.
Stanovujeme počáteční úroveň
Co tím myslím pod "počáteční úrovní"? V dnešní době většinu problémů v softwarovém průmyslu "lze" vyřešit pomocí již existujících metod a technologií. Tímto způsobem, orientujíc se v tomto prostředí, získáváte určitý náskok, když se setkáváte s úkoly, které už někdo před vámi řešil. Nezapomínejte, že programy jsou psány za účelem řešení problémů podnikání a uživatelů, proto se snažíme vyřešit úkol co nejjednodušším a nejpřímějším způsobem (z pohledu uživatele). Proč je důležité to mít na paměti? Možná ve vašem systému souřadnic rádi hledáte pro všechny úkoly unikátní řešení, protože si myslíte, "jaký jsem programátor, když všude dodržuji vzory"? Ve skutečnosti umění spočívá v rozhodování o tom, kde a co dělat. Samozřejmě, každý z nás se čas od času setkává s unikátními problémy, z nichž každý je opravdovou výzvou. Nicméně, pokud je naše počáteční úroveň jasně definována, víme, na co zaměřit své síly: zda hledat již dostupné možnosti řešení daného úkolu, nebo se věnovat jeho dalšímu zkoumání a hlubšímu porozumění.
Myslím, že se mi podařilo vás přesvědčit, že pokud specialista spolehlivě rozumí architektonickým aspektům některých úžasných softwarových systémů, tyto znalosti budou nenahraditelné pro ovládnutí umění architekta a vybudování solidního základu v této oblasti.
Dobře, kde tedy začít? U je repozitář na GitHubu s názvem , ze kterých se naučíte navrhovat rozsáhlé systémy a také se připravit na pohovory na toto téma. V repozitáři je sekce s příklady , kde se konkrétně podíváme na to, jak některé dobře známé společnosti přistupují k návrhu svých systémů . Nicméně dříve, než se pustíme do tohoto materiálu, podívejme se blíže na nejdůležitější architektonické výzvy, kterým čelíme v praxi. To je důležité, protože je třeba konkretizovat MNOHO aspektů nepoddajného a mnohostranného problému a poté jej řešit v rámci regulace, která v daném systému platí.
Jackson Gabbard 50minutové video o pohovorech zaměřených na návrh systémů shrnutí Získávejte znalosti o ukládání a vyhledávání dat
Obecně platí, že vaše rozhodnutí o tom, jak dlouhodobě budete ukládat a vydávat svá data, má kritický vliv na výkon systému. Proto byste měli především rozumět očekávaným charakteristikám zápisu a čtení dat ve vašem systému. Poté je třeba být schopen hodnotit tyto parametry a provést volbu na základě provedených hodnocení. Nicméně efektivně tuto práci zvládnete pouze tehdy, pokud rozumíte existujícím vzorcům ukládání dat. V podstatě to zahrnuje důkladné znalosti týkající se
výběru databáze .
Databáze lze považovat za datové struktury, které se vyznačují výjimečnou škálovatelností a trvanlivostí. Proto by měly znalosti datových struktur být užitečné i při výběru konkrétní databáze. Například, – je server strukturovaných dat, který podporuje různé typy hodnot. Umožňuje pracovat s datovými strukturami jako jsou seznamy a množiny, číst data pomocí obvyklých algoritmů, například, , organizuje takovou práci v dlouhodobém a vysoce dostupném stylu.
Fotografie z webu Unsplash
Jakmile se dostatečně zorientujete v různých vzorech ukládání dat, přejděte k studiu konzistence a dostupnosti dat. Nejprve se budete muset naučit, , alespoň v obrysech, a poté si tyto znalosti prohloubit tím, že se podíváte na ustálené vzory a . Tak si rozšíříte obzory v této oblasti a pochopíte, že čtení a zápis dat jsou ve skutečnosti dvě velmi odlišné problémy, z nichž každé nese své vlastní výzvy. S několika vzory pro zajištění konzistence a dostupnosti budete moci výrazně zvýšit výkon systému, přičemž zajistíte kontinuitu dodávky dat do vašich aplikací.
Nakonec, když ukončujeme diskusi o otázkách ukládání dat, je třeba zmínit i o caching. Mělo by se to provádět současně na klientovi i na serveru? Jaká data budete mít ve vaší cache? A proč? Jak organizujete zneplatnění cache? Bude probíhat pravidelně, po určitém časovém intervalu? Pokud ano – jak často? Doporučuji začít prozkoumávat tato témata v výše zmíněného abecedníku pro návrh systémů.
Komunikační vzory
Systémy se skládají z různých komponent; mohou to být různé procesy běžící uvnitř jednoho fyzického uzlu, stejně jako různé stroje působící v různých částech vaší sítě. Některé z těchto zdrojů uvnitř vaší sítě mohou být soukromé, ale jiné by měly být veřejné a otevřené pro spotřebitele, kteří se k nim obracejí zvenčí.
Je třeba zajistit komunikaci mezi těmito zdroji navzájem a také výměnu informací mezi celým systémem a vnějším světem. V kontextu návrhu systémů se zde opět setkáváme s sadou nových unikátních výzev. Zjistíme, jak mohou být užitečné , a jaké r.
Fotografie z webu Unsplash
Při organizaci komunikace s vnějším světem je vždy velmi důležité , na což je také třeba přistupovat se vší vážností a aktivně se tím zabývat.
Distribuce připojení
Nejsem si jistý, zda se prezentace tohoto tématu jako samostatné sekce všem jeví jako oprávněná. Nicméně zde rozvedu tuto koncepci a považuji za nejpřesnější popis tohoto oddílu termín „distribuce připojení“ (connection distribution).
Systémy se formují správným propojením mnoha komponentů a jejich komunikace mezi sebou je často organizována na základě ustálených protokolů, jako jsou TCP a UDP. Tyto protokoly však často nestačí k uspokojení všech potřeb moderních systémů, které jsou často provozovány při vysokém zatížení a silně závisí na potřebách uživatelů. Často je nutné hledat způsoby distribuce připojení, abychom se vyrovnali s takovými vysokými zatíženími v systému.
Na základě takové distribuce leží dobře známý (DNS). Tento systém umožňuje převádět doménové jméno, jako například vážený cyklický algoritmus (weighted round robin) a metody na základě zpoždění, které pomáhají distribuovat zátěž.
je zásadně důležité a prakticky každý velký systém na internetu, se kterým se dnes musíme potýkat, je umístěn za jedním nebo několika vyvažovači zátěže. Vyvažovače zátěže pomáhají distribuovat klientské požadavky mezi mnoha dostupnými instancemi. Vyvažovače zátěže mohou být jak hardwarové, tak softwarové, ale v praxi se častěji setkáváme se softwarovými, například s a . konceptuálně se také velmi podobají vyvažovačům zátěže, i když mezi nimi existuje řada . Tyto rozdíly je nutné zohlednit při navrhování systému podle vašich potřeb.
Také je třeba vědět o (CDN). CDN je globální distribuovaná síť proxy serverů, která doručuje informace z těch uzlů, které jsou geograficky umístěny blíže k konkrétnímu uživateli. Sítě CDN se doporučuje používat, pokud pracujete se statickými soubory napsanými v JavaScriptu, CSS a HTML. Dnes jsou také oblíbené cloudové služby, které poskytují správce provozu, například , které vám zajišťují globální distribuci a snížené latence při práci s dynamickým obsahem. Tyto služby jsou však obvykle užitečné v případech, kdy musíte pracovat s webovými službami bez uchovávání stavu.
Pojďme hovořit o business logice. Strukturování business logiky, pracovních toků a komponenty
Takže jsme stihli probrat různé infrastrukturní aspekty systému. Je pravděpodobné, že uživatel si ani neuvědomuje všechny tyto prvky vašeho systému a upřímně řečeno, vůbec si s nimi nedělá starosti. Uživatel se zajímá o to, jaké to je interagovat s vaším systémem, co všechno je možné udělat, když se chováte tímto způsobem, a také jakým způsobem systém vykonává uživatelské příkazy, co a jak dělá s uživatelskými daty.
Jak je z názvu tohoto článku jasné, hodlal jsem hovořit o softwarové architektuře a návrhu systémů. Proto jsem neplánoval pokrýt návrhové vzory softwaru, které popisují, jak jsou vytvářeny softwarové komponenty. Nicméně čím více o tom přemýšlím, tím víc se mi zdá, že hranice mezi návrhovými vzory softwaru a architektonickými vzory je velmi rozmazaná a tyto dvě koncepty jsou úzce propojeny. Vezměme si například (event sourcing). Jakmile si osvojíte tento architektonický vzor, ovlivní to prakticky všechny aspekty vašeho systému: dlouhodobé uchovávání dat, úroveň konzistence, přijímanou ve vašem systému, siluetu komponentů v něm atd. Proto jsem se rozhodl zmínit některé architektonické vzory, které se přímo týkají business logiky. I když se v tomto článku musím omezit na jednoduchý seznam, doporučuji vám se s ním seznámit a zamyslet se nad myšlenkami souvisejícími s těmito vzory. Tady, prosím:
- Koncepty , konkrétně ,
Kolaborativní přístupy
Je velmi nepravděpodobné, že se na projektu ocitnete jako ten účastník, který sám odpovídá za proces návrhu systému. Naopak, pravděpodobně budete muset spolupracovat s kolegy, kteří pracují jak v rámci vašeho úkolu, tak i mimo něj. V takovém případě může být potřeba posoudit zvolené technologické řešení společně s kolegy, vyčlenit obchodní potřeby a pochopit, jak nejlépe paralelizovat úkoly.
Fotografie z webu Unsplash
Nejdříve je potřeba vypracovat přesné a obecně uznávané představy o tom, jaký je obchodní cíl, který se snažíte dosáhnout, a s jakými pohyblivými prvky budete muset pracovat. Techniky skupinového modelování, konkrétně (event storming) výrazně urychlují tento proces a zvyšují vaše šance na úspěch. Tohoto úkolu se můžete ujmout předtím, nebo poté, co vymezíte , a pak ho prohlubovat, jak produkt zraje. Na základě úrovně shody, která zde bude dosažena, můžete také formulovat pro omezený kontext, v němž pracujete. Když bude potřeba hovořit o architektuře vašeho systému, může se vám hodit , navržený , zvlášť když je potřeba pochopit, jak hluboko se musíte ponořit do detailů problému, vizualizací věcí, které chcete sdělit.
Pravděpodobně existuje i jiná vyspělá technologie v této oblasti, která je stejně užitečná jako předmětově orientované navrhování. Přesto se nějakým způsobem vždy vracíme k porozumění předmětu, a proto se znalosti a zkušenosti v oblasti budou vám určitě hodit.
Zdroj: habr.com
