Ahoj habr. Prihlasovanie do nového streamu kurzov je otvorené práve teraz na OTUS . V predvečer začiatku kurzu sa s vami chcem podeliť o svoj pôvodný článok.
Ú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.
Trocha histórie
Ak sa pokúsite spýtať vývojárov: „Prečo potrebujeme mikroslužby?“, dostanete rôzne odpovede. Budete počuť, že mikroslužby zlepšujú škálovateľnosť, zjednodušujú pochopenie kódu, zlepšujú odolnosť voči chybám a niekedy budete počuť, že vám umožňujú „vyčistiť si kód“. Pozrime sa do histórie, aby sme pochopili účel, ktorý stojí za vznikom mikroslužieb.
Stručne povedané, mikroslužby v našom súčasnom chápaní vznikli takto: v roku 2011 James Lewis, ktorý analyzoval prácu rôznych spoločností, upozornil na vznik nového vzoru „mikroaplikácií“, ktorý optimalizoval SOA z hľadiska zrýchlenia nasadenia služby. O niečo neskôr, v roku 2012, na summite architektúry, bol vzor premenovaný na mikroslužbu. Prvotným cieľom zavedenia mikroslužieb teda bolo zlepšiť notoricky známe doba uvedenia na trh.
Mikroslužby boli v roku 2015 na vlne humbuku. Podľa niektorých štúdií sa ani jedna konferencia nezaobišla bez správy na tému mikroslužieb. Navyše, niektoré konferencie boli venované výlučne mikroslužbám. V súčasnosti veľa projektov začína používať tento architektonický štýl a ak projekt obsahuje tony staršieho kódu, pravdepodobne sa aktívne vykonáva migrácia na mikroslužby.
Napriek všetkému vyššie uvedenému môže pomerne malý počet vývojárov stále definovať pojem „mikroservis“. Ale o tom si povieme trochu neskôr...
Monolit
Architektonický štýl, ktorý kontrastuje s mikroslužbami, je monolit (alebo všetko v jednom). Pravdepodobne nemá zmysel hovoriť, čo je monolit, takže okamžite uvediem nevýhody tohto architektonického štýlu, ktorý inicioval ďalší vývoj architektonických štýlov: veľkosť, konektivita, nasadenie, škálovateľnosť, spoľahlivosť a tuhosť. Nižšie navrhujem pozrieť sa na každý z nedostatkov samostatne.
Veľkosť
Monolit je veľmi veľký. A zvyčajne komunikuje s veľmi veľkou databázou. Aplikácia je príliš veľká na to, aby jej jeden vývojár vôbec porozumel. Iba tí, ktorí strávili veľa času prácou na tomto kóde, môžu dobre pracovať s monolitom, zatiaľ čo začiatočníci strávia veľa času snahou zistiť monolit a neexistuje žiadna záruka, že na to prídu. Väčšinou sa pri práci s monolitom vždy nájde nejaký „podmienečný“ senior, ktorý monolit viac-menej dobre pozná a do roka a pol porazí ruky ďalších nových vývojárov. Prirodzene, takýto podmienený senior je jediným bodom zlyhania a jeho odchod môže viesť k smrti monolitu.
Prepojenosť
Monolit je „veľká guľa blata“, ktorej zmeny môžu viesť k nepredvídateľným následkom. Vykonaním zmien na jednom mieste môžete poškodiť monolit na inom mieste (to isté „poškriabal si si ucho, *@ spadol“). Je to spôsobené tým, že komponenty v monolite majú veľmi zložité a čo je najdôležitejšie, nie sú zrejmé vzťahy.
Nasadenie
Nasadenie monolitu je vzhľadom na zložité vzťahy medzi jeho komponentmi dlhý proces s vlastným rituálom. Takýto rituál zvyčajne nie je úplne štandardizovaný a odovzdáva sa „ústne“.
Škálovateľnosť
Moduly Monolith môžu mať konfliktné potreby zdrojov, čo si vyžaduje kompromis z hľadiska hardvéru. Predstavte si, že máte monolit pozostávajúci zo služieb A a B. Služba A je náročná na veľkosť pevného disku a služba B je náročná na RAM. V tomto prípade musí buď stroj, na ktorom je monolit nainštalovaný, podporovať požiadavky oboch služieb, alebo budete musieť jednu zo služieb umelo deaktivovať manuálne.
Ďalší príklad (klasickejší): služba A je oveľa populárnejšia ako služba B, takže chcete, aby tam bolo 100 služieb A a 10 služieb B. Opäť dve možnosti: buď nasadíme 100 plnohodnotných monolitov, alebo na niektorých potom služby B bude potrebné vypnúť manuálne.
Spoľahlivosť
Keďže všetky služby sú umiestnené spolu, ak monolit spadne, všetky služby spadnú naraz. V skutočnosti to nemusí byť až také zlé, aspoň nedôjde k čiastočným výpadkom v distribuovanom systéme, no na druhej strane kvôli chybe vo funkcionalite, ktorú používa 0.001 % používateľov, môžete prísť o všetkých používateľov vášho systému.
Zotrvačnosť
Vzhľadom na veľkosť monolitu je ťažké prejsť na nové technológie. V dôsledku toho je udržanie toho istého seniora samostatnou úlohou. Technologický zásobník zvolený na začiatku projektu sa môže stať blokom, ktorý brzdí vývoj produktu.
Záver
Nabudúce si povieme, ako sa ľudia snažili tieto problémy vyriešiť prechodom na komponenty a SOA.
Čítaj viac:
Zdroj: hab.com