Architektúra mikroslužieb – čo to je a  prečo ju používame (1. časť)

Počuli ste už o termíne architektúra mikroservisov? Je to jedna z možných alternatív ku všeobecne známej monolitickej architektúre. Dnes už existuje viacero typov architektúr a voľba, ktorú použiť, závisí hlavneod projektu. Neexistuje žiadna ideálna možnosť, nakoľko každá architektúra má svoje výhody i nevýhody.

Aký je rozdiel v  porovnaní s  monolitickou architektúrou?

Architektúramikroslužieb pozostáva - v  porovnaní s  monolitickou architektúrou - z  kolekcieviacerýchslužieb, kde má každá svoj konkrétny obchodný význam. Takúto mikroslužbu si môžeme predstaviť ako malú aplikáciu, ktorá riadilen špecifický set funkcionalít v rámci celého informačného systému. Jedna služba má na starosti napríklad správu používateľov zahŕňajúc registráciu, prihlásenie, obnovu hesla a  úpravu profilu, no iná môže maťna starostiproduktový katalóg, kategorizáciu produktov a  všetko okolo nich.

Motivácia

V projektoch, ktoré sme vyvíjali, sme videli, že sa často opakujú rovnaké funkcionality a programovať ich znova a znova nebolo efektívne. S narastajúcim dopytom po komplexných informačných systémoch sme potrebovali do nášho procesu zaviesť viac "znovupoužívania".Základný prístup k  vývoju nám už nestačil, lebo viedol k  opakovaniu rovnakej práce viackrát. Prístup s  prepoužívanýmia  zdieľanými časťami, nazývanými mikroslužby, by priniesol do nášho procesu väčšiu efektivitu a  naše riešenia lepšiepripravil naplneniepožiadavok našichklientov.

Aké benefity prináša?

Pre dosiahnutie znovupoužiteľnosti mikroslužieb ich musíme vyvíjať generické a  konfigurovateľné.Len zmenami ich konfigurácie musia byť pripravené na viaceré prípady, a  to väčšinou bez zmien ich kódu. Registrácia a  aktivačný proces používateľského účtu v  pouíivateľkom module (tzv. „User module“) je dobrým príkladom, ktorý môže fungovať ako okamžitý(bez aktivačného emailu) v  jednom projekte a v  inom zas vyžadujúci overenie aktivačným e-mailom.

V  komplexných informačných systémoch môžu niektoré časti potrebovať viacvýkonu ako ostatné. To užnie je problémom, pretožejednoducho môžeme vyhradiť viac zdrojov pre konkrétnu mikroslužbu. Spracovanie veľkého množstva dát, čo je známym problémom obrovských aplikácií, pomáha riešiť škálovateľnosť vo forme viacerých inštancií jednej mikroslužby. Prirodzene tak z  tejto architektúry vyplýva aj vysoká dostupnosť služieb, keďže počas údržby alebo  aktualizácie jednej mikroslužby nie sú zasiahnuté všetky ostatné a  môžu tak pokračovať vo svojej funkčnosti.

Aktuálizácie a  bezpečnosť

Komplexné informačné systémy často využívajú integrácie treťostranných služieb, ako napríklad daňové systémy, poskytovateľov e-mail serverov, SMS brány, platobné brány,... Keď vznikne potreba vymeniť treťostrannú službu za inú, oproti monolitickej architektúre nie je tento proces tak náročný. Nakoľko sú integrácie týchto treťostranných služieb naprogramované ako nezávislé mikroslužby, nie je problém ich vymeniť, ak dodržia stanovené rozhranievstupov a  výstupov, ktoré poskytujú. To isté platí aj pre knižnice a  frameworky. Ohlásená bezpečnostná aktualizácia danej časti vie byť zavedená individuálne, bez ovplyvnenia celého systému. Neriskujeme pokazenie inej funkcionality a  zároveň udržiavame aplikáciu bezpečnú a  aktualizovanú. Týka sa to nielen existujúcich častí systému, ale aj nových. Každej novej službe môže byť technológia zvolená nezávisle od ostatných podľa jej potrieb.

Závery

Teraz máte základný prehľad rozdielov medzi spomenutými architektúrami a  viete,ako architektúra mikroslužieb pomáha dodávať rýchlejšie, ušetriť peniaze klienta a  poskytovaťsoftvér vyššej kvality. V  ďalšej časti tejto série o  architektúre mikroslužieb sa pozrieme na zmeny v  našich procesoch, ktoré sme museli spraviť a  ako sme saim my, vývojári, prispôsobili.

Autori:Dávid Ondruš,Richard Roštecký, Tibor Hanesz