Komunikace mezi službami: REST, gRPC a fronty zpráv

Komunikační modely v mikroservisní architektuře

Komunikace mezi službami je jedním z klíčových návrhových rozhodnutí v mikroservisní architektuře. Ovlivňuje latenci, propustnost, konzistenci dat, volbu technologií, provozní náklady i způsob testování. Tři dominantní přístupy jsou REST (HTTP/1.1/2, JSON/HTTP), gRPC (HTTP/2, Protobuf, streaming) a message queue (asynchronní zpracování přes broker s pub/sub nebo frontami). Žádný z modelů není univerzálně „nejlepší“ – správná volba závisí na charakteru domény, SLA, profilech zatížení a požadavcích na konzistenci.

REST: jednoduchost, interoperabilita a webový ekosystém

Transport a formát: HTTP/1.1 (nebo HTTP/2) s JSON/HTTP; široká podpora nástrojů, prohlížečů a reverzních proxy. Vysoká interoperabilita mezi jazyky a platformami.
Modelování API: prostředky (resources) a jejich reprezentace; sémantika metod GET, POST, PUT, PATCH, DELETE; stavové kódy pro stavové informace.
Výhody: nízké bariéry adopce, snadné ladění (cURL/HTTP nástroje), přirozená integrace s API gateway a cachováním.
Nevýhody: režie JSON a hlaviček HTTP, obtížnější typová kontrola kontraktů, slabší vzory streamingu a duplexní komunikace.
Případy použití: veřejná API, B2B integrace, dotazovací operace typu „request/response“, CRUD nad zdroji s požadavkem na možnost cachování.

gRPC: vysoký výkon, binární kontrakty a streaming

Transport a formát: HTTP/2 + Protobuf; podpora režimů unary, server-streaming, client-streaming a bidirectional streaming.
IDL a kontrakty: soubory .proto jako zdroj pravdy; generovaný klientský a serverový kód, silná typová kontrola a jasně definovaná evoluce schémat (čísla polí, optional/oneof).
Výhody: nízká latence, menší datové objemy, zpětná kompatibilita při správě polí podle doporučených postupů, vestavěná metadata pro deadline a zrušení požadavku.
Nevýhody: složitější ladění bez nástrojů, menší vhodnost pro webové prohlížeče (vyžaduje proxy gRPC-Web), horší čitelnost bez generovaného kódu.
Případy použití: interní komunikace „east-west“ mezi mikroservisami s vysokou propustností, streaming telemetrie, datové proudy v reálném čase.

Message queue: asynchronní zpracování, oddělení komponent a elastické škálování

Modely: fronty (point-to-point) a pub/sub (vysílání podle témat/klíčů). Implementace: Kafka, RabbitMQ, NATS, Pulsar aj.
Sémantika doručování: typicky at-least-once (vyžaduje idempotenci a deduplikaci), výjimečně at-most-once; „exactly-once“ je omezené a náročné na orchestraci.
Výhody: časové oddělení odesílatele a příjemce, pohlcení špiček, přirozený návrh řízený událostmi, možnost opětovného zpracování a návratu v čase (u brokerů založených na logu).
Nevýhody: složitější ladění a řízení konzistence, riziko „zmeškaného probuzení“ bez správné observability, nutnost zvládnout pořadí, partition a rebalance.
Případy použití: zpracování objednávek, platební workflow, notifikace, integrace s externími systémy, event sourcing a CQRS.

Serializační formáty a kontrakty: JSON, Protobuf, Avro

JSON: čitelný, snadno laditelný; nižší efektivita binárního formátu a nejednoznačnost typů (čísla, data, výčtové typy).
Protobuf: binární, kompaktní, s pevnými ID polí; vynikající pro gRPC a interní API s generováním klientů.
Avro: se samopopisujícím schématem nebo se schema registry; vhodné pro streamy (Kafka) a evoluci schémat.
Schema registry: v systémech řízených událostmi umožňuje spravovat kompatibilitu (zpětnou/dopřednou/úplnou) a auditovat změny.

Návrh API, verzování a kompatibilita

REST: upřednostňujte evoluční návrh – přidávejte volitelná pole, neměňte význam stávajících; zpětně nekompatibilní změny vydávejte pod novou verzí (/v2) nebo pomocí vyjednávání obsahu.
gRPC: neměňte čísla polí, odebrané položky označte jako reserved; upřednostňujte optional před required.
Události: události se pouze přidávají; nikdy neměňte význam stávajících polí; nové informace přidávejte jako nová pole nebo nový typ události.

Spolehlivost: timeouty, opakování, přerušení okruhu a zpětný tlak

Rozpočet pro timeout: nastavujte deadline pro celý řetězec (metadata gRPC, hlavičky REST) a předávejte ji dalším službám.
Politiky opakování: exponenciální prodleva s jitterem; opakujte pouze idempotentní operace (GET, bezpečné PUT/DELETE), vyhýbejte se bouřím opakovaných požadavků.
Circuit breaker: ochrana proti kaskádovým výpadkům; kombinujte s izolací bulkhead a omezováním zátěže.
Zpětný tlak: u streamingu (gRPC, messaging) respektujte řízení toku; u pub/sub omezujte zpoždění konzumentů a nastavte paralelismus.

Konzistence dat: synchronní a asynchronní vzory

Synchronní orchestrace: volání REST/gRPC v transakčním řetězci – nižší latence odezvy, ale vyšší křehkost.
Asynchronní choreografie: workflow řízené událostmi; vyšší odolnost a škálovatelnost, ale eventual consistency a potřeba kompenzačních kroků typu saga.
Transactional outbox: zápis změny v doméně a události „outbox“ v rámci jedné lokální transakce; následné spolehlivé publikování prostřednictvím relay.
Idempotence: klíčová pro at-least-once; využívejte idempotency keys, tabulky deduplikace a přirozené unikátní klíče.

Pořadí, partition a škálování v message systémech

Pořadí: je zaručeno v rámci partition; pro pořadí konzistentní v rámci entity (např. účtu) používejte partition key podle ID.
Paralelizace: zvyšujte počet partition/konzumentů; pozor na přetížený klíč (skew) a dlouhé transakce, které brzdí potvrzování offsetů.
DLQ a témata pro opakování: oddělte krátkodobé chyby (opakování) od trvalých (dead letter queue) a nastavte upozornění a forenzní analýzu.

API gateway, service mesh a síťové politiky

API gateway: centralizuje autentizaci, omezení počtu požadavků, transformace a směrování; ideální pro veřejná a partnerská API REST/gRPC.
Service mesh: jednotná kontrola na vrstvě L7 (mTLS, opakování, CB, telemetrie) bez změn kódu; zjednodušuje politiku komunikace east-west a observabilitu.
Síťové politiky: v clusterech definujte povolené toky a segmentaci domén.

Zabezpečení: mTLS, OAuth2/OIDC a podpisy zpráv

Transport: povinné TLS/mTLS mezi službami; správa certifikátů (rotace, krátká doba platnosti, automatizace) a uvážlivé používání pinningu.
Autentizace/autorizace: pro REST/gRPC používejte tokeny (OAuth2/OIDC, JWT) a jemnozrnné politiky (ABAC/RBAC). U messagingu autentizaci klientů a ACL pro témata/fronty.
Integrita a nepopiratelnost: JWS pro podepisování datových obsahů/událostí, rotace klíčů a audit.
Ochrana proti zneužití: omezení počtu požadavků, detekce anomálií, WAF a validace schémat (JSON Schema, validace Protobuf).

Observabilita: metriky, logy, trasování a korelace

Metriky: latence (p50/p95/p99), chybovost, propustnost, saturace; u messagingu zpoždění podle partition a rebalance konzumentů.
Distribuované trasování: předávejte kontext trasování (W3C Trace Context, B3) napříč REST/gRPC i událostmi (trace ID v metadatech).
Strukturované logy: JSON s correlation/causation ID; u událostí ukládejte offset/partition kvůli reprodukovatelnosti.

Výkon a latence: praktické tipy

REST: komprese (gzip/brotli) pro velké JSON; zvažte HTTP/2 a náhrady za server push (datové proudy událostí, SSE) pouze tam, kde dávají smysl.
gRPC: nastavujte max message size, využívejte streaming místo mnoha požadavků v rámci chatu; logika na klientovi zohledňující deadline.
Messaging: dávkujte produkci/konzumaci, používejte idempotentního producenta a parametry linger/batch.size (u brokerů založených na logu).

Testování: kontraktové testy, chaos a výkon

Kontraktové testy: pro REST/gRPC používejte testy řízené konzumenty (CDC) – ověřují kompatibilitu bez prostředí end-to-end.
Testy událostí: validace schémat, mutační testy a opětovné zpracování přehráním v sandboxovém clusteru.
Chaos a převzetí služeb při selhání: vypínání uzlů/brokerů, zhoršování kvality sítě (latence, ztráta paketů), kontrola reakce CB/opakování/zpětného tlaku.
Výkon: zátěžové testy s realistickým rozložením požadavků, horkými klíči a špičkami.

Migrační a integrační strategie

Strangler pattern: postupné nahrazování endpointů REST službou gRPC přes API gateway; dual-write/dual-read při přechodu na architekturu řízenou událostmi.
Outbox + CDC: přechod od synchronních integrací k událostem bez ztráty transakční integrity.
Verzování za běhu: souběžná podpora kontraktů v1 a v2, feature flags a shadow traffic pro ověření.

Rozhodovací matice: kdy REST, kdy gRPC, kdy messaging

REST – externí/poloveřejná API, potřeba cachování, široká interoperabilita, čitelnost pro člověka.
gRPC – interní komunikace „east-west“, nároky na latenci/propustnost, binární kontrakt, obousměrný streaming.
Message queue – časové oddělení, odolnost a škálování, architektura řízená událostmi a workflow s eventual consistency.
Kombinace: příkaz synchronně (gRPC/REST) a události asynchronně (MQ) pro doručování změn; CQRS pro čtecí modely.

Referenční architektonický vzor

API gateway (REST/gRPC) s autentizací a omezením počtu požadavků.
Interní komunikace gRPC s mTLS a předáváním deadline/kontextu trasování.
Doménové události přes broker (Kafka/Pulsar) se vzorem outbox a schema registry.
Politiky v service mesh (CB, opakování, timeouty) a NetworkPolicies v clusterech.
Observabilita: metriky, logy a trasování sjednocené napříč kanály.

Časté anti-patterny a jak se jim vyhnout

Upovídané API: mnoho synchronních volání v řetězci → agregace endpointů, BFF (backend-for-frontend), události.
Neidempotentní opakování: duplikace operací → idempotency keys, sémantika upsert, deduplikace na straně konzumenta.
„Fire-and-forget“ bez observability: ztráta událostí → DLQ, metriky produkce/konzumace, upozornění na zpoždění.
Zpětně nekompatibilní změny bez verze: porušení kontraktů → explicitní verzování a testy CDC v CI.

Závěr: kombinace komunikačních stylů jako konkurenční výhoda

Moderní mikroservisní platformy využívají kombinaci REST, gRPC a message queue podle povahy domény. Pevný kontrakt (IDL/Schema), řízená kompatibilita, explicitní politiky pro timeouty/opakování/CB a robustní observabilita jsou základem udržitelného provozu. Vyvážená architektura – synchronní pro kritické dotazy a asynchronní pro šíření změn a škálování – přináší nižší latenci, vyšší odolnost a rychlejší vývoj s menším rizikem regresí.