Ahoj, Habr. Práve teraz je v OTUS otvorená registrácia na nový kurz . Pred začiatkom kurzu sa s vami chcem podeliť o svoj autor článok.
Ú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.
Trochu histórie
Ak sa opýtate vývojárov: „Prečo sú potrebné mikroslužby?“, dostanete veľmi rozličné odpovede. Počujete, že mikroslužby zlepšujú škálovateľnosť, uľahčujú porozumenie kódu, zlepšujú odolnosť proti poruchám a niekedy sa môžete dozvedieť, že umožňujú „vyčistiť kód“. Poďme sa pozrieť na históriu, aby sme porozumeli, aký cieľ sledovalo vznik mikroslužieb.
Stručne povedané, mikroslužby v našom súčasnom chápání vznikli nasledujúcim spôsobom: v roku 2011 James Lewis, analyzujúc práce rôznych spoločností, si všimol vznik nového vzoru „micro-app“, ktorý optimalizoval SOA z hľadiska zrýchlenia nasadzovania služieb. O niečo neskôr, v roku 2012, bol na architektúrnom summite tento vzor premenovaný na mikroslužbu. Takže pôvodným cieľom zavedenia mikroslužieb bolo zlepšiť preslávené time to market.
Na „vlne hype“ boli mikroslužby v roku 2015. Podľa niektorých štúdií sa na žiadnej konferencii nezaobišli bez prezentácie na tému mikroslužieb. Navyše niektoré konferencie boli venované výhradne mikroslužbám. Mnoho projektov sa dnes začína s týmto architektonickým štýlom, a ak projekt obsahuje obrovské množstvo legacy kódu, určite prebieha migrácia na mikroslužby.
Napriek všetkému uvedenému je stále pomerne malé množstvo vývojárov schopných definovať pojem „mikroslužba“. O tom si však povieme neskôr...
Monolit
Architektonický štýl, ktorý stojí v protiklade k mikroslužbám, je monolit (alebo „všetko v jednom“). O monolite asi nemá zmysel rozprávať, preto rovno uvediem jeho nedostatky, ktoré iniciovali ďalší rozvoj architektonických štýlov: veľkosť, prepojenosť, nasadenie, škálovateľnosť, spoľahlivosť a rigidnosť. Nižšie sa navrhujem oboznámiť s každým z nedostatkov osobitne.
Veľkosť
Monolit je veľmi veľký. A väčšinou komunikuje s veľmi veľkou databázou. Aplikácia sa stáva príliš veľká, aby ju mohol pochopiť jeden vývojár. S monolitom dobre pracujú iba tí, ktorí strávili s týmto kódom dosť veľa času, zatiaľ čo nováčikovia strávia veľmi veľa času pokusmi o pochopenie monolitu a nie je isté, že sa im to podarí. Zvyčajne pri práci s monolitom existuje nejaký „podmienene“ senior, ktorý pozná monolit viac-menej dobre a počas jedného až pol druhého roka zasahuje do práce nových vývojárov. Je samozrejmé, že taký podmienene senior je jediným bodom zlyhania, a jeho odchod môže viesť k zániku monolitu.
Prepojenosť
Monolit predstavuje „veľký balík blata“ (big ball of mud), zmeny v ktorom môžu viesť k nepredvídateľným následkom. Zmenou v jednom mieste môžete poškodiť monolit na inom mieste (to je to „pohladil si ucho, *@ sa odtrhlo“). Je to spôsobené tým, že komponenty v monolite majú veľmi zložitú a, hlavne, nejasnú súvzťažnosť.
Nasadenie
Nasadenie monolitu v dôsledku zložitých väzieb medzi jeho komponentmi je dlhý proces s vlastným rituálom. Takýto rituál nie je zvyčajne úplne štandardizovaný a odovzdáva sa „z úst do úst“.
Škálovateľnosť
Moduly monolitu môžu mať konfliktujúce požiadavky na zdroje, čo si vyžaduje hľadanie kompromisu z hľadiska hardvéru. Predstavte si, že váš monolit sa skladá zo služieb A a B. Služba A je náročná na veľkosť pevného disku, zatiaľ čo služba B na operačnú pamäť. V takom prípade buď stroj, na ktorý sa inštaluje monolit, musí spĺňať požiadavky oboch služieb, alebo bude potrebné manuálne, umelo jeden zo služieb vypnúť.
Ďalší príklad (viac klasický): služba A je oveľa populárnejšia ako služba B, preto chcete, aby bolo 100 služieb A a 10 služieb B. Opäť existujú dve možnosti: buď nasadíme 100 plnohodnotných monolitov, alebo na niektorých z nich ručne vypneme služby B.
Spoľahlivosť
Keďže sú všetky služby spolu, ak monolit zlyhá, všetky služby zlyhajú naraz. V skutočnosti to nemusí byť tak zlé, aspoň nebudú čiastočné výpadky v distribuovanom systéme, ale na druhej strane, kvôli chybe vo funkčnosti, ktorú využíva 0,001% používateľov, môžete prísť o všetkých používateľov vašej systémy.
Neohybnosť
Vzhľadom na veľkosť monolitu je ťažké prejsť na nové technológie. Ako dôsledok sa zjavuje samostatná úloha udržať toho podmieneného seniora. Vybraný technologický stack na začiatku projektu sa môže stať prekážkou v rozvoji produktu.
Záver
Na budúce stretko budeme hovoriť o tom, ako sa ľudia snažili riešiť uvedené problémy prechodom na komponenty a SOA.
Čítať ďalej:
Zdroj: habr.com
