Návrh mikroservisní architektury

Cíle a rozhodovací rámec

Mikroservisní infrastruktura poskytuje nezávisle nasaditelné, škálovatelné a doménově orientované služby propojené přes síť. Cílem je urychlit změny, zvýšit odolnost a umožnit autonomii týmů. Před zahájením definujte: obchodní cíle, nefunkční požadavky (SLO, latence, dostupnost, náklady), regulační omezení a rozpočtová/kompetenční rizika. Mikroservisy nejsou dogma – uplatněte je tam, kde monolit narazí na limity organizace, doménové složitosti nebo škálování.

Doménové vymezení a hranice služeb

• Domain-Driven Design (DDD): identifikujte bounded contexts a mapujte je na služby. Jedna služba = jedna jasná business capability.
• Koheznost a coupling: maximalizujte vnitřní soudržnost (cohesion), minimalizujte mezi-službové vazby. Vyhněte se entity services bez jasné obchodní logiky.
• Granularita: příliš jemné služby zvyšují latenci a provozní zátěž; začněte se hrubšími hranicemi a až poté je případně štěpte.
• Vlastnictví dat: každá služba vlastní svůj datový model a úložiště; nesdílejte databázové schéma napříč službami.

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

• Synchronní API (REST/gRPC): jednoduchý vzor dotaz–odpověď, vhodný pro čtení a krátké operace. Dávejte pozor na řetězení volání a problém n+1 závislostí.
• Asynchronní messaging (události, fronty, streamy): Kafka/Pulsar/RabbitMQ pro volnou vazbu, škálovatelnost a odolnost. Umožňuje event-driven integraci a choreografii procesů.
• Orchestrace vs. choreografie: složité workflow řešte buď centrálním orchestrátorem (Camunda/Temporal) nebo distribuovanou choreografií (sagy pomocí událostí). Volba závisí na auditovatelnosti a složitosti kompenzačních akcí.

API návrh, verze a smlouvy

• Kontrakt-first: OpenAPI/AsyncAPI/Protobuf jako zdroj pravdy, generování klientů a stubů.
• Verzování: v1/v2 nebo schémata v hlavičkách; u událostí verzujte schema registry (např. Avro/JSON Schema) a preferujte kompatibilní změny.
• Stabilita smluv: přidávání polí je obvykle kompatibilní; odstraňování nebo změna typu vyžaduje novou verzi.
• API Gateway: centralizuje autentizaci, omezení rychlosti (throttling), agregaci, canary směrování a backends for frontends (BFF).

Data, konzistence a transakce

• Polyglot persistence: volba úložiště dle charakteru domény (relační/NoSQL/time-series/search).
• Eventuální konzistence: akceptujte, že ne vše bývá silně konzistentní. Publikujte domain events po potvrzení lokální transakce.
• Sagy: distribuované transakce řešte kompenzačními akcemi. Každý krok musí být idempotentní a opakovatelný.
• Outbox pattern: zapisujte události do tabulky outbox a spolehlivě je přenášejte do brokera (transakční outbox + CDC).

Odolnost a řízení chyb

• Idempotence a at-least-once doručení: používejte idempotentní klíče a deduplikaci na spotřebiteli.
• Timeouty, retry s backoffem a jitterem: nastavte rozumné limity; rozlišujte retriable a non-retriable chyby.
• Circuit breaker a bulkhead: izolujte zdroje; zabráníte kaskádovým selháním.
• Omezení rychlosti a zpětný tlak (backpressure): chraňte upstream systémy a udržujte stabilitu během špiček.

Bezpečnost a řízení přístupu

• Identita a federace: OIDC/OAuth 2.1 pro uživatele; SPIFFE/SPIRE/SVID pro identitu služeb a mTLS.
• Autorizace: RBAC/ABAC nebo centrální policy engine (OPA) s policy-as-code.
• Šifrování: TLS 1.3 v síti, šifrování dat v klidu; rotace klíčů v KMS/HSM, tajemství mimo image (Secrets).
• Zero trust: explicitní povolení komunikace (network policies), žádná implicitní důvěra uvnitř clusteru.

Service Mesh a síťová vrstva

• Service discovery a load-balancing: DNS/Envoy/Consul. Objevování endpointů a L7 směrování s observabilitou.
• Service mesh (Istio/Linkerd): jednotné mTLS, traffic shaping (canary, mirroring), retries, timeouts, circuit breaking bez úprav v kódu.
• Network policies: segmentace komunikace mezi jmennými prostory a službami.

Observabilita: logy, metriky a trasování

• Metriky: RED (Rate, Errors, Duration) pro API, USE (Utilization, Saturation, Errors) pro infrastrukturu. Export do Promethea; SLO/SLI definované na úrovni domén.
• Distribuované trasování: OpenTelemetry → backend (Jaeger/Tempo/Zipkin); korelační ID přenášejte mezi službami.
• Logy: strukturovaný JSON, jednotné pole traceId/spanId, zákaz citlivých dat; centralizace (ELK/Vector/Fluent Bit).
• Alerting: na porušení SLO (error budget), nikoliv na šum. Runbooky a auto-remediace.

CI/CD a řízení releasů

• Pipelines: lint → jednotkové/integrace → kontraktové testy → build image → SCA/scan → podpis → deployment.
• Strategie: blue/green, canary, progressive delivery (Argo Rollouts/Flagger). Feature flags pro řízené aktivování funkcí.
• Prostředí: dev/test/stage/prod, izolace tajemství a konfigurací; GitOps (Argo CD/Flux) jako jediný zdroj pravdy.

Platforma: kontejnery, orchestrace a runtime

• Kubernetes jako standardní orchestrátor: Deployment/StatefulSet, Services, Ingress/Gateway API, HPA/VPA, PodDisruptionBudget.
• Konfigurace a tajemství: ConfigMap/Secrets, encrypt at rest, sealed secrets; hierarchická konfigurace podle prostředí.
• Zdrojové limity: requests/limits, QoS třídy; optimalizujte CPU/RAM pro JIT jazyky (warmup, jemné GC).
• Persistentní data: CSI drivery, zálohovací operátory; pro DB zvažte spravované služby (RDS/CloudSQL) vs. vlastní operátory (postgres-operator).

Správa schémat a verzí dat

• Schema registry: kontrola kompatibility (backward/forward).
• Migrace databází: migrátory (Flyway/Liquibase) s expand/contract strategií.
• Event sourcing & CQRS: pro složitá doménová pravidla a auditovatelnost; počítejte s náklady na projekce a re-play.

Testování v mikroservisním světě

• Contract testing: spotřebitel vs. poskytovatel (Pact), zabraňuje rozbití integrace.
• Testcontainers: integrační testy proti reálným závislostem v kontejnerech.
• Chaos engineering: simulace výpadků uzlů, zpoždění, ztráty paketů; ověřte odolnost vůči částečným poruchám.
• Zatížení a kapacita: sledujte p95/p99 latenci, saturaci vláken, fronty a backpressure.

Edge vrstva a caching

• API Gateway / Ingress: autentizace, WAF, rate-limit, transformace požadavků/odpovědí, geo a canary routing.
• Cache: CDN/edge cache pro statický obsah; aplikační cache (Redis) pro hot path; invalidace řízená událostmi.
• Content negotiation a komprese: Gzip/Brotli na edge; preferujte HTTP/2/3.

Monitoring nákladů a efektivity

• Cost observability: přiřazujte náklady ke službám (štítky/annotace), sledujte náklady na request/tenant.
• Optimalizace: správné dimenzování podů, autoscaling dle metrik domény (hloubka front), vypínání nevyužívaných prostředí.

Více tenantů a izolace

• Model multi-tenancy: shared-nothing (izolované instance), shared-with-guards (tenant ID v datech + row-level security) nebo hybridní model.
• Izolace rizik: rate-limit na tenant, kvóty, oddělené fronty/partitiony pro prioritizaci.

Compliance, audit a správa dat

• Audit logy: kdo/co/kdy, neměnitelné úložiště (WORM); korelace s trasami.
• Privacy-by-design: minimalizace dat, šifrování, retention dat, mazání na vyžádání (GDPR a ekvivalenty).
• SBOM a supply-chain: podpisy imagí (cosign), skenování zranitelností (Trivy), politiky nasazení (OPA/Gatekeeper).

Organizační model a provoz

• „You build it, you run it“: tým vlastní službu end-to-end (kód, infrastrukturu, alerty, náklady).
• Platform engineering: poskytuje samoobslužné zlaté cesty (CI/CD šablony, observabilita, runtime) a katalog služeb.
• Runbooky a SRE: definujte SLO, error budgety, postupy incident response, postmortemy bez obviňování.

Checklist návrhu mikroservisní infrastruktury

• Jasně definované bounded contexts a vlastnictví dat každé služby.
• Kontrakt-first API, verzování a schema registry pro události.
• Asynchronní integrace pro cross-doménové toky, outbox + sagy.
• Idempotence, retry/backoff, circuit breaker, rate-limit.
• mTLS, OIDC, centralizovaná autorizace, správa tajemství v KMS.
• Observabilita: metriky RED/USE, trace, strukturované logy, SLO/SLI.
• Kubernetes s GitOps, limity/requests, PDB, autoscaling.
• CI/CD s canary/blue-green, podpis imagí, SCA/DAST v pipeline.
• Edge: API Gateway, WAF, caching, traffic shaping.
• Compliance: audit logy, retention, SBOM, politiky nasazení.

Závěr

Návrh mikroservisní infrastruktury je kombinací správně vymezených domén, robustních integračních vzorů, bezpečné a pozorovatelné platformy a disciplinovaných týmových praktik. Úspěch spočívá v koherentních hranicích, asynchronní komunikaci, automatizovaném a bezpečném provozu a měřitelných cílech spolehlivosti. Začněte jednoduchými hranicemi, investujte do platformy a observability a evolučně iterujte dle skutečných potřeb domény a uživatelů.