Ahoj, Habr. Právě teď je v OTUS otevřen nový běh kurzu. . V předvečer zahájení kurzu s vámi chci sdílet svůj autorský článek.
Úvod
Volba architektonického stylu je jedním z klíčových technických rozhodnutí při vytváření informačního systému. V této sérii článků se pokusím prozkoumat nejpopulárnější architektonické styly pro výstavbu aplikací a odpovědět na otázku, kdy je jaký architektonický styl nejvhodnější. Během vyprávění se pokusím provést logickou linii, která vysvětluje vývoj architektonických stylů od monolitů po mikroservisy.
Trocha historie
Pokud se zeptáte vývojářů: „Proč jsou mikroservisy potřeba?“, dostanete různé odpovědi. Uslyšíte, že mikroservisy zlepšují škálovatelnost, usnadňují porozumění kódu, zlepšují odolnost proti chybám, někdy uslyšíte, že umožňují „vyčistit kód“. Pojďme se podívat do historie, abychom pochopili, jaký cíl sledovalo zavedení mikroservisů.
Pokud to shrneme, mikroservisy v našem současném pojetí vznikly takto: v roce 2011 James Lewis, analyzující práce různých firem, si všiml vzniku nového vzoru „micro-app“, který optimalizoval SOA z hlediska zrychlení nasazení služeb. O něco později, v roce 2012, byl na architektonickém summitu vzor přejmenován na mikroservis. Cílem zavedení mikroservisů tedy bylo zlepšení proslulého time to market.
Na „vlně hype“ byly mikroservisy v roce 2015. Podle některých výzkumů na žádné konferenci nechyběl příspěvek na téma mikroservisů. Navíc některé konference byly věnovány výhradně mikroservisům. Nyní začíná velmi mnoho projektů s použitím tohoto architektonického stylu, a pokud projekt obsahuje tuny legacy kódu, pak se pravděpodobně aktivně provádí migrace na mikroservisy.
Navzdory výše uvedenému je stále relativně malé množství vývojářů schopno určit pojem „mikroservis“. Ale o tom si promluvíme později...
Monolit
Architektonickým stylem, který je protikladem mikroservisního, je monolit (nebo „všechno v jednom“). O tom, co je monolit, asi nemá smysl vyprávět, proto hned vyjmenuji nedostatky tohoto architektonického stylu, které podnítily další vývoj architektonických stylů: velikost, provázanost, nasazení, škálovatelnost, spolehlivost a nehybnost. Níže navrhuji se seznámit s každým z nedostatků jednotlivě.
Velikost
Monolit je velmi rozsáhlý. Obvykle komunikuje s velkou databází. Aplikace se stává natolik složitou, že ji není schopný pochopit ani jeden vývojář. S monolitem mohou pracovat jen ti, kdo strávili dostatek času nad tímto kódem, zatímco nováčci budou trávit hodně času pokusy přizpůsobit se monolitu, a není zaručeno, že to zvládnou. Při práci s monolitem obvykle existuje nějaký "podmíněný" senior, který monolit zná více-méně dobře a po dobu jednoho až jednoho a půl roku „přidržuje“ ostatní nové vývojáře. Samozřejmě, že takový podmíněný senior je jediným bodem selhání, a jeho odchod může vést k zániku monolitu.
Vazba
Monolit je jako "velký chumel bahna" (big ball of mud), jehož změny mohou mít nepředvídatelné důsledky. Změny na jednom místě mohou poškodit monolit na jiném místě (to je to „poškrábání ucha, a *@ odpadlo“). Je to způsobeno tím, že komponenty v monolitu mají velmi složité a především nejasné vzájemné vazby.
Nasazení
Nasazení monolitu kvůli složitým vazbám mezi jeho komponenty je dlouhý proces s vlastním rituálem. Takový rituál obvykle není zcela standardizován a předává se "z úst do úst".
Škálovatelnost
Moduly monolitu mohou mít konfliktující požadavky na zdroje, proto je třeba hledat kompromis z pohledu hardwaru. Představte si, že váš monolit se skládá ze služeb A a B. Služba A vyžaduje velké množství místa na disku, zatímco služba B vyžaduje hodně operační paměti. V takovém případě buď stroj, na který se monolit nasazuje, musí splňovat požadavky obou služeb, nebo se bude muset některá ze služeb uměle vypnout.
Další příklad (tradičnější): služba A je mnohem populárnější než služba B, a proto chcete, aby bylo 100 služeb A a 10 služeb B. Opět existují dvě možnosti: buď nasazujeme 100 plnohodnotných monolitů, nebo na některých z nich je nutné manuálně služby B vypnout.
Spolehlivost
Jelikož jsou všechny služby spojeny, pokud monolit selže, selžou všechny služby najednou. Ve skutečnosti to možná není tak špatné, alespoň nebudou částečné výpadky v distribuovaném systému, na druhou stranu však kvůli chybě ve funkčnosti, kterou používá 0,001 % uživatelů, můžete ztratit všechny uživatele vašeho systému.
Konzervatismus
Vzhledem k velikosti monolitu je těžké přejít na nové technologie. Důsledkem je, že se jako samostatný úkol vyjasňuje udržení takového conditio sine qua non seniora. Vybraný technologický stack na začátku projektu se může stát překážkou bránící rozvoji produktu.
Závěr
Příště si povíme, jak se lidé snažili vyřešit zmíněné problémy přechodem na komponenty a SOA.
Číst víc:
Zdroj: habr.com
