Ahojte, Habr. Dnes pokračujem v sérii publikácií, ktorú som napísal špeciálne na štart nového kurzu. .
Úvod
Výber architektonického štýlu je jedným z kľúčových technických rozhodnutí pri budovaní informačného systému. V tejto sérii článkov navrhujem preskúmať najpopulárnejšie architektonické štýly aplikácií a zodpovedať na otázku, ktorý architektonický štýl je najpreferovanejší. Počas vysvetľovania sa pokúsim vytvoriť logickú súvislosť, ktorá vysvetľuje vývoj architektonických štýlov od monolitov po mikroslužby.
V Prešli sme cez monolit a dospeli sme k tomu, že monolit má niekoľko problémov: veľkosť, prepojenie, nasadenie, škálovateľnosť, spoľahlivosť a rigidnosť.
Tentokrát navrhujem hovoriť o možnostiach organizácie systému vo forme sady modulov/knižníc (architektúra orientovaná na komponenty) alebo služieb (architektúra orientovaná na služby).
Architektúra orientovaná na komponenty
Architektúra orientovaná na komponenty predpokladá realizáciu systému vo forme sady komponentov, ktoré môžu byť použité ako v aktuálnych, tak aj budúcich projektoch. Pri rozdelení systému na komponenty sa prihliada na: vhodnosť na opätovné použitie, zameniťelnosť, nezávislosť od kontextu, rozšíriteľnosť, enkapsuláciu a nezávislosť.
Pri správnom využití komponentov sa rieši problém "veľkej hromady neporiadku" (veľká veľkosť + vysoké prepojenie), pričom samotné komponenty môžu predstavovať ako jednotky zostavenia (moduly, knižnice), tak aj jednotky nasadenia (služby). Jednotky nasadenia sa vždy neprejavujú na vykonávanom procese: napríklad webová aplikácia a databáza sa nasadzujú spoločne.
Monolity sa najčastejšie vyvíjajú vo forme sady modulov. Tento prístup zabezpečuje nezávislosť vývoja, avšak problémy s nezávislým škálovaním a nasadením, odolnosťou voči poruchám a nezávislosťou od spoločného technologického stacku zostávajú. Preto je modul - čiastočne nezávislá zložka.
Najväčší problém takého monolitu spočíva v tom, že rozdelenie na moduly je čisto logické a môže byť ľahko narušené vývojármi. Môže vzniknúť modul core, ktorý sa postupne stáva smetiskom, môže rásť graf závislostí medzi modulmi a podobne. Aby sa predišlo takýmto problémom, musí vývoj prebiehať buď veľmi zrelým tímom, alebo pod vedením „architekta“, ktorý sa na plný úväzok zaoberá kontrolou kódu a upozorňuje porušovateľov logickej štruktúry vývoja.
„Ideálny“ monolit je súbor logicky oddelených modulov, z ktorých každý má svoju vlastnú databázu.
Architektúra orientovaná na služby
Ak sa predpokladá organizácia systému formou súboru služieb, ide o architektúru orientovanú na služby. Jej zásady sú: zlučiteľnosť používateľsky orientovaných aplikácií, opakované využívanie obchodných služieb, nezávislosť od technológií a autonómnosť (nezávislá evolúcia, škálovateľnosť a nasaditeľnosť).
Architektúra orientovaná na služby (SOA = service oriented architecture) rieši všetky vymedzené problémy monolitu: pri zmene sa dotkne len jednej služby a jasne definované API podporuje dobrú enkapsuláciu komponentov.
Ale nie všetko je tak jednoduché: SOA vedie k vzniku nových problémov. Vzdialené volania sú drahšie ako lokálne a presun zodpovednosti medzi komponentmi sa stal výrazne drahším.
Mimochodom, možnosť nezávislého nasadenia je veľmi dôležitou vlastnosťou služby. Ak sa služby musia nasadzovať spoločne alebo, tým viac, v určitej sekvencii, systém nemôže byť považovaný za orientovaný na služby. V takom prípade hovoríme o distribuovanom monolite (považuje sa za antipattern nielen z pohľadu SOA, ale aj mikroslužbovej architektúry).
Architektúra orientovaná na služby je dobre podporovaná architektonickou komunitou a dodávateľmi. Z toho vyplýva existencia množstva kurzov a certifikácií, dobre prepracovaných vzorov. Medzi tie posledné patrí napríklad známa podniková služobná zbus (ESB = enterprise service bus). Treba však poznamenať, že ESB je dedičstvom dodávateľov a nemusí sa nutne používať v SOA.
Vrchol popularity architektúry orientovanej na služby bol približne v roku 2008, po čom nastal pokles, ktorý sa stal výraznejším po nástupe mikroslužieb (~2015).
Záver
Po diskusii o možnostiach organizácie informačných systémov vo forme služieb a modulov, navrhujem prejsť k zásadám mikroslužbovej architektúry a osobitne sa zamerať na rozdiel medzi mikroslužbovou architektúrou a architektúrou orientovanou na služby v nasledujúcej časti.
Zdroj: habr.com
