Mikroservisní architektura

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 byznysové schopnosti, má jasně definované rozhraní (typicky HTTP/gRPC události) a vlastní odpovědnost za data. Cílem je zrychlit doručová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 heterogenních technologií a rozdílné škálovací profily. Naopak pro menší produkt s jedním týmem je často pragmatičtější modulární monolit s čistými hranicemi a připraveností na pozdější rozřezání.

Doménový návrh a rozřezání systému

• Bounded Contexty (DDD): slaďte hranice služeb s jazykem domény; zamezíte tak chatty komunikaci a „rozteklé“ zodpovědnosti.
• Byznysové schopnosti: jedna služba = jedna schopnost (např. platby, katalog, doporučování), nikoli „technická vrstva“.
• Tok hodnoty: mapujte end-to-end scénáře (objednávka → platba → expedice) a minimalizujte synchronní závislosti.
• Antivzor: sdílená databáze napříč službami – vede k těsnému spojení a krachu autonomie.

Komunikační styly: synchronní vs. asynchronní

• Synchronní (HTTP/gRPC): jednoduché, vhodné pro dotazy (queries), vyžaduje timeouts, retry s exponenciálním backoffem a circuit breaker.
• Asynchronní (eventy, fronty, streamy): Kafka, RabbitMQ, NATS. Umožní volnější vazbu, vyšší propustnost a přirozenou škálovatelnost. Vhodné pro event-driven integrace.
• Transakční model: akceptujte eventual consistency, používejte idempotenci, deduplikaci a outbox pattern.

Gateway, směrování a service mesh

• API Gateway: jedno vstupní místo pro klienty (rate-limit, authn/authz, TLS, transformace, agregace).
• BFF (Backend for Frontend): oddělené brány pro web/mobil, aby se minimalizovala „chatty“ komunikace a formát dat.
• Service Mesh: sidecar proxy (např. Envoy) pro mTLS, traffic-shaping, retry/timeout policy, circuit breaking, observabilitu bez změn aplikačního kódu.

Data v mikroservisech: autonomie a konzistence

• Datová suverenita: každá služba vlastní svůj úložiště (SQL/NoSQL/search/cache); jiné služby přistupují přes API či eventy.
• Transakce napříč službami: Saga pattern (choreografie nebo orchestrace) s kompenzačními kroky.
• Schémata a evoluce: verzování kontraktů (semver), schema registry pro eventy (Avro/JSON Schema/Protobuf), kompatibilita dopředná/zpětná.
• Dotazy napříč hranicemi: API composition, CQRS, materializované pohledy a read models.

Spolehlivost a odolnost

• Time-outs a retry: vždy definujte; exponential backoff + jitter, vyhýbejte se „thundering herd“.
• Circuit Breaker: izolujte poruchy, fail-fast a fallbacky.
• Bulkheads a load shedding: oddělení zdrojů (pooly vláken, spojení), priorita kritických cest.
• Backpressure: u streamů a front kontrolujte tempo příjmu.
• Cache a rate-limit: snižte latence a zatížení; respektujte konzistenci a invalidaci.

Bezpečnost a správa tajemství

• Zero-Trust: ověřujte každou komunikaci, mTLS mezi službami, krátkodobé certifikáty.
• Autentizace/Autorizace: OAuth 2.1/OIDC, tokeny (JWT/PASETO), jemnozrnná pravidla (OPA/ABAC/RBAC).
• Secret management: trezory (Vault), rotace klíčů, nikdy neukládat tajemství v repozitáři.
• Supply-chain: 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), sampling, vizualizace kritických cest.
• Logy: strukturované (JSON), korelace s trasami, PII hygiena, centralizace a retenční politika.
• Alerting: užitečné a akční, runbooky a SRE pohotovosti.

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

• Kontejnery: neměnné image, více fází buildů, minimální základní image.
• Orchestrace: Kubernetes nebo managed platforma; readiness/liveness pro health-checky, horizontální autoscaling.
• CI/CD: trunk-based, automatizované testy, progressive delivery (canary, blue-green), feature flagy.
• IaC: deklarativní infrastruktura (Terraform/Helm), policy-as-code.

Testování v mikroservisech

• Unit a komponentové testy: rychlá zpětná vazba.
• Contract testing: consumer-driven (Pact); chrání proti regresím mezi službami.
• Integrační a E2E: pouze klíčové scénáře, aby se nebrzdil deploy.
• Chaos engineering: injektujte poruchy (síť, latence, výpadky) a sledujte chování.

Organizace a týmy

• Team Topologies: stream-aligned týmy za konkrétní byznysové proudy, platformní tým, enabling tým pro praxi a bezpečnost.
• „You build it, you run it“: vlastnictví služby end-to-end, metriky kvality a nákladů.
• Governance: minimální potřebná pravidla (konvence API, telemetrie, bezpečnost), golden paths a šablony.

Antivzory a časté pasti

• Distribuovaný monolit: mnoho služeb, ale těsně svázaných (sdílená DB, společné releasy) – složitost bez benefitů.
• Nano-servisy: příliš malé, vysoká režie sítí a koordinace.
• Chattiness: příliš mnoho synchronních volání v jedné transakci – řešit agregací, BFF, eventy.
• Předčasné škálování: rozřezání bez doménové jasnosti a týmu – zhoršení rychlosti vývoje.

Migrace z monolitu: strategie „bez bolesti“

• Strangler Fig: postupné obalování monolitu API/Proxy a vyřezávání domén po částech.
• Carve-out podle hodnoty: začněte tam, kde je jasný zisk (nezávislé škálování, rychlejší změny).
• Datová migrace: dual-write s outboxem, backfill streamy, ověřování konzistence.
• Paralelní běh: dočasně dvojí implementace kritických endpointů a stínové nasazení.

Výkonnost a náklady

• Latency budget: počítejte síťové skoky; kritické cesty optimalizujte (agregace, cache, asynchronní reakce).
• Náklady na provoz: více komponent = více observability, bezpečnosti a platformní práce; zvažte návratnost.
• Škálování podle profilu: IO-bound vs. CPU-bound; oddělené plány pro databáze, fronty, cache.

Referenční architektura (příklad)

• Klient (web/mobil) → API Gateway/BFF → microservices (Katalog, Košík, Platby, Doprava) → vlastní DB (PostgreSQL, Redis, Elastic).
• Event bus (Kafka): události OrderPlaced, PaymentCaptured, ShipmentCreated pro choreografii.
• Service mesh: mTLS, retry/timeout policy, canary routing.
• Observabilita: metriky + tracing + logy konsolidované v jednom panelu se SLO.
• CI/CD: pipeline s testy, contract-testy, skenováním, canary deploy a automatickým rollbackem.

Checklist pro úspěšné mikroservisy

1. Hranice služeb podle byznysových schopností a bounded contextů.
2. Asynchronní integrace všude, kde to jde; synchronní volání minimalizovat.
3. Vlastnictví dat na úrovni služby; žádná sdílená schémata.
4. Standardizovaná observabilita a bezpečnost (mTLS, OAuth/OIDC, OPA).
5. Automatizované CI/CD, progressive delivery, IaC a policy-as-code.
6. Contract-testing a řízená evoluce schémat/eventů.
7. Resilience vzory: timeouts, retries, circuit breaker, bulkheads, backpressure.
8. Platformní tým a golden paths pro zvýšení vývojářské produktivity.
9. Pravidelné operational reviews a SLO s chybovými rozpočty.

Závěr

Mikroservisní architektura není cíl sám o sobě, ale prostředek, 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 end-to-end zodpovědnost. Pokud tyto principy dodržíte, získáte systém, který se přizpůsobuje byznysu – ne naopak.