Ahoj Habr. Dnes pokračujem v sérii publikácií, ktoré som napísal špeciálne pre začiatok nového prúdu kurzu. .
Úvod
Výber architektonického štýlu je jedným zo zásadných technických rozhodnutí pri budovaní informačného systému. V tejto sérii článkov navrhujem analyzovať najpopulárnejšie architektonické štýly pre stavebné aplikácie a odpovedať na otázku, kedy je ktorý architektonický štýl najvýhodnejší. V procese prezentácie sa pokúsim nakresliť logický reťazec, ktorý vysvetľuje vývoj architektonických štýlov od monolitov po mikroslužby.
В zaoberali sme sa monolitom a dospeli sme k záveru, že monolit má množstvo problémov: veľkosť, konektivita, nasadenie, škálovateľnosť, spoľahlivosť a tuhosť.
Tentoraz navrhujem hovoriť o možnostiach organizácie systému ako súboru modulov/knižníc (komponentovo orientovaná architektúra) alebo služieb (servisne orientovaná architektúra).
Komponentovo orientovaná architektúra
Komponentovo orientovaná architektúra zahŕňa spustenie systému ako súboru komponentov, ktoré možno použiť v súčasných aj budúcich projektoch. Pri rozdeľovaní systému na komponenty sa berú do úvahy: ich opätovná použiteľnosť, ich zameniteľnosť, nezávislosť od kontextu, rozšíriteľnosť, zapuzdrenie a nezávislosť.
Správnym používaním komponentov je vyriešený problém „veľkej gule nečistôt“ (veľká veľkosť + vysoká spojka) a samotné komponenty môžu byť montážne jednotky (moduly, knižnice) aj nasadzovacie jednotky (služby). Jednotky nasadenia nie sú vždy namapované na spustený proces: napríklad webová aplikácia a databáza sú nasadené spoločne.
Najčastejšie sa monolity vyvíjajú ako súbor modulov. Tento prístup vedie k nezávislému vývoju, ale problémy nezávislého škálovania a nasadenia, odolnosti voči chybám a nezávislosti od celkového technologického zásobníka zostávajú. Preto je modul čiastočne nezávislý komponent.
Najväčším problémom takéhoto monolitu je, že rozdelenie na moduly je čisto logické a vývojári ho môžu ľahko porušiť. Môže sa objaviť základný modul, ktorý sa postupne zmení na smetisko, môže rásť graf závislostí medzi modulmi atď. Aby sa predišlo takýmto problémom, vývoj by mal vykonávať buď veľmi vyspelý tím, alebo pod vedením „architekta“, ktorý sa venuje kontrole kódu na plný úväzok a poráža ruky vývojárov, ktorí porušujú logickú štruktúru.
„Ideálny“ monolit je súbor logicky oddelených modulov, z ktorých každý nazerá do vlastnej databázy.
Architektúra orientovaná na služby
Ak má byť systém organizovaný vo forme súboru služieb, potom hovoríme o architektúre orientovanej na služby. Jeho princípmi sú interoperabilita aplikácií zameraná na používateľa, opätovné použitie obchodných služieb, nezávislosť zásobníka technológií a autonómia (nezávislý vývoj, škálovateľnosť a nasadenie).
Servisne orientovaná architektúra (SOA = service oriented architecture) rieši všetky identifikované problémy monolitu: zmena je ovplyvnená iba jednou službou a dobre definované API podporuje dobré zapuzdrenie komponentov.
Ale nie všetko je také hladké: SOA vytvára nové problémy. Vzdialené hovory sú drahšie ako lokálne a výrazne sa predražilo aj prerozdelenie povinností medzi komponenty.
Mimochodom, možnosť nezávislého nasadenia je veľmi dôležitou vlastnosťou služby. Ak musia byť služby nasadené spoločne alebo navyše v určitom poradí, potom systém nemožno považovať za orientovaný na služby. V tomto prípade sa hovorí o distribuovanom monolite (považovanom za anti-vzor nielen z pohľadu SOA, ale aj z pohľadu architektúry mikroslužieb).
Architektúra orientovaná na služby je dobre podporovaná architektonickou komunitou a predajcami. To znamená prítomnosť mnohých kurzov a certifikácií, dobre vyvinutých vzorov. K tomu poslednému patrí napríklad známa zbernica podnikových služieb (ESB = enterprise service bus). ESB je zároveň batožinou od predajcov, nemusí sa nevyhnutne používať v SOA.
Obľúbenosť architektúry orientovanej na služby vyvrcholila okolo roku 2008, po ktorom začala klesať, čo sa výrazne zdramatizovalo po nástupe mikroslužieb (~2015).
Záver
Po tom, čo sme si rozobrali možnosti organizácie informačných systémov vo forme služieb a modulov, navrhujem prejsť konečne k princípom architektúry mikroslužieb a v ďalšej časti venovať osobitnú pozornosť rozdielu medzi architektúrou mikroslužieb a architektúrou orientovanou na služby.
Zdroj: hab.com