Přeskočit na obsah
_CORE
AI & agentní systémy Podnikové informační systémy Cloud & Platform Engineering Datová platforma & integrace Bezpečnost & compliance QA, testování & observabilita IoT, automatizace & robotika Mobilní & digitální produkty Bankovnictví & finance Pojišťovnictví Veřejná správa Obrana & bezpečnost Zdravotnictví Energetika & utility Telco & média Průmysl & výroba Logistika & e-commerce Retail & věrnostní programy
Reference Technologie Blog Know-how Nástroje
O nás Spolupráce Kariéra
CS EN DE
Pojďme to probrat

Microservices Patterns — kompletní průvodce

14. 11. 2019 Aktualizováno: 27. 03. 2026 2 min čtení intermediate
Tento článek byl publikován v roce 2019. Některé informace mohou být zastaralé.

Architektura Pokročilý

Microservices Patterns — kompletní průvodce

MicroservicesPatternsArchitektura 3 min čtení

Přehled nejdůležitějších návrhových vzorů pro mikroservisní architekturu. Od dekompozice po komunikaci mezi službami.

Co jsou Microservices Patterns?

Mikroservisní architektura rozkládá monolitickou aplikaci na nezávislé služby. Každá služba má vlastní datový model, vlastní deployment a komunikuje přes definované API.

Klíčové výhody:

  • Nezávislý deployment jednotlivých služeb
  • Technologická diverzita — každá služba může používat jiný stack
  • Škálovatelnost na úrovni jednotlivých služeb
  • Odolnost — selhání jedné služby neshodí celý systém

Decomposition Patterns

Nejdůležitější rozhodnutí je jak rozdělit monolith. Existují dva hlavní přístupy:

Decompose by Business Capability — služby odpovídají byznys schopnostem (objednávky, platby, sklad).

Decompose by Subdomain — vychází z DDD, každý bounded context = služba.

services/
├── order-service/          # Bounded context: Objednávky
│   ├── src/
│   ├── Dockerfile
│   └── docker-compose.yml
├── payment-service/        # Bounded context: Platby
├── inventory-service/      # Bounded context: Sklad
└── api-gateway/            # Vstupní bod

Communication Patterns

Služby spolu komunikují dvěma základními způsoby:

Synchronní (Request/Response): REST API (HTTP/JSON) nebo gRPC (binární, rychlejší).

Asynchronní (Event-Driven): Message Queue (RabbitMQ) nebo Event Streaming (Kafka).

// Synchronní volání přes REST
const order = await fetch('http://order-service/api/orders/123');

// Asynchronní event přes Kafka
await kafka.produce('order-events', {
  type: 'OrderCreated',
  orderId: '123',
  items: [{ sku: 'ABC', qty: 2 }]
});

Data Management Patterns

Každá služba by měla mít vlastní databázi (Database per Service pattern). To přináší nezávislost, ale komplikuje dotazy napříč službami.

  • API Composition — query service agreguje data z více služeb
  • CQRS — oddělené modely pro čtení a zápis
  • Saga Pattern — distribuované transakce bez 2PC
  • Event Sourcing — stav jako sekvence událostí

Shrnutí

Microservices patterns nejsou jen teorie — jsou to ověřená řešení reálných problémů. Začněte s rozumnou granularitou, zvolte správný komunikační vzor a řešte data consistency od začátku.

Potřebujete pomoct s implementací?

Náš tým má zkušenosti s návrhem a implementací moderních architektur. Rádi vám pomůžeme.

Nezávazná konzultace

Sdílet:

CORE SYSTEMS tým

Stavíme core systémy a AI agenty, které drží provoz. 15 let zkušeností s enterprise IT.