Architektura mikroservis a kontejnerizace: principy

Cloud, virtualizace a architektury
Natália Šimková
Architektura mikroservis a kontejnerizace: Principy

Proč mikroservisy a proč právě teď

Architektura mikroservis rozkládá aplikaci na menší služby, které lze nezávisle nasazovat a škálovat a které spolu komunikují prostřednictvím dobře definovaných rozhraní. V kombinaci s kontejnerizací (OCI image) a orchestrací (Kubernetes) umožňuje rychlé vydávání verzí, nezávislé nasazování, lepší izolaci chyb a efektivní využití zdrojů. Cenou za tuto flexibilitu je komplexita: správa distribuovaného systému, observabilita, spolehlivost sítě a bezpečnost.

Principy mikroservis: hranice, nezávislost a kontrakty

  • Jedna odpovědnost: každá služba se zaměřuje na malou obchodní schopnost (např. „fakturace“), nikoli na technickou vrstvu.
  • Jasně vymezené hranice: kontrakty API jsou explicitní; data vlastní služba (vlastnictví dat) a nesdílejí se na úrovni databáze.
  • Nezávislé nasazování: každá služba má svůj životní cyklus, CI/CD a verzi.
  • Odolnost vůči chybám: standardně se předpokládá selhání sítě i závislostí; implementují se opakované pokusy, časové limity, jističe a izolované oblasti.

Doménový návrh a dekompozice

Mikroservisy by měly odrážet doménové hranice (DDD): ohraničený kontext určuje slovník a pravidla dané domény. Dekompozice „podle databázových tabulek“ vede k těsnému propojení; vhodnější je dělit podle případů užití a toků hodnoty. Klíčové je zvolit správnou granularitu: příliš malé služby zvyšují režijní náklady na provoz, příliš velké omezují přínosy nezávislosti.

Datová vrstva: jedna služba, jeden zdroj pravdy

  • Polyglotní perzistence: každá služba si volí databázi podle potřeby (relační, dokumentovou, pro časové řady nebo grafovou).
  • Integrace dat: místo sdílené databáze používejte události (CDC, protokol změn) a materializované pohledy u konzumentů.
  • Transakční konzistence: vyhýbejte se distribuovanému dvoufázovému potvrzování (2PC); upřednostněte vzorec Saga (choreografii/orchestraci) s kompenzačními kroky.

Komunikace: synchronní vs. asynchronní

  • Synchronní (HTTP/gRPC): vhodná pro komunikaci požadavek–odpověď a nízkou latenci; je nutné definovat časové limity, idempotenci a prodlevy mezi opakovanými pokusy.
  • Asynchronní (sběrnice událostí, streamy): oddělení producentů od konzumentů, vyšší odolnost vůči špičkám; vyžaduje schéma událostí, verzování a fronty odložených zpráv.
  • Nejprve kontrakt: OpenAPI/AsyncAPI/Protobuf jako zdroj pravdy, generování klientů a validátorů.

Kontejnerizace: neměnné artefakty a přenositelnost

  • OCI image: reprodukovatelné sestavení (vícefázové), minimální základní image (distroless, alpine), samostatný uživatel (ne root), kořenový souborový systém pouze pro čtení.
  • Dodavatelský řetězec: SBOM (CycloneDX/SPDX), skenování zranitelností, podepisování image (cosign), doklad o původu z CI.
  • Konfigurace: zásady 12-Factor – konfigurace prostřednictvím proměnných, tajemství uložená externě (Vault/KMS), vstupní bod bez úprav typu shell hack.

Orchestrace v Kubernetes: od podů ke službám

  • Základní objekty: Pod (běh kontejnerů), Deployment (repliky a postupné nasazování), Service (vyvažování zátěže na L4), Ingress/Gateway (směrování na L7).
  • Škálování: HPA (metriky CPU/paměti/vlastní metriky), VPA pro doporučení, KEDA pro škálování řízené událostmi.
  • Úložiště: CSI pro persistentní svazky, třídy úložiště; stavové služby prostřednictvím StatefulSet, PodDisruptionBudget.
  • Síť: CNI (Calico/Cilium), NetworkPolicy pro izolaci; šifrování komunikace mezi pody (IPsec/WireGuard) podle CNI.

Service Mesh: spolehlivost a bezpečnost na síťové vrstvě

Proxy sidecar (např. Envoy) přidává mTLS, řízení provozu, opakované pokusy/jistič, telemetrii a politiky bez změn aplikačního kódu. Dávejte pozor na režii: zvažte varianty ambient nebo bez sidecaru, případně mesh pouze pro kritické domény.

Observabilita: logy, metriky a trasování

  • Metriky: RED/USE (rate, errors, duration / utilization, saturation, errors), standard OpenMetrics; centralizace do TSDB a upozorňování na základě SLO/SLI.
  • Logy: strukturované JSON, korelační ID napříč službami; pravidla uchovávání a maskování.
  • Trasování: OpenTelemetry pro měření latence od začátku do konce; vzorkování (tail-based) a baggage pro obchodní korelace.

Odolnost a řízení provozu

  • Časový limit, opakované pokusy, jitter: vždy je definujte a testujte – výchozí hodnoty existují jen v dokumentaci.
  • Jistič: izolujte kaskádová selhání; záložní řešení a izolace vláken/poolů pomocí oddělených oblastí.
  • Chaos engineering: řízené výpadky (sítě, uzlů, závislostí) s měřitelným cílem (SLO).

Bezpečnost cloud-native: od kódu po runtime

  • Shift-left: kontroly SAST/SCA/IaC v CI; blokování kritických CVE.
  • Provozní prostředí: seccomp/AppArmor, odebrání capabilities, souborový systém pouze pro čtení, běh bez oprávnění root, standardy zabezpečení podů, síťové politiky, detekce anomálií pomocí eBPF.
  • Politiky: OPA/Gatekeeper nebo Kyverno – vynucování podpisů image, štítků, limitů zdrojů a práce s tajemstvími.
  • Identita: identita úloh (SPIFFE/SPIRE, cloudové OIDC), rotace klíčů, nulová důvěra (Zero Trust).

CI/CD a GitOps pro mikroservisy

  • Pipeline: lint → build → test → SBOM → sign → push → deploy; matice verzí a paralelní zpracování.
  • Manifesty: deklarativní správa (Helm/Kustomize); GitOps (Argo CD/Flux) jako zdroj pravdy – auditovatelné změny, automatická rekonciliace.
  • Strategie vydávání verzí: blue-green, canary s metrikami, příznaky funkcí; automatický návrat k předchozí verzi podle SLO.

Konfigurace, tajemství a multitenance

  • Konfigurace: ConfigMap/Secrets, šablonování a verzování; prostředí oddělená pomocí namespace a RBAC.
  • Tajemství: integrace s Vault/KMS, zapečetěná tajemství; žádná tajemství v image ani v otevřené podobě v repozitáři Git.
  • Multitenance: limity/kvóty, síťové politiky, oddělené ingress/gateway, požadavky/limity zdrojů a PDB pro spravedlivé plánování.

Testování v distribuovaném světě

  • Testování kontraktů: ověřuje kompatibilitu producenta a konzumenta (podobně jako Pact).
  • Dočasná prostředí: náhledy pro jednotlivé větve (preview apps) – rychlá zpětná vazba.
  • Zátěžové a chaos testy: realistická data, testování latence, špiček a degradace závislostí.

Výkon a náklady

  • Profilování: APM, pprof/eBPF, plamenné grafy; identifikace úzkých míst (CPU, I/O, zámky, GC).
  • Řízení zdrojů: správně nastavené požadavky/limity předcházejí thrashingu a jevu hlučného souseda.
  • Nákladové metriky: náklady na požadavek, na tenanta; práh automatického škálování podle obchodních metrik (KEDA + Prometheus).

Antipatterny a jak se jim vyhnout

  • Distribuovaný monolit: mnoho služeb, ale těsné vazby a koordinovaná vydávání verzí – řešení: kontrakty, asynchronní události, nezávislá úložiště dat.
  • Upovídané služby: příliš mnoho synchronních volání na kritické cestě – řešení: agregace, CQRS, ukládání do mezipaměti, dávkové API.
  • Sdílená databáze: obcházení API prostřednictvím sdílené tabulky – řešení: vlastnictví dat a CDC/události.
  • „Jeden klastr pro všechno“: míchání rizik a priorit – řešení: izolace prostředí, skupiny uzlů, taints/tolerations.

Stavové mikroservisy a transakce

Stav je nevyhnutelný: StatefulSet s persistentním úložištěm, proby readiness/liveness/startup, řízení pod anti-affinity, topology spread, záložní repliky a vhodná strategie pod disruption. Transakce řeší Saga, idempotentní operace a sémantika pořadí v datových proudech událostí.

Platform engineering a zkušenost vývojářů

  • Osvědčené postupy: připravené šablony (Backstage/portál), přednastavené pipeline a manifesty.
  • Samoobsluha: katalog služeb, standardizované „stavebnice“ (buildpacky), interní vývojářská platforma s bezpečným výchozím nastavením.
  • Správa a řízení: policy-as-code, SLO-as-code, jednotné standardy telemetrie a dokumentace.

Hraniční případy: hybridní/multicloud a suverenita dat

Pro distribuovanou infrastrukturu jsou klíčové federace klastrů, zjišťování služeb napříč regiony, globální řízení provozu a řízení latence. Suverenita dat vyžaduje lokalitu úložiště, geofencing a šifrování dat v klidu i při přenosu.

Kontrolní seznam pro nasazení mikroservis v kontejnerech

  • Jasně vymezené domény a kontrakty (OpenAPI/AsyncAPI/Protobuf), verzování a zpětná kompatibilita.
  • OCI image: vícefázové sestavení, běh bez oprávnění root, pouze pro čtení, SBOM, podpis, skenování zranitelností.
  • Kubernetes: správně nastavené požadavky/limity, readiness/liveness, NetworkPolicy, PDB, HPA/VPA/KEDA.
  • Bezpečnost: zabezpečení podů, seccomp/AppArmor, OPA/Kyverno, identita úloh, tajemství mimo image.
  • Observabilita: metriky RED/USE, strukturované logy, trasování OpenTelemetry, SLO/upozornění.
  • CI/CD a GitOps: automatizované sestavení, canary/blue-green, návrat k předchozí verzi na základě SLO, auditní stopa.
  • Odolnost: časové limity, opakované pokusy s jitterem, jistič, oddělené oblasti, chaos testy.

Závěr: mikroservisy jako organizační i technický závazek

Mikroservisy a kontejnerizace přinášejí rychlost a škálovatelnost, vyžadují však disciplínu při návrhu kontraktů, datové architektury, bezpečnosti a observability. Úspěch neurčuje počet služeb, nýbrž kvalita hranic, automatizace a provozní vyspělost. Vytvoření stabilní platformy, standardizovaných cest pro vývojáře a měřitelných SLO proměňuje komplexitu cloud-native prostředí v konkurenční výhodu.