Slovník pojmů

Mikroservisní architektura

Samostatné deploymenty mohou oddělit změny a škálování částí systému. Zároveň mění obyčejná volání metod na distribuovanou komunikaci s latencí, výpadky a složitější konzistencí.

Stručná definice

Hranici služby určuje schopnost systému, ne počet řádků.

Mikroservisa je samostatně nasaditelná služba, která poskytuje ucelenou schopnost a skrývá svou vnitřní implementaci za kontraktem. Její velikost se neposuzuje podle počtu tříd nebo řádků, ale podle odpovědnosti, autonomie změn a toho, zda ji tým dokáže bezpečně vlastnit od vývoje po provoz.

Mikroservisní architektura je vlastnost celého systému a organizace práce. Nestačí rozdělit jeden proces na malé moduly, spustit je v kontejnerech nebo ke každému přidat HTTP endpoint. Smysluplné hranice vycházejí z domény, změn, odpovědnosti týmu a provozních potřeb.

Jaký problém řeší

Části velkého systému se mohou měnit a provozovat různým tempem.

Přístup může pomoci, když jeden celek brzdí nezávislé týmy nebo když určité schopnosti mají výrazně odlišné nároky na nasazování, dostupnost a škálování.

samostatné nasazení katalogu bez vydání celého objednávkového systému
oddělené škálování čtení produktů a zpracování plateb
jasné vlastnictví služby týmem, který řeší její kód, data, deployment i incidenty
izolace změn a některých výpadků za podmínky, že volající umějí degradovat
postupná náhrada vymezené schopnosti bez jednorázového přepsání celého systému

Praktický příklad

Objednávka ve větší e-commerce platformě

Platforma může mít samostatnou službu Katalog pro produkty, Order Service pro objednávky, Payment Service pro platby a Inventory Service pro sklad. Hranice nevzniknou prostým rozdělením tabulek: Order Service vlastní pravidla objednávky, Payment Service průběh platby a Inventory Service rezervaci fyzických zásob. Každou službu spravuje tým, který zná její kontrakt i provoz.

API může synchronně ověřit údaje, které musí uživatel znát hned. Po lokálním uložení objednávky Order Service publikuje událost OrderCreated přes frontu zpráv. Inventory Service ji přijme, idempotentně vytvoří rezervaci a publikuje výsledek. Pokud sklad nestačí, systém potřebuje explicitní stav a kompenzační postup; jedna databázová transakce přes obě služby obvykle není k dispozici.

Textový diagram a jeho alternativa

Frontend
  → API gateway (volitelná)
    → Order Service ──sync API──→ Payment Service
           │
           └── OrderCreated event ──→ Inventory Service

Každá služba: vlastní kontrakt, datová hranice, deployment a monitoring

Jak funguje

Od požadavku přes lokální změny k distribuovanému výsledku

Tok je textovou alternativou diagramu. API gateway je možný vstup, nikoliv povinná podmínka mikroservisní architektury.

Vstup do systému Frontend zavolá přímo veřejnou službu nebo volitelnou API gateway, která řeší routing a vybrané průřezové technické úlohy. Nemá se stát místem doménových pravidel.
Lokální rozhodnutí Order Service ověří požadavek, provede vlastní pravidla a uloží změnu atomicky ve své datové hranici.
Synchronní komunikace HTTP, gRPC nebo jiný request–response protokol se hodí, když je bezprostředně potřeba odpověď. Volající ale musí počítat s timeoutem, latencí a nedostupností protistrany.
Asynchronní komunikace RabbitMQ nebo jiný broker může předat událost bez čekání na dokončení navazující práce. Opakované doručení, pořadí a chybové toky vyžadují vlastní návrh.
Dosažení výsledného stavu Služby potvrzují lokální kroky v různých časech. Systém proto sleduje průběžný stav, opakování, kompenzace a případnou výslednou konzistenci (eventual consistency) místo předstírání jedné okamžité transakce.

Hlavní části a principy

Autonomie vzniká společně s kontraktem, daty a provozem.

Samostatný repozitář ani kontejner službu sám nevytvoří. Hranice má umožnit změnu jedné schopnosti bez koordinovaného vydání mnoha dalších částí.

Hranice služby

Domain-Driven Design může pomoci rozlišit bounded contexty a schopnosti, které se mění společně. Bounded context ale není automaticky mikroservisa; může zůstat modulem jednoho nasazovaného systému.

Kontrakt komunikace

Služba skrývá interní třídy a databázové schéma za verzovaným API nebo schématem zpráv. REST API je jeden možný styl rozhraní, nikoli definice mikroservisy.

Data a jejich vlastnictví

Služba má být autoritou pro své schéma a zápisy. Database per service je častý princip logického oddělení, ne příkaz kupovat pro každou službu vlastní fyzický databázový server; oddělená schémata či instance závisí na riziku a provozu.

Deployment a ownership

Nezávislé vydání vyžaduje kompatibilní kontrakty, automatizované ověření, rollback a odpovědnost týmu za službu v produkci. Každá služba nemusí používat jiný jazyk a technologická pestrost má vlastní cenu.

Service discovery a směrování

V dynamickém prostředí musí volající najít zdravou instanci služby. DNS, orchestrátor nebo registry mohou discovery zajistit; nejde o businessovou hranici ani povinný vlastní produkt.

Observabilita

Centralizované logy, metriky a korelační identifikátory skládají jeden uživatelský tok napříč službami. Distribuované trasování (tracing) ukazuje průchod požadavku a latenci mezi službami; bez observability se incident mění v hádání mezi procesy.

Výhody a omezení

Nezávislost části systému se platí distribuovanou složitostí.

Možné přínosy

nezávislé nasazení a škálování skutečně oddělených schopností
jasnější ownership kódu, dat, provozu a incidentů pro jednotlivé týmy
omezení rozsahu některých změn a výpadků při správně navržené odolnosti
možnost použít odlišnou technologii tam, kde pro ni existuje konkrétní důvod

Omezení a časté chyby

síťové volání může selhat, být pomalé nebo skončit neznámým výsledkem
řetězec synchronních volání zvyšuje latenci a riziko kaskádového výpadku
změny přes více služeb nemají jednoduchou společnou databázovou transakci
příliš jemné hranice vedou k mnoha drobným síťovým voláním a společným deploymentům
více pipeline, prostředí, tajemství, alarmů a on-call odpovědností zvyšuje provozní náklady
sdílená databáze nebo knihovna může skrytě svázat služby navzdory jejich samostatným názvům

Mikroservisy, monolit a ostatní přístupy

Dobře strukturovaný monolit je často vhodnější výchozí bod.

Modulární monolit má oddělené moduly a jasná interní rozhraní, ale nasazuje se jako jeden celek a může používat jednu lokální transakci. Pro menší tým, neustálenou doménu, běžné zatížení nebo systém bez samostatných provozních potřeb bývá jednodušší vyvíjet, testovat, ladit i provozovat. Hranice lze později oddělit, pokud se pro nezávislý deployment objeví prokazatelný důvod.

Docker je možná deployment technologie, ne architektonický důkaz: jeden monolit může běžet v kontejneru a jedna mikroservisa může běžet bez něj. Také malá třída či modul uvnitř procesu není mikroservisa, protože nemá vlastní síťový kontrakt a samostatný životní cyklus nasazení.

Clean Architecture řeší směr závislostí uvnitř aplikace, zatímco mikroservisní architektura rozděluje nasazovaný systém. Lze je kombinovat, ale žádný z přístupů není podmínkou druhého. SOA je širší rodina návrhů kolem služeb; mikroservisy obvykle zdůrazňují jemnější doménové hranice, autonomní týmy a nezávislé deploymenty, přesná hranice názvů však není univerzální norma.

Odolnost a provoz

Každá síťová hranice potřebuje plán pro částečné selhání.

Úspěšný provoz závisí stejně na organizaci, automatizaci a diagnostice jako na samotném rozdělení kódu.

definovat timeouty, omezený retry a circuit breaker podle typu operace
použít korelační ID, centralizované logy, metriky, alerty a tracing důležitých toků
navrhnout asynchronní konzumenty s idempotencí a dohledatelným stavem zpracování
držet lokální databázové transakce uvnitř jedné služby a přes hranice modelovat výslednou konzistenci či kompenzace
verzovat kontrakty kompatibilně a ověřovat interakce mezi producenty a konzumenty
sledovat vlastnictví služby, provozní cíle, náklady a postup obnovy po výpadku
vyhodnocovat, zda hranice stále snižuje koordinaci, nebo ji pouze přesunula do sítě

Časté otázky

Mikroservisy bez technologických zkratek

Jsou mikroservisy automaticky lepší než monolit?

Ne. Přinášejí smysl, když nezávislé nasazení, škálování a ownership převáží náklady distribuovaného systému. Pro menší tým a neustálenou doménu bývá dobře strukturovaný monolit bezpečnější a levnější.

Musí mít každá mikroservisa vlastní databázový server?

Nemusí. Důležitá je autorita služby nad daty a omezení přímého přístupu ostatních služeb. Fyzická instance, cluster nebo oddělené schéma se volí podle izolace, dostupnosti a provozních nákladů.

Je Docker kontejner mikroservisa?

Ne. Kontejner je způsob zabalení a spuštění procesu. Může obsahovat monolit, worker i mikroservisu; architektonickou hranici a odpovědnost neurčuje.

Musí mikroservisy komunikovat přes REST API?

Ne. Mohou používat synchronní HTTP či gRPC i asynchronní zprávy a události. Volba závisí na potřebě okamžité odpovědi, odolnosti, vazbě a požadované konzistenci.

Jak poznat příliš malé služby?

Varováním jsou mnohá drobná síťová volání, změny vyžadující společné vydání několika služeb, sdílené interní modely a nejasný vlastník. Funkce, které se mění společně, pravděpodobně patří do jedné hranice.

Jak architekturu volím v praxi

Hranice nasazení odděluji jen tam, kde řeší skutečnou potřebu systému a týmu.

Při návrhu zvažuji doménu, konzistenci dat, integrační chyby, observabilitu i provozní kapacitu. Mikroservisa není cíl sama o sobě a dobře strukturovaný monolit zůstává plnohodnotnou volbou.

Zobrazit přístup k architektuře aplikací Nezávazně probrat projekt