Mikroservisní architektura: principy a distribuované systémy

Co je mikroservisní architektura a kdy dává smysl

Mikroservisní architektura je přístup k návrhu softwaru, který rozděluje aplikaci do sady malých, samostatně nasaditelných služeb. Každá služba je organizována kolem obchodní schopnosti, má jasně definované rozhraní (typicky události HTTP/gRPC) a odpovídá za vlastní data. Cílem je zrychlit dodávání změn, umožnit nezávislé škálování, omezit kaskádové výpadky a sladit strukturu systému se strukturou týmů (Conwayův zákon).

Mikroservisy dávají smysl, pokud máte rychle rostoucí produkt, mnoho týmů, potřebu používat různé technologie a odlišné požadavky na škálování. Naopak u menšího produktu s jedním týmem bývá pragmatičtější modulární monolit s jasně vymezenými hranicemi a možností pozdějšího rozdělení.

Doménový návrh a rozdělení systému

Ohraničené kontexty (DDD): slaďte hranice služeb s jazykem domény; předejdete tak příliš časté komunikaci a nejasnému rozdělení odpovědností.
Obchodní schopnosti: jedna služba = jedna schopnost (např. platby, katalog, doporučování), nikoli „technická vrstva“.
Tok hodnoty: mapujte scénáře od začátku do konce (objednávka → platba → expedice) a minimalizujte synchronní závislosti.
Antivzor: sdílená databáze napříč službami – vede k těsnému provázání a ztrátě autonomie.

Komunikační styly: synchronní a asynchronní

Synchronní (HTTP/gRPC): jednoduchá komunikace, vhodná pro dotazy (queries); vyžaduje nastavení časových limitů, opakování požadavků s exponenciálním prodlužováním prodlevy a circuit breaker.
Asynchronní (události, fronty, streamy): Kafka, RabbitMQ, NATS. Umožňuje volnější provázání, vyšší propustnost a přirozenou škálovatelnost. Vhodné pro integrace řízené událostmi (event-driven).
Transakční model: počítejte s eventual consistency, používejte idempotenci, deduplikaci a outbox pattern.

Gateway, směrování a service mesh

API Gateway: jedno vstupní místo pro klienty (omezení počtu požadavků, autentizace/autorizace, TLS, transformace, agregace).
BFF (Backend for Frontend): samostatné brány pro web a mobilní zařízení, které omezují příliš častou komunikaci a přizpůsobují formát dat.
Service Mesh: proxy typu sidecar (např. Envoy) pro mTLS, řízení provozu, pravidla pro opakování požadavků a časové limity, circuit breaking a observabilitu bez změn aplikačního kódu.

Data v mikroservisech: autonomie a konzistence

Datová autonomie: každá služba vlastní své úložiště (SQL/NoSQL/vyhledávací systém/cache); ostatní služby k němu přistupují prostřednictvím API nebo událostí.
Transakce napříč službami: Saga pattern (choreografie nebo orchestrace) s kompenzačními kroky.
Schémata a jejich vývoj: verzování kontraktů (semver), schema registry pro události (Avro/JSON Schema/Protobuf), zpětná a dopředná kompatibilita.
Dotazy napříč hranicemi: API composition, CQRS, materializované pohledy a read models.

Spolehlivost a odolnost

Časové limity a opakování požadavků: vždy je definujte; použijte exponenciální prodlužování prodlevy a náhodnou složku (jitter), vyhněte se nárazovému přetížení systému („thundering herd“).
Circuit Breaker: izolujte poruchy, reagujte rychlým selháním (fail-fast) a využívejte záložní řešení.
Bulkheads a omezení zátěže: oddělujte zdroje (fondy vláken, spojení) a upřednostňujte kritické cesty.
Backpressure: u streamů a front kontrolujte tempo příjmu.
Cache a omezení počtu požadavků: snižte latenci a zatížení; zohledněte konzistenci a invalidaci.

Bezpečnost a správa tajemství

Zero-Trust: ověřujte každou komunikaci, používejte mTLS mezi službami a krátkodobé certifikáty.
Autentizace/autorizace: OAuth 2.1/OIDC, tokeny (JWT/PASETO), jemnozrnná pravidla (OPA/ABAC/RBAC).
Správa tajemství: trezory (Vault), rotace klíčů; tajemství nikdy neukládejte do repozitáře.
Bezpečnost dodavatelského řetězce: podepisování artefaktů (SLSA, Sigstore), SBOM, skenování závislostí a kontejnerů.

Observabilita: logy, metriky, trasování

Metriky: RED/USE, SLI/SLO a chybové rozpočty; standardizace metrik (OpenMetrics).
Distribuované trasování: korelační ID (W3C Trace Context), vzorkování, vizualizace kritických cest.
Logy: strukturované (JSON), korelované s trasami, s ohledem na ochranu osobních údajů (PII), centralizované a s definovanou retenční politikou.
Upozorňování: užitečné a akční, s provozními příručkami a pohotovostní službou SRE.

Nasazení, škálování a platforma

Kontejnery: neměnné image, vícestupňové sestavení, minimální základní image.
Orchestrace: Kubernetes nebo spravovaná platforma; readiness/liveness pro kontroly stavu, horizontální automatické škálování.
CI/CD: vývoj založený na hlavní větvi (trunk-based), automatizované testy, postupné nasazování (progressive delivery; canary, blue-green), příznaky funkcí.
IaC: deklarativní infrastruktura (Terraform/Helm), pravidla definovaná jako kód (policy-as-code).

Testování v mikroservisech

Jednotkové a komponentové testy: rychlá zpětná vazba.
Testování kontraktů: řízené potřebami konzumentů (consumer-driven) (Pact); chrání před regresními chybami mezi službami.
Integrační a E2E testy: pouze pro klíčové scénáře, aby nebrzdily nasazování.
Chaos engineering: simulujte poruchy (síť, latence, výpadky) a sledujte chování systému.

Organizace a týmy

Team Topologies: týmy zaměřené na konkrétní obchodní proudy, platformní tým a podpůrný (enabling) tým pro osvědčené postupy a bezpečnost.
„You build it, you run it“: odpovědnost za službu od začátku do konce, včetně metrik kvality a nákladů.
Governance: pouze nezbytná pravidla (konvence API, telemetrie, bezpečnost), osvědčené postupy (golden paths) a šablony.

Antivzory a časté pasti

Distribuovaný monolit: mnoho služeb, ale těsně provázaných (sdílená databáze, společná vydání) – složitost bez přínosů.
Nanoslužby: příliš malé služby, vysoká režie spojená se sítí a koordinací.
Příliš častá komunikace: příliš mnoho synchronních volání v rámci jedné transakce – řešením je agregace, BFF a události.
Předčasné škálování: rozdělení bez jasně vymezené domény a připraveného týmu – zpomalení vývoje.

Migrace z monolitu: strategie „bez bolesti“

Strangler Fig: postupné obalování monolitu pomocí API/proxy a vyčleňování domén po částech.
Vyčleňování podle přínosu: začněte tam, kde je jasný přínos (nezávislé škálování, rychlejší změny).
Migrace dat: dual-write s outboxem, streamy pro doplnění historických dat (backfill), ověřování konzistence.
Paralelní provoz: dočasná dvojí implementace kritických endpointů a nasazení ve stínovém režimu.

Výkonnost a náklady

Rozpočet na latenci: počítejte se síťovými skoky; optimalizujte kritické cesty (agregace, cache, asynchronní reakce).
Provozní náklady: více komponent znamená více práce s observabilitou, bezpečností a platformou; zvažte návratnost.
Škálování podle profilu: zátěžově náročné na I/O vs. zátěžově náročné na CPU; samostatné plány pro databáze, fronty a cache.

Referenční architektura (příklad)

Klient (web/mobilní zařízení) → API Gateway/BFF → mikroservisy (Katalog, Košík, Platby, Doprava) → vlastní databáze (PostgreSQL, Redis, Elastic).
Event bus (Kafka): události OrderPlaced, PaymentCaptured, ShipmentCreated pro choreografii.
Service mesh: mTLS, pravidla pro opakování požadavků a časové limity, směrování canary.
Observabilita: metriky + trasování + logy konsolidované na jednom panelu se SLO.
CI/CD: pipeline s testy, testy kontraktů, skenováním, canary nasazením a automatickým návratem k předchozí verzi.

Kontrolní seznam pro úspěšné mikroservisy

Hranice služeb podle obchodních schopností a ohraničených kontextů.
Asynchronní integrace všude, kde je to možné; synchronní volání minimalizujte.
Vlastnictví dat na úrovni služeb; žádná sdílená schémata.
Standardizovaná observabilita a bezpečnost (mTLS, OAuth/OIDC, OPA).
Automatizované CI/CD, postupné nasazování, IaC a pravidla definovaná jako kód.
Testování kontraktů a řízený vývoj schémat/událostí.
Vzory odolnosti: časové limity, opakování požadavků, circuit breaker, bulkheads, backpressure.
Platformní tým a osvědčené postupy (golden paths) pro zvýšení produktivity vývojářů.
Pravidelné provozní revize a SLO s chybovými rozpočty.

Závěr

Mikroservisní architektura není cílem sama o sobě, ale prostředkem, jak urychlit dodávky, omezit rizika změn a škálovat organizaci. Funguje tehdy, když hranice odpovídají doméně, data jsou autonomní, komunikace je převážně asynchronní, infrastruktura je automatizovaná a týmy nesou odpovědnost od začátku do konce. Pokud tyto principy dodržíte, získáte systém, který se přizpůsobuje potřebám podnikání – ne naopak.