Ahoj, Habr. Dnes pokračuji v sérii publikací, kterou jsem napsal speciálně k zahájení nového běhu kurzu .
Úvod
Volba architektonického stylu je jedním z klíčových technických rozhodnutí při vytváření informačního systému. V této sérii článků se pokusím prozkoumat nejpopulárnější architektonické styly pro výstavbu aplikací a odpovědět na otázku, kdy je jaký architektonický styl nejvhodnější. Během vyprávění se pokusím provést logickou linii, která vysvětluje vývoj architektonických stylů od monolitů po mikroservisy.
V Zabývali jsme se monolitickým přístupem a dospěli jsme k závěru, že monolit má řadu problémů: velikost, provázanost, nasazení, škálovatelnost, spolehlivost a rigiditu.
Tentokrát navrhuji hovořit o možnostech organizace systému jako souboru modulů/knihoven (komponentně orientovaná architektura) nebo služeb (službově orientovaná architektura).
Komponentně orientovaná architektura
Komponentně orientovaná architektura předpokládá realizaci systému jako souboru komponent, které lze využít jak v aktuálních, tak i budoucích projektech. Při rozdělení systému na komponenty se zohledňuje: vhodnost pro opětovné použití, zaměnitelnost, nezávislost na kontextu, rozšiřitelnost, zapouzdření a nezávislost.
Při správném využití komponent se řeší problém "velkého balíku nepořádku" (velká velikost + vysoká provázanost), přičemž samotné komponenty mohou představovat jak jednotky sestavení (moduly, knihovny), tak jednotky nasazení (služby). Jednotky nasazení se nemusí vždy vztahovat na vykonávaný proces: například webová aplikace a databáze se nasazují společně.
Nejčastěji bývají monolity vyvíjeny jako soubor modulů. Tento přístup zajišťuje nezávislost vývoje, avšak problémy s nezávislým škálováním a nasazením, odolností a nezávislostí na společném technologickém stacku přetrvávají. Právě proto je modul částečně nezávislá komponenta.
Největší problém tohoto monolitu spočívá v tom, že dělení na moduly je čistě logické a může být snadno porušeno vývojáři. Může se objevit modul core, který se postupně mění v odpadkový koš, může růst graf závislostí mezi moduly a tak dále. Aby se předešlo takovým problémům, měla by vývojová práce probíhat buď velmi zralým týmem, nebo pod vedením "architekta", který se na plný úvazek věnuje code review a koriguje vývojáře, kteří porušují logickou strukturu.
„Ideální“ monolit představuje soubor logicky oddělených modulů, z nichž každý se dívá do své vlastní databáze.
Službově orientovaná architektura
Pokud se přece jen plánuje organizace systému ve formě sady služeb, jedná se o architekturu orientovanou na služby. Její principy: kompatibilita aplikací zaměřených na uživatele, opětovné využití obchodních služeb, nezávislost na sadě technologií a autonomnost (nezávislý vývoj, škálovatelnost a nasazení).
Architektura orientovaná na služby (SOA = service oriented architecture) řeší všechny zmíněné problémy monolitu: při změně se dotýká pouze jedné služby a jasně definované API zajišťuje dobrou enkapsulaci komponent.
Ale ne vše je tak jednoduché: SOA přináší vznik nových problémů. Vzdálené volání je dražší než lokální a přerozdělení povinností mezi komponenty se stalo výrazně dražším.
Mimochodem, možnost nezávislého nasazení je velmi důležitá vlastnost služby. Pokud se služby musí nasazovat společně nebo, tím spíše, v určité posloupnosti, systém nemůže být považován za orientovaný na služby. V takovém případě se mluví o distribuovaném monolitu (považuje se za antipattern nejen z hlediska SOA, ale také mikroslužeb).
Architektura orientovaná na služby je dobře podporována architektonickým komunitou a dodavateli. Z toho vyplývá existence mnoha kurzů a certifikací, dobře propracovaných vzorů. K těmto vzorům patří například známá podniková služební sběrnice (ESB = enterprise service bus). Při tom ESB je břemenem dodavatelů, nemusí být nutně používána v SOA.
Vrchol popularity architektury orientované na služby připadl přibližně na rok 2008, poté začala klesat, což se stalo výrazně rychlejším po příchodu mikroslužeb (~2015).
Závěr
Poté, co jsme prodiskutovali možnosti organizace informačních systémů ve formě služeb a modulů, navrhuji konečně přejít k principům architektury mikroslužeb a věnovat zvláštní pozornost rozdílu mezi mikroslužební a službami orientovanou architekturou v následující části.
Zdroj: habr.com
