Dobrý den, Habr. Dnes pokračuji v sérii publikací, které jsem napsal speciálně pro začátek nového proudu kurzu. .
ú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.
В zabývali jsme se monolitem a došli jsme k závěru, že monolit má řadu problémů: velikost, konektivitu, nasazení, škálovatelnost, spolehlivost a rigiditu.
Tentokrát navrhuji hovořit o možnostech organizace systému jako sady modulů/knihoven (komponentově orientovaná architektura) nebo služeb (servisně orientovaná architektura).
Komponentově orientovaná architektura
Komponentově orientovaná architektura zahrnuje spouštění systému jako sady komponent, které lze použít v současných i budoucích projektech. Při členění systému na komponenty se berou v úvahu: jejich znovupoužitelnost, jejich nahraditelnost, kontextová nezávislost, rozšiřitelnost, zapouzdření a nezávislost.
Správným použitím komponentů je problém „velké koule nečistot“ (velká velikost + vysoká spojka) vyřešen a samotné komponenty mohou být jak montážní jednotky (moduly, knihovny), tak jednotky nasazení (služby). Jednotky nasazení nejsou vždy namapovány na běžící proces: například webová aplikace a databáze jsou nasazeny společně.
Nejčastěji jsou monolity vyvíjeny jako sada modulů. Tento přístup vede k nezávislému vývoji, ale problémy s nezávislým škálováním a nasazením, odolností proti chybám a nezávislostí na celkovém technologickém zásobníku přetrvávají. Proto je modul částečně nezávislou komponentou.
Největší problém takového monolitu je, že rozdělení na moduly je čistě logické a vývojáři jej mohou snadno porušit. Může se objevit jádrový modul, který se postupně změní na smetiště, může se zvětšit graf závislostí mezi moduly a tak dále. Aby se předešlo takovým problémům, vývoj by měl provádět buď velmi zralý tým, nebo pod vedením „architekta“, který se zabývá kontrolou kódu na plný úvazek a bije do rukou vývojářů, kteří porušují logickou strukturu.
„Ideální“ monolit je sada logicky oddělených modulů, z nichž každý nahlíží do své vlastní databáze.
Architektura orientovaná na služby
Pokud má být systém organizován ve formě sady služeb, pak hovoříme o architektuře orientované na služby. Jeho principy jsou interoperabilita aplikací zaměřených na uživatele, opětovné použití obchodních služeb, nezávislost na zásobníku technologií a autonomie (nezávislý vývoj, škálovatelnost a nasazení).
Architektura orientovaná na služby (SOA = service oriented architecture) řeší všechny identifikované problémy monolitu: při změně je ovlivněna pouze jedna služba a dobře definované API podporuje dobré zapouzdření komponent.
Ale ne všechno je tak hladké: SOA vytváří nové problémy. Vzdálená volání jsou dražší než místní a výrazně se prodražilo přerozdělování povinností mezi komponenty.
Mimochodem, možnost samostatného nasazení je velmi důležitou vlastností služby. Pokud musí být služby nasazeny společně nebo navíc v určitém pořadí, nelze systém považovat za orientovaný na služby. V tomto případě se mluví o distribuovaném monolitu (považovaném za anti-vzor nejen z pohledu SOA, ale i z pohledu architektury mikroslužeb).
Architektura orientovaná na služby je dobře podporována architektonickou komunitou a prodejci. To znamená přítomnost mnoha kurzů a certifikací, dobře vyvinutých vzorů. Mezi posledně jmenované patří například známá podniková servisní sběrnice (ESB = enterprise service bus). ESB je zároveň zavazadlo od prodejců, nemusí být nutně použito v SOA.
Obliba architektury orientované na služby dosáhla vrcholu kolem roku 2008, poté začala upadat, což se výrazně zdramatizovalo po nástupu mikroslužeb (~2015).
Závěr
Poté, co jsme probrali možnosti organizace informačních systémů ve formě služeb a modulů, navrhuji přejít konečně k principům architektury mikroslužeb a věnovat zvláštní pozornost rozdílu mezi architekturou mikroslužeb a architekturou orientovanou na služby v další části.
Zdroj: www.habr.com