Dobrý den, habr. Přihlašování do nového streamu kurzu je otevřeno právě teď na OTUS . V předvečer začátku kurzu se s vámi chci podělit o svůj původní článek.
úvod
Volba architektonického stylu je jedním ze zásadních technických rozhodnutí při budování informačního systému. V této sérii článků navrhuji analyzovat nejoblíbenější architektonické styly pro stavební aplikace a odpovědět na otázku, kdy je který architektonický styl nejvýhodnější. V procesu prezentace se pokusím nakreslit logický řetězec, který vysvětluje vývoj architektonických stylů od monolitů po mikroslužby.
Trocha historie
Pokud se pokusíte zeptat vývojářů: „Proč potřebujeme mikroslužby?“, dostanete různé odpovědi. Uslyšíte, že mikroslužby zlepšují škálovatelnost, usnadňují pochopení kódu, zlepšují odolnost proti chybám a někdy uslyšíte, že vám umožňují „vyčistit si kód“. Podívejme se do historie, abychom pochopili účel, který stojí za vznikem mikroslužeb.
Stručně řečeno, mikroslužby v našem současném chápání vznikly následovně: v roce 2011 James Lewis, analyzující práci různých společností, upozornil na vznik nového vzoru „mikroaplikací“, který optimalizoval SOA z hlediska urychlení nasazení služby. O něco později, v roce 2012, na summitu architektury, byl vzor přejmenován na mikroslužbu. Prvotním cílem zavedení mikroslužeb tedy bylo zlepšit notoricky známé čas nakupovat.
Mikroslužby byly v roce 2015 na vlně humbuku. Podle některých studií se ani jedna konference neobešla bez zprávy na téma mikroslužeb. Některé konference byly navíc věnovány výhradně mikroslužbám. V dnešní době začíná tento architektonický styl používat mnoho projektů, a pokud projekt obsahuje tuny legacy kódu, pak se pravděpodobně aktivně provádí migrace na mikroslužby.
Navzdory všemu výše uvedenému může poměrně malý počet vývojářů stále definovat pojem „mikroslužba“. Ale o tom si povíme trochu později...
Monolit
Architektonický styl, který kontrastuje s mikroslužbami, je monolit (neboli vše v jednom). Pravděpodobně nemá smysl říkat, co je monolit, takže okamžitě uvedu nevýhody tohoto architektonického stylu, který inicioval další vývoj architektonických stylů: velikost, konektivita, nasazení, škálovatelnost, spolehlivost a tuhost. Níže navrhuji podívat se na každý z nedostatků samostatně.
velikost
Monolit je velmi velký. A obvykle komunikuje s velmi velkou databází. Aplikace je příliš velká, aby jí jeden vývojář vůbec porozuměl. S monolitem mohou dobře pracovat pouze ti, kteří strávili hodně času prací na tomto kódu, zatímco začátečníci stráví spoustu času snahou přijít na monolit a není zaručeno, že na to přijdou. Obvykle se při práci s monolitem vždy najde nějaký „podmíněný“ senior, který monolit více či méně dobře zná a do roka a půl porazí ruce dalším novým vývojářům. Přirozeně, že takový podmíněný senior je jediným bodem selhání a jeho odchod může vést ke smrti monolitu.
Propojenost
Monolit je „velká koule bahna“, jejíž změny mohou vést k nepředvídatelným následkům. Provedením změn na jednom místě můžete poškodit monolit na jiném (totéž „poškrábal jste se v uchu, *@ spadl“). Je to způsobeno tím, že součásti v monolitu mají velmi složité a hlavně nesrozumitelné vztahy.
Rozvinutí
Nasazení monolitu je vzhledem ke složitým vztahům mezi jeho komponentami dlouhý proces s vlastním rituálem. Takový rituál obvykle není zcela standardizován a předává se „ústně“.
Škálovatelnost
Moduly Monolith mohou mít konfliktní potřeby zdrojů, což vyžaduje kompromis, pokud jde o hardware. Představte si, že máte monolit sestávající ze služeb A a B. Služba A je náročná na velikost pevného disku a služba B je náročná na RAM. V tomto případě buď stroj, na kterém je monolit nainstalován, musí podporovat požadavky obou služeb, nebo budete muset ručně, uměle deaktivovat jednu ze služeb.
Další příklad (klasičtější): služba A je mnohem populárnější než služba B, takže chcete, aby tam bylo 100 služeb A a 10 služeb B. Opět dvě možnosti: buď nasadíme 100 plnohodnotných monolitů, nebo na nějaké pak služby B bude nutné deaktivovat ručně.
Spolehlivost
Protože jsou všechny služby umístěny společně, pokud monolit spadne, všechny služby spadnou najednou. Ve skutečnosti to nemusí být tak špatné, alespoň nedojde k částečným výpadkům v distribuovaném systému, ale na druhou stranu kvůli chybě ve funkčnosti, kterou používá 0.001 % uživatelů, můžete přijít o všechny uživatele vašeho systému.
Setrvačnost
Vzhledem k velikosti monolitu je obtížné přejít na nové technologie. V důsledku toho je udržení stejného seniora samostatný úkol. Zásobník technologií zvolený na začátku projektu se může stát blokem, který brání vývoji produktu.
Závěr
Příště si povíme, jak se lidé snažili tyto problémy vyřešit přechodem na komponenty a SOA.
Přečtěte si více:
Zdroj: www.habr.com