Od monolitů k mikroservisům
Mikroservisy představují architektonický styl, ve kterém je aplikace složena z malých, samostatně nasaditelných služeb, které mezi sebou komunikují přes síť pomocí jasně definovaných rozhraní. Každá služba implementuje úzkou, dobře ohraničenou byznysovou schopnost a je nezávislá z hlediska vývoje, nasazení, škálování i volby technologií. Tento přístup kontrastuje s monolitem, kde je veškerá systémová logika, data i uživatelské rozhraní zabaleno do jednoho spustitelného artefaktu a nasazováno jako celek.
Proč monolity dlouhou dobu dominovaly a kde narážejí
- Jednodušší start: jednotný repozitář, jednotné testy, „jeden build – jedno nasazení“.
- Silná konzistence v rámci jednoho procesu (transakce, sdílené objekty, společné knihovny).
- Limity růstu: těžkopádné releasy, pomalé buildy, vysoká míra vzájemných závislostí, obtížné škálování jen vybrané části systému.
- Organizační překážky: mnoho týmů zasahuje do téže codebase; fronty na releasy, konflikty priorit, „big bang“ integrace.
Definice mikroservisů a klíčové vlastnosti
- Samostatné nasazení: každá služba je verzována, sestavována a nasazována nezávisle.
- Byznysově orientované rozhraní: API popisuje doménové schopnosti, nikoli tabulky či interní objekty.
- Vlastnictví dat: každá služba má své úložiště (polyglot persistence); žádné sdílené databázové schéma mezi službami.
- Izolace poruch: chyba v jedné službě nevyřadí celý systém.
- Nezávislé škálování: služby se škálují podle vlastní zátěže, nikoli podle největšího společného jmenovatele.
Proč mikroservisy v mnoha případech nahradily monolity
- Rychlost změn: menší codebase na tým, kratší doba mezi změnou a nasazením, možnost deployovat několikrát denně.
- Organizační sladění: Conwayův zákon – týmy vytvářejí služby, které odrážejí jejich komunikační struktury; vlastnictví od nápadu po provoz (you build it, you run it).
- Technologická volnost: každá služba může zvolit nejlepší nástroj (programovací jazyk, framework, databázi) pro daný problém.
- Odolnost a škálování: horizontální škálování jen tam, kde je potřeba; graceful degradation při dílčích výpadcích.
Doménový návrh a hranice služeb
Základem kvalitního dělení je Domain-Driven Design (DDD). Systém rozdělujeme podle bounded contexts – relativně autonomních oblastí byznysu s vlastními modely a terminologií.
- Heuristiky rozdělení: vysoká koheze uvnitř kontextu, nízké vazby ven; stabilní API na rozhraní; rozdílné tempo změn.
- Antipattern: dělení podle vrstev (UI/Service/DB) vede k mini-monolitům a těsným vazbám.
- Kontrakty: explicitní API (REST/JSON, gRPC, GraphQL), schémata a verzování (SemVer), consumer-driven contract testing.
Komunikace: synchronní vs. asynchronní
- Synchronní (HTTP/gRPC): jednoduchá integrace, přímé dotazy; riziko kaskádových timeoutů – nutné circuit breaker, timeouts, retries s exponential backoff, bulkhead.
- Asynchronní (události, message broker): volné vazby, lepší odolnost a škálování; vyžaduje idempotenci, deduplikaci, outbox a exactly-once doručování není bez kompromisů.
- Event-driven architektura: služby publikují doménové události (OrderPlaced), ostatní na ně reagují; snižuje potřebu orchestrátorů.
Konzistence dat: od ACID ke konečné konzistenci
V distribuovaném systému není možné spoléhat na transakce napříč službami. Namísto toho:
- Sagy: choreografie (reakce na události) nebo orchestrace (centrální koordinátor) s kompenzačními kroky.
- Outbox pattern: atomické zapsání změny a události do lokální databáze, následná spolehlivá publikace událostí.
- Read modely: materializované pohledy pro rychlé čtení, CQRS pro oddělení zápisu a čtení dat.
API Gateway, BFF a edge
- API Gateway: jednotný vstup do systému, autentizace/autorizace, omezení rychlosti (rate limiting), směrování, observabilita, transformace dat.
- Backend for Frontend (BFF): specializované API pro různé klienty (web/mobil), snižuje nadměrnou komunikaci a složitost v uživatelském rozhraní.
- GraphQL / agregace: vhodné pro složité dotazy napříč službami (nutnost dávat pozor na N+1 problém a latenci).
Observabilita a provoz
- Logy: strukturované (JSON), korelační a trace ID propagované přes všechny služby.
- Metriky: golden signals (latence, chybovost, provoz, saturace), byznysové metriky (např. úspěšnost objednávek).
- Tracing: distribuované trasování (W3C Trace Context, OpenTelemetry), vizualizace závislostí a latencí.
Odolnost a řízení selhání
- Circuit breaker a bulkhead izolují chyby, timeouts a retries s exponenciálním backoffem a náhodným rozhozením (jitter).
- Rate limiting, queueing, load shedding a hedged requests pro řízení špiček zátěže.
- Chaos engineering a game days slouží k ověření připravenosti systému na výpadky.
Bezpečnost: zero-trust a řízení identity
- mTLS mezi službami, rotace certifikátů, service identity (SPIFFE/SPIRE) a krátkodobé tokeny.
- Least privilege u API i databází, ABAC/RBAC, policy-as-code (OPA).
- Supply chain: podepisované imagy, SBOM, skeny zranitelností, izolace tajemství (KMS/Secrets manažery).
Nasazení, škálování a runtime
- Kontejnery a orchestrátor (např. Kubernetes): deklarativní nasazení, autoscaling (HPA/VPA), rolling/canary releasy, kontrola způsobilosti (readiness/liveness probe).
- Service mesh (Istio, Linkerd): jednotná observabilita, TLS, síťová politika bez úprav aplikačního kódu.
- CI/CD: pipeline s testy, bezpečnostními kontrolami, feature flags a rychlou rollback strategií.
Testování v mikroservisním prostředí
- Kontraktní testy: zabraňují skrytým breaking změnám API.
- Integrační a end-to-end testy: selektivní pokrytí kritických toků; plné e2e testy jsou náročné a často nahrazovány syntetickými testy a shadow traffic.
- Správa testovacích dat: deterministická data, seedování, izolace testovacích prostředí.
Data a persistence: vlastnictví a polyglotní přístup
- Každá služba vlastní své schéma a publikuje změny prostřednictvím API nebo událostí, ne přes přímý přístup do cizí databáze.
- Polyglot persistence: volba typu uložiště podle domény (relační databáze, dokumentové úložiště, časové řady, grafové databáze).
- Migrace: migrations-as-code, strategie expand & contract, blue-green deployment pro rizikové změny.
Verzování a kompatibilita
- Zachování zpětné kompatibility jako základní požadavek; tolerantní čtenář na straně klienta.
- Schema registry a validace (OpenAPI/JSON Schema/Protobuf); řízené odstraňování podporovaných verzí s metrikami jejich využití.
Organizační model a řízení (governance)
- Platformový tým poskytuje CI/CD infrastrukturu, observabilitu, šablony a základní bezpečnostní standardy.
- Produktové týmy vlastní služby end-to-end (kód, infrastrukturu, SLO), s jasně definovanými zodpovědnostmi.
- Lehká governance: katalog služeb, standardy telemetrie, bezpečnostní politiky, přitom svoboda volby uvnitř stanovených rámců.
Migrační strategie z monolitu
- Strangler Fig: kolem monolitu vzniká nová fasáda, postupně se jednotlivé schopnosti vyřezávají do samostatných služeb.
- Oddělení dat: anti-corruption layer, replikace nebo streamování změn (CDC), postupné vyřazování tabulek z monolitu.
- Prioritizace podle hodnoty: začít u oblastí s častými změnami, problémy se škálováním či nutností inovací.
Antipatterny a časté chyby
- Distribuovaný monolit: mnoho služeb s těsnými vazbami, koordinované releasy, sdílená databáze – ztráta výhod mikroservisů a nárůst složitosti.
- Předčasná granularita: příliš malá zrna zvyšují režii, latenci a náročnost koordinace.
- Chybějící observabilita a řízení chyb vedou k obtížné diagnostice a dlouhému MTTR (mean time to recovery).
- Nejasné doménové hranice: „vyteklé“ modely a křehká API.
Náklady a kompromisy
- Provozní komplexita: více artefaktů, více běhů služeb, vyšší nároky na SRE a platformní tým.
- Latence: síťová komunikace, serializace, více skoků mezi službami – vyžaduje optimalizaci toků a cachování.
- Bezpečnostní plocha: více hranic a více tajemství – vyžaduje silnější bezpečnostní standardy a automatizaci.
Best practices pro úspěšné mikroservisy
- Začněte s DDD a mapou bounded contexts; vyhněte se technickému dělení.
- Prosazujte event-driven integrace, idempotenci a outbox pro spolehlivost.
- Standardizujte telemetrii (logy, metriky, trasování) a security baseline (mTLS, správa tajemství, bezpečnostní politiky).
- Automatizujte CI/CD a platformní nástroje (šablony, golden paths); zkraťte lead time bez kompromisů na kvalitě.
- Definujte SLO/SLI a používejte error budgets pro řízení rychlosti změn.
Závěr: kdy (ne)volit mikroservisy
Mikroservisy přinášejí rychlejší inovace, nezávislé škálování a vyšší odolnost, avšak za cenu vyšší distribuované složitosti. Jsou vhodné pro doménově rozmanité systémy s vícero týmy, potřebou rychlých release cyklů a elastického škálování. Pro malé produkty nebo raná MVP může být efektivnější modulární monolit s jasně definovanými hranicemi a případný následný přechod na mikroservisy podle potřeby růstu. Správně aplikovaná mikroservisní architektura – založená na DDD, eventech, silných provozních standardech a kultuře you build it, you run it – představuje robustní základ pro dlouhodobě udržitelné a škálovatelné systémy.
