Komunikace mezi službami – REST, gRPC, message queue

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 fronty). Žá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; semantika metod GET, POST, PUT, PATCH, DELETE; status kódy pro stavové informace.
Výhody: nízké bariéry adopce, snadné debugování (cURL/HTTP tooling), přirozená integrace s API gateway a caching.
Nevýhody: overhead JSON a HTTP hlaviček, obtížnější kontraktová typovost, slabší streamingové vzory a duplexní komunikace.
Use-cases: veřejná API, B2B integrace, „request/response“ dotazovací operace, CRUD nad zdroji s požadavkem na cacheovatelnost.

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

Transport a formát: HTTP/2 + Protobuf; podpora unary, server-streaming, client-streaming a bidirectional streaming.
IDL a kontrakty: .proto soubory jako zdroj pravdy; generovaný kód klient/server, silná typovost a jasně daná evoluce schémat (field numbers, optional/oneof).
Výhody: nízká latence, menší payloady, zpětná kompatibilita při správné správě polí, vestavěná metadata pro deadline a cancelaci.
Nevýhody: složitější ladění bez nástrojů, méně přívětivé pro webové prohlížeče (vyžaduje gRPC-Web proxy), horší čitelnost bez generovaného kódu.
Use-cases: interní „east-west“ komunikace mezi mikroservisami s vysokou propustností, streaming telemetrie, real-time feedy.

Message queue: asynchronie, decoupling a elastické škálování

Modely: fronty (point-to-point) a pub/sub (broadcast podle témat/klíčů). Implementace: Kafka, RabbitMQ, NATS, Pulsar aj.
Semantika doručení: typicky at-least-once (s nutnou idempotencí a deduplikací), vzácně at-most-once; „exactly-once“ je omezené a nákladné na orchestraci.
Výhody: vyvázání odesílatele a příjemce v čase, pohlcení špiček, přirozený event-driven design, možnost reprocessingu a time-travel (log-based brokery).
Nevýhody: složitější ladění a řízení konzistence, riziko „lost wakeup“ bez správné observability, nutnost zvládnout pořadí, partice a rebalancování.
Use-cases: zpracování objednávek, platební workflow, notifikace, integrace s externími systémy, event sourcing a CQRS.

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

JSON: čitelný, snadno debugovatelný; horší binární efektivita a nejednoznačnost typů (čísla, data, enumerace).
Protobuf: binární, kompaktní, pevná ID polí; vynikající pro gRPC a interní API s generováním klientů.
Avro: self-describing nebo se schema registry; vhodné pro streamy (Kafka) a evoluci schémat.
Schema registry: u event-driven systémů umožní řídit kompatibilitu (backward/forward/full) a audit změn.

API návrh, verzování a kompatibilita

REST: preferujte evolutionary návrh – přidávejte volitelná pole, neměňte význam existujících; breaking changes pod novou verzí (/v2), nebo přes content negotiation.
gRPC: neměňte čísla polí, odebrané položky označte reserved; preferujte optional před required.
Eventy: události jsou append-only; nikdy neměňte význam existujících polí; nové informace jako nová pole/nový typ události.

Spolehlivost: timeouty, retry, circuit breaking a backpressure

Timeout budget: nastavujte deadline end-to-end (gRPC metadata, REST hlavičky) a propagujte ji downstream.
Retry politiky: exponenciální backoff s jitterem; retrujte pouze idempotentní operace (GET, bezpečné PUT/DELETE), vyhněte se retry-storms.
Circuit breaker: ochrana proti kaskádovým pádům; v kombinaci s bulkhead isolation a load-shedderem.
Backpressure: u streamingu (gRPC, messaging) respektujte flow-control; v pub/sub omezujte consumer lag a nastavte paralelismus.

Konzistence dat: synchronní vs. asynchronní vzory

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

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

Pořadí: garantováno v rámci partice; pro entitně konzistentní pořadí (např. účet) používejte partition-key podle ID.
Paralelizace: zvyšujte počet particí/consumerů; pozor na hot-key (skew) a dlouhé transakce brzdící commit offsetů.
DLQ a retry témata: oddělte krátkodobé chyby (retry) od trvalých (dead letter queue) s alerty a forenzí.

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

API gateway: centralizuje autentizaci, rate-limit, transformace a routing; ideální pro veřejná a partnerská REST/gRPC API.
Service mesh: jednotná L7 kontrola (mTLS, retries, CB, telemetry) bez změn kódu; zjednodušuje east-west politiku a observabilitu.
Network policies: 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é expirace, automatizace) a pinning s rozvahou.
Autentizace/Autorizace: pro REST/gRPC tokeny (OAuth2/OIDC, JWT) a jemnozrnné politiky (ABAC/RBAC). Pro messaging autentizace klientů a ACL na témata/fronty.
Integrita a nepopiratelnost: JWS pro podepisování payloadů/eventů, rotace klíčů a audit.
Ochrana proti zneužití: rate limiting, detekce anomálií, WAF a validace schémat (JSON Schema, Protobuf validation).

Observabilita: metriky, logy, tracing a korelace

Metriky: latence (p50/p95/p99), chybovost, propustnost, saturation; pro messaging lag per partition a consumer rebalance.
Distribuované trasování: propagujte trace context (W3C Trace Context, B3) napříč REST/gRPC i eventy (trace ID v metadatech).
Strukturované logy: JSON s correlation/causation ID; u eventů ukládejte offset/partition pro reprodukovatelnost.

Výkon a latence: praktické tipy

REST: komprese (gzip/brotli) pro velké JSON; uvažujte HTTP/2 a server push náhrady (event streams, SSE) jen tam, kde dávají smysl.
gRPC: nastavujte max message size, využijte streaming místo chatu multi-requestů; deadline-aware logika na klientovi.
Messaging: batchujte produkci/konzum, používejte idempotentní producer a linger/batch.size (u log-based brokerů).

Testování: kontraktové testy, chaos a performance

Kontraktové testy: pro REST/gRPC spotřebitelé-řízené testy (CDC) – verifikují kompatibilitu bez end-to-end prostředí.
Eventové testy: validace schémat, mutační testy a re-processing replay na sandbox clusteru.
Chaos a failover: vypínání uzlů/brokerů, degradace sítě (latence, packet loss), kontrola reakce CB/retry/backpressure.
Performance: zatěž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í REST endpointů gRPC službou za API gateway; dual-write/dual-read při přechodu na event-driven.
Outbox + CDC: přenos synchronních integrací na eventy bez ztráty transakční integrity.
Verzování v běhu: simultánní podpora v1 a v2 kontraktu, feature-flags a shadow traffic pro ověření.

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

REST – externí/poloveřejná API, potřeba cacheování, široká interoperabilita, lidská čitelnost.
gRPC – interní „east-west“, nároky na latenci/propustnost, binární kontrakt, full-duplex streaming.
Message queue – oddělení v čase, odolnost a škálování, event-driven a workflow s eventual consistency.
Kombinace: příkaz synchronně (gRPC/REST) a události asynchronně (MQ) pro doručení změn; CQRS pro čtecí modely.

Referenční architektonický vzor

API gateway (REST/gRPC) s autentizací a rate-limitem.
Interní komunikace gRPC s mTLS a propagací deadline/trace contextu.
Doménové události přes broker (Kafka/Pulsar) s outbox patternem a schema registry.
Policie v service mesh (CB, retry, timeouty) a NetworkPolicies v clusterech.
Observabilita: metriky, logy, tracing sjednocené napříč kanály.

Časté proti-vzory a jak se jim vyhnout

Chatty API: mnoho synchronních výzev v řetězci → agregace endpointů, BFF (backend-for-frontend), eventy.
Neidempotentní retry: duplikace operací → idempotency keys, upsert semantika, deduplikace na konzumentovi.
„Fire-and-forget“ bez observability: ztráta událostí → DLQ, metriky produkce/konzumu, alerting na lag.
Breaking changes bez verze: porušení kontraktů → explicitní verzování a CDC testy v CI.

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

Moderní mikroservisní platformy využívají kombinaci REST, gRPC a message queue podle povahy domény. Silný kontrakt (IDL/Schema), řízená kompatibilita, explicitní politiky pro timeouty/retry/CB a robustní observabilita jsou základy 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í.