Architektúra mikroservisov: kompletný a praktický sprievodca

Informatec Digital » Zdroje » Architektúra mikroservisov: kompletný a praktický sprievodca

Architektúra mikroservisov sa stala de facto štandardom pre budovanie moderných cloudových aplikácií: je škálovateľná, odolná a ľahko sa vyvíja. Zďaleka nie je len „trikom“ na rozbitie monolitu, ale znamená hlboké zmeny v spôsobe, akým navrhujeme, vyvíjame, nasadzujeme a prevádzkujeme softvér.

V tomto článku sa podrobne a veľmi prakticky pozrieme na to, čo je architektúra mikroslužieb a decentralizovaná architektúra , aké sú ich skutočné výhody a nevýhody, aké komponenty ich umožňujú, ako súvisia so vzormi ako MVC alebo čistá architektúra, akú úlohu hrajú databázy a kontajnery a aké návrhové a nasadzovacie vzory sú kľúčové pre zabránenie tomu, aby sa vynález stal neudržateľným chaosom.

Čo je vlastne architektúra mikroservisov?

Keď hovoríme o mikroslužbách, máme na mysli vývojový prístup, kde je aplikácia rozdelená na malé, autonómne a špecializované služby , pričom každá z nich má jasne definovanú obchodnú zodpovednosť. Tieto služby zvyčajne komunikujú prostredníctvom ľahkých API (REST, gRPC, zasielanie správ, udalosti), sú nasadzované nezávisle a často spravujú vlastné úložisko údajov.

Mikroslužba je v podstate samonasaditeľná softvérová súčasť, ktorú riadi malý tím zodpovedný za celý jej životný cyklus: návrh, vývoj, testovanie, nasadenie, pozorovateľnosť a údržbu. Tento koncept „produkt, nie projekt“ je jadrom modelu: služba nie je dodaná a zabudnutá; je pestovaná a neustále vyvíjaná.

Na rozdiel od klasickej monolitickej architektúry, kde všetky funkcie koexistujú v jednom procese a jednej databáze , mikroslužby volia oddelenie: každá služba môže byť napísaná v inom jazyku, používať vlastnú databázovú technológiu a byť verzovaná vlastným tempom bez toho, aby sa s každou zmenou musel ťahať celý systém.

Tento model dokonale zapadá do postupov DevOps , kontinuálnej integrácie a kontinuálneho dodávania , pretože umožňuje rýchle, časté a nízkorizikové cykly nasadenia. Zavádza však novú úroveň zložitosti v oblasti sietí, dát, pozorovateľnosti a riadenia, ktorú je potrebné efektívne riadiť.

Kľúčové vlastnosti mikroslužieb

Systém založený na mikroslužbách má zvyčajne niekoľko spoločných charakteristík, hoci každá organizácia ich implementuje vlastným spôsobom :

Po prvé, komponenty aplikácie sú implementované ako nezávislé služby, ktoré fungujú ako izolované jednotky nasadenia a nahrady . Namiesto knižníc v pamäti služby komunikujú pomocou volaní HTTP/REST, gRPC alebo posielania správ, čo síce zavádza latenciu, ale znižuje prepojenie.

Dekompozícia je založená na obchodných možnostiach , nie na technických vrstvách. Každá služba je zosúladená s definovanou subdoménou alebo kontextom (napr. používatelia, katalóg, objednávky, platby) a centralizuje všetku potrebnú logiku: API, logiku domény, prístup k údajom a integráciu tretích strán.

Prijíma sa mentalita „produkty, nie projekty“ : za mikroslužbu počas celého jej životného cyklu je zodpovedný jeden multidisciplinárny tím (backend, frontend, QA, DevOps). To podporuje komplexné vlastníctvo, urýchľuje dodanie a zabraňuje nekonečnému prideľovaniu úloh medzi oddeleniami.

Pokiaľ ide o štýl integrácie, vo všeobecnosti sa uprednostňuje princíp „inteligentných koncových bodov a jednoduchých kanálov“ . Obchodná logika spočíva v službách, zatiaľ čo komunikačná infraštruktúra (HTTP, fronty, sprostredkovatelia udalostí) je udržiavaná čo najľahšia, čím sa vyhýba hyperkomplexným orchestráciám spojeným s náročnými protokolmi a uprednostňuje sa programovanie riadené udalosťami.

Ďalšou dôležitou vlastnosťou je decentralizovaná správa technológie : každý tím si môže vybrať jazyk, framework a typ databázy, ktoré najlepšie vyhovujú jeho potrebám, pokiaľ dodržiava minimálne prierezové štandardy (zabezpečenie, protokolovanie, pozorovateľnosť, zmluvy API). Táto sloboda umožňuje optimalizáciu výkonu, nákladov a produktivity v jednotlivých prípadoch.

Decentralizovaná správa údajov a vzor databázy podľa mikroslužieb

Jedným z najcitlivejších rozhodnutí pri migrácii na tento prístup je spôsob spracovania údajov. Najbežnejším vzorom je databáza na mikroslužbu : každá služba vlastní a spravuje svoju vlastnú databázu, ktorá môže byť inštanciou rovnakej technológie ako ostatné alebo niečím úplne iným.

Tento prístup zvyšuje autonómiu, pretože každá zmena schémy ovplyvňuje iba službu, ktorá vlastní dané dáta , znižuje úzke miesta na jednom databázovom serveri a podporuje perzistenciu polyglotov: jedna služba môže používať PostgreSQL, iná MongoDB, ďalšia vyrovnávaciu pamäť v Redise a ďalšia vyhľadávací nástroj ako Elasticsearch pre komplexné dotazy a analýzu textu.

Napríklad na stránke elektronického obchodu by sme mohli mať používateľskú službu ukladajúcu svoje relačné dáta v PostgreSQL , katalógovú službu používajúcu NoSQL databázu na modelovanie vysoko variabilných produktov, objednávkovú službu s inou relačnou databázou optimalizovanou pre transakcie, službu nákupného košíka podporovanú Redisom pre prchavé dáta a vyhľadávaciu službu s Elasticsearch pre komplexné dotazy a analýzu textu.

Nevýhodou je, že distribuované transakcie ACID sa stávajú nepraktickými . Namiesto jednej veľkej transakcie, ktorá ovplyvňuje viacero tabuliek, sa na koordináciu zmien medzi službami zvyčajne používa konečná konzistencia, udalosti domény a vzory ako Saga, pričom sa akceptuje, že rôzne služby môžu mať krátkodobo rôzne stavy.

Na prístup k údajom patriacim inej službe sa namiesto „zaostávania“ za jej databázou odporúča použiť vzory ako API Composition (služba zostavuje údaje volaním niekoľkých proprietárnych služieb) alebo CQRS (oddelené čítania a zápisy a aktualizácia projekcií iba na čítanie podľa udalostí).

Orchestrácia verzus choreografia a ságový vzor

Keď obchodný proces zahŕňa niekoľko služieb (napr. registrácia zákazníka, vytvorenie vernostného účtu, doručenie uvítacej súpravy a e-mail ), existujú dva hlavné štýly koordinácie: orchestrácia a choreografia.

Pri orchestračnom prístupe existuje centrálny komponent (orchestrátor alebo „koordinačná“ služba), ktorý pozná celý tok: vyvoláva službu bodov, potom poštovú službu, nakoniec e-mailovú službu, riadi medziľahlé stavy a spracováva chyby. Je jednoduchšie ho sledovať, ale má tendenciu sústrediť príliš veľa logiky a stať sa „centralizovaným monštrom“.

Naproti tomu pri choreografickom prístupe je proces založený na udalostiach, ktoré služby publikujú a konzumujú . Zákaznícky servis vygeneruje udalosť „customer_created“ (vytvoril zákazník); vernostná služba ju počúva a priraďuje body; poštová služba počúva a generuje e-mail; e-mailová služba odosiela uvítaciu správu. Každá služba vie, čo má robiť, keď pozoruje určité udalosti, bez centrálneho prvku, ktorý by diktoval priebeh.

Vzor Saga využíva tieto myšlienky na správu distribuovaných transakcií. Sága pozostáva z reťazca lokálnych operácií naprieč rôznymi službami a v prípade chyby zo série kompenzačných akcií, ktoré vrátia späť (alebo zmiernia) predchádzajúce zmeny. Ságy je možné implementovať orchestrovaným spôsobom (jeden komponent riadi celý tok) alebo choreografickým spôsobom (každá služba reaguje na udalosti a publikuje nové).

Choreografia je zvyčajne vhodnejšia pre vysoko distribuované, udalosťami riadené architektúry mikroslužieb, ale vyžaduje si veľmi dobrú pozorovateľnosť a monitorovanie obchodného toku , aby sa vedelo, čo sa stalo v každom kroku, a aby sa odhalili nezrovnalosti alebo čiastočné zlyhania.

Vzory odolnosti a odolnosti voči chybám

V distribuovanom systéme je nevyhnutné akceptovať, že akékoľvek volanie služby môže zlyhať, trvať príliš dlho alebo vrátiť občasné chyby . Ignorovanie tohto je receptom na kaskádové zlyhania a globálne výpadky.

Na minimalizáciu týchto rizík sa používa niekoľko vzorcov odolnosti, počnúc maximálnymi časovými limitmi pre všetky vzdialené volania. Nikto nechce, aby boli vlákna blokované donekonečna čakajúce na výpadok služby; po uplynutí časového limitu sa klient môže rozhodnúť, či to skúsi znova, zaradiť operáciu do frontu na neskôr alebo znížiť funkčnosť.

Vzor ističa pridáva ďalšiu vrstvu ochrany: ak klient zistí, že významné percento volaní do služby zlyháva, „otvorí okruh“ a na chvíľu sa zastaví pri pokusoch o vyvolanie tejto služby, pričom vráti okamžité zlyhania alebo zhoršené odpovede. Po určitom intervale povolí niekoľko testovacích volaní (polootvorený stav) a ak sú aj tieto úspešné, okruh opäť uzavrie.

Je tiež bežné navrhovať vodotesné priehradky , logické aj fyzické, aby sa zachytili škody: viacero podov na službu, viacero počítačov alebo dokonca viacero regiónov, aby lokalizovaná porucha nespôsobila výpadok celého systému. Použitie techník, ako sú obmedzovanie rýchlosti alebo fronty na vyrovnávanie záťaže, pomáha predchádzať náhlym výkyvom, ktoré by mohli ochromiť kritické služby.

Toto všetko je podporované opakovane použiteľnými modulmi odolnosti (napríklad knižnice ako Resilience4j integrované s frameworkami ako Spring Cloud), ktoré vám umožňujú konfigurovať politiky opakovania, limity požiadaviek, ističe a správu chýb centralizovaným a konzistentným spôsobom vo všetkých službách.

Typické komponenty architektúry mikroslužieb

Okrem samotných obchodných služieb obsahuje vyspelá architektúra mikroslužieb aj sériu základných komponentov platformy, aby sa zabezpečilo, že všetko bude spoľahlivo fungovať :

Na jednej strane je tu orchestrátor alebo platforma kontajnerov (zvyčajne Kubernetes), ktorá je zodpovedná za plánovanie a spúšťanie kontajnerov, škálovanie replík, reštartovanie zlyhaných služieb a poskytovanie mechanizmov vyhľadávania služieb a vyvažovania internej záťaže; na túto infraštruktúru sa odporúča aplikovať opatrenia na zabezpečenie kontajnerov.

Na okraji architektúry sa nachádza API Gateway , ktorá slúži ako jednotný vstupný bod pre externých klientov: smeruje požiadavky do správnej mikroslužby, vynucuje autentifikáciu a autorizáciu, pridáva alebo overuje bezpečnostné hlavičky, riadi kvóty, funguje ako TLS proxy a v mnohých prípadoch agreguje odpovede.

Pre asynchrónnu komunikáciu sa používajú platformy na odosielanie správ a streamovanie, ako napríklad Apache Kafka alebo Azure Service Bus, ktoré podporujú vzory publikovania a odberu, fronty úloh, udalosti domén a vysoko škálovateľné architektúry riadené udalosťami.

Pozorovateľnosť je ďalším kritickým prvkom: centralizované protokoly, metriky aplikácií, distribuované sledovania a monitorovanie v reálnom čase nám umožňujú pochopiť, čo sa deje v systéme s desiatkami alebo stovkami služieb. Rámce ako OpenTelemetry a kanály zberu a analýzy (s vyhradenými kolektormi) sú teraz nevyhnutné.

Nakoniec, centralizovaná správa konfigurácie a bezpečnostný modul (prístupové tokeny, mTLS medzi službami, riadenie prístupu na základe rolí, správa tajných údajov) dopĺňajú obraz. Konfigurácia je externalizovaná z kódu, takže tie isté artefakty je možné nasadiť vo viacerých prostrediach zmenou iba externých parametrov.

Architektúra a návrhové vzory v mikroslužbách

Aby sa predišlo znovuvynájdeniu kolesa (a upadnutiu do anti-vzorov), je kľúčové spoliehať sa na architektonické a dizajnové vzory, ktoré sa osvedčili v distribuovaných prostrediach :

Vo fáze modelovania vyniká vzor Decompose by Subdomain , úzko spojený s dizajnom riadeným doménou (DDD). Cieľom je identifikovať jasne definované subdomény a kontexty (používatelia, objednávky, fakturácia, logistika atď.) a priradiť im mikroslužby, ktoré sú v súlade s týmito hranicami, čím sa vyhneme službám, ktoré sú buď príliš veľké, alebo absurdne malé.

Pre synchrónnu komunikáciu sa používa vzor Vzdialené volanie procedúr (Remote Procedure Invocation) , implementovaný pomocou REST, gRPC, GraphQL alebo WebSockets. Odporúča sa prijať prístup API-First s použitím formálnych zmlúv (OpenAPI pre REST, gRPC IDL alebo schémy GraphQL) na návrh rozhrania a následné generovanie alebo úpravu kódu.

Keď je potrebná asynchrónna komunikácia, používa sa vzor zasielania správ (Messaging pattern ), založený na udalostiach, ktoré producent odošle brokerovi a ktoré môže viacero konzumentov spracovať vlastným tempom. Definovanie kontraktov udalostí pomocou AsyncAPI sa tu veľmi dobre hodí, podobne ako sa OpenAPI používa v REST svete.

V oblasti prístupu k údajom sa okrem databázy na mikroslužbu stáva dôležitým aj CQRS (Command Query Responsibility Segregation) : oddelenie modelu zápisu (príkazy) od modelu čítania (dotazy) pomocou projekcií a udalostí na synchronizáciu zobrazení iba na čítanie optimalizovaných pre vyhľadávanie.

Na sprístupnenie mikroslužieb externým klientom vzor API Gateway centralizuje prístup, zatiaľ čo variant ako Backend for Frontends (BFF) vytvára špecifické API pre každý typ klienta (web, mobil, interné aplikácie), ktoré agregujú a prispôsobujú údaje podľa potrieb každého rozhrania.

Vzťah k MVC, čistá architektúra a klasické vzory

V mnohých projektoch sa príbeh začína monolitickou aplikáciou založenou na MVC (Model-View-Controller): webové ovládače, ktoré spracovávajú požiadavky, modely domén úzko prepojené s jednou databázou a pohľady vykresľované na serveri.

Vzor MVC zostáva užitočný v rámci každej mikroslužby, ktorá sprístupňuje API alebo webové rozhranie (napríklad s frameworkami ako Flask v Pythone ), ale už nie je globálnou štruktúrou celej aplikácie . Súčasným trendom je oddeliť frontend (SPA, mobilné aplikácie) a používať moderné frameworky, ktoré využívajú API mikroslužieb, pričom klasický vzor MVC zostáva ako interný detail, ak sa stále používa.

Čistá architektúra je obzvlášť vhodná pre mikroslužby, pretože podporuje dobre definované vrstvy a závislosti zamerané na doménu: entity a prípady použitia v jadre, adaptéry rozhrania (kontroléry, prezentátory, perzistentné brány) smerom von a frameworky (databázy, HTTP, zasielanie správ) na okraji siete.

Aplikácia týchto princípov v rámci mikroslužby nám umožňuje chrániť obchodnú logiku pred technickými detailmi : môžeme zmeniť databázu, webový framework alebo poskytovateľa správ bez prepisovania jadra služby. Okrem toho to výrazne zjednodušuje jednotkové a integračné testovanie.

Návrhové vzory ako SOLID, oddelenie zodpovedností, vkladanie závislostí a jednoduché princípy kódu zostávajú rovnako relevantné; teraz sa uplatňujú iba v menšom kontexte každej mikroslužby, čo uľahčuje dlhodobé udržiavanie čistého kódu.

Automatizácia, CI/CD a nasadenie v kontajneroch a bezserverových riešeniach

Architektúra mikroservisov nemá zmysel bez agresívnej automatizácie celého životného cyklu v cloudových prostrediach . Pri desiatkach služieb je manuálne nasadenie receptom na katastrofu.

Tímy zvyčajne vytvárajú kanály kontinuálnej integrácie a kontinuálneho dodávania (CI/CD) , často podporované GitOps , ktoré kompilujú kód, spúšťajú testy, generujú obrazy kontajnerov, aplikujú migrácie databáz (ak je to vhodné) a nasadzujú služby opakovateľným, kontrolovaným a sledovateľným spôsobom.

Najrozšírenejším vzorom nasadenia je „nasadenie služby ako kontajnera “, pričom sa každá mikroslužba zabalí do obrazu (napríklad Docker) a replikácia, škálovanie a aktualizácie sa budú spravovať na Kubernetes alebo inom orchestratore. To umožňuje efektívne využitie zdrojov a rýchle a konzistentné nasadenie.

Okrem toho je možné použiť platformové vzory, ako napríklad service mesh (Istio, Linkerd atď.), ktoré pridávajú pokročilé možnosti smerovania, bezpečnostné politiky mTLS, podrobnú pozorovateľnosť a distribúciu prevádzky medzi verziami (canary releases, modro-zelená) bez toho, aby sa dotýkali kódu služby.

V určitých prípadoch, najmä pri veľmi špecifických alebo udalosťami riadených úlohách, prichádza na rad bezserverové nasadenie : funkcie, ktoré bežia na požiadanie (napríklad AWS Lambda) a sú riadené službami, ako je API Gateway, fronty, streamy alebo plánovače. Hoci nie všetko musí byť bezserverové, zvyčajne sa hodí pre veľmi malé a vysoko elastické mikroslužby.

Bezpečnosť, pozorovateľnosť a testovanie v distribuovaných systémoch

Bezpečnosť v mikroslužbách sa spolieha na princíp Zero Trust: nikto štandardne nikomu nedôveruje . To zahŕňa robustnú autentifikáciu prostredníctvom API Gateway (OAuth2, OIDC), vydávanie tokenov (napr. JWT), ktoré sa odosielajú s každou požiadavkou, lokálnu autorizáciu v každej službe a šifrovanie prevádzky medzi službami pomocou mTLS.

Vzor prístupového tokenu tento prístup dobre zhŕňa: brána overuje poverenia klienta, generuje token s bezpečnostným kontextom (identita, roly, rozsahy) a preposiela ho mikroslužbám, ktoré ho používajú na prijímanie rozhodnutí o autorizácii bez ukladania hesiel alebo internej logiky autentifikácie.

Pokiaľ ide o pozorovateľnosť, kombinuje sa niekoľko vzorcov: Metriky aplikácií (technické a obchodné metriky pre každú službu), Protokolovanie auditu (auditné protokoly akcií používateľov), Distribuované sledovanie (po požiadavke prostredníctvom viacerých služieb), Sledovanie výnimiek (centralizované systémy správy chýb), API kontroly stavu (koncové body stavu) a Agregácia protokolov (agregácia protokolov na spoločnej platforme).

Toto všetko umožňuje detekciu anomálií, skracuje diagnostické časy a poskytuje pochopenie toho, ako sa systém správa pri reálnych záťažiach. Bez dobrej pozorovateľnosti sa systém mikroslužieb stáva čiernou skrinkou, ktorú je takmer nemožné prevádzkovať.

V oblasti testovania sa okrem klasických jednotkových testov stávajú relevantnými aj vzory ako Service Integration Contract Test (overenie, či poskytovateľ a spotrebiteľ rešpektujú rovnakú API zmluvu) a Service Component Test (spúšťanie služby izolovane pomocou externých závislostí), čím sa znižuje závislosť od krehkých a pomalých end-to-end testov.

Nakoniec, zrelá kultúra DevOps a prax chaosového inžinierstva (vnášanie kontrolovaných zlyhaní na overenie odolnosti architektúry) pomáhajú zabezpečiť, aby sa systém správal správne, keď sa niečo pokazí, čo sa v produkčnom prostredí vždy stane skôr či neskôr.

Výhody, nevýhody a kritériá prijatia

Hlavné výhody mikroslužieb sa točia okolo agility a škálovateľnosti: malé a autonómne tímy, časté nasadzovanie bez zastavenia celej aplikácie, nezávislé škálovanie každej funkčnej oblasti, technologická sloboda pre každú službu a väčšia odolnosť vďaka izolácii chýb.

Taktiež podporujú opätovné použitie dobre zapuzdrených funkcií (platobná, autentifikačná alebo notifikačná služba môže slúžiť ako štandardný stavebný kameň pre mnohé riešenia), znižujú náklady na lokálne zmeny a umožňujú lepšie zosúladenie organizácie (tímov) s obchodným modelom (domény a produkty).

Na druhej strane, mikroslužby prinášajú zďaleka nie triviálnu zložitosť : viac bodov zlyhania, vyššiu latenciu siete, väčšie ťažkosti s udržiavaním konzistencie údajov, sofistikovanejšie procesy nasadzovania a testovania a oveľa väčšiu potrebu nástrojov na sledovanie, automatizáciu a riadenie.

Okrem toho vyžadujú technické profily so skúsenosťami v oblasti distribuovaných systémov , kontajnerov, Kubernetes, bezpečnosti, integračných vzorov, riadenia API a návrhu domén, čo nie je vždy dostupné vo všetkých tímoch alebo spoločnostiach.

Preto má architektúra mikroservisov zmysel predovšetkým v organizáciách s rozsiahlou kódovou základňou, mnohými tímami, vysokou mierou funkčných zmien a silnými požiadavkami na škálovateľnosť , ako sú napríklad veľké digitálne platformy, komplexné SaaS alebo systémy s masívnym publikom. Pre malé aplikácie alebo s malým tímom je dobrý modulárny monolit zvyčajne jednoduchší, lacnejší a postačujúci.

Architektúra mikroservisov predstavuje významný skok vpred oproti tradičnému monolitickému vývoju, ale ak je dobre navrhnutá a riadená, stáva sa mocným nástrojom na škálovanie organizácií, tímov a systémov. Využitím vzorov, ako sú Database per Microservice, Saga, API Gateway, CQRS, Clean Architecture, kontajnerové nasadenia a robustné platformy pozorovateľnosti, je možné vytvárať riešenia, ktoré kombinujú rýchle zmeny, odolnosť voči zlyhaniam, technologickú slobodu a oveľa presnejšie zosúladenie s podnikaním , za predpokladu, že sa akceptujú dodatočné náklady na zložitosť a investuje sa do automatizácie, kultúry a osvedčených postupov.