Každý chce mikroslužby. Málokdo ví, jak se k nim dostat z existujícího monolitu bez toho, aby produkce shořela. Sdílíme zkušenosti z dekompozice tří enterprise monolitů — co fungovalo, co ne a proč je Strangler Fig pattern váš nejlepší přítel.
Kdy (ne)dělat mikroslužby¶
Martin Fowler to říká jasně: „Don’t start with microservices.” Pokud nemáte problém se škálováním, deployment frekvencí nebo team autonomií, mikroslužby přidávají komplexitu bez benefitu.
Mikroslužby dávají smysl, když:
- Máte více než 3 vývojové týmy pracující na jednom monolitu
- Deployment jedné feature blokuje release celé aplikace
- Různé části systému potřebují různé škálování (checkout vs. product catalog)
- Chcete používat různé technologie pro různé domény (Python pro ML, Go pro API)
Strangler Fig Pattern¶
Pojmenovaný podle fíkovníku, který obrůstá strom a postupně ho nahradí. Princip: nové funkce stavíte jako mikroslužby, staré postupně migrujete. Monolit a mikroslužby běží paralelně.
# Fáze 1: API Gateway routuje vše na monolit
/api/users → monolit
/api/orders → monolit
/api/products → monolit
/api/payments → monolit
# Fáze 2: Nová payment služba, zbytek na monolitu
/api/users → monolit
/api/orders → monolit
/api/products → monolit
/api/payments → payment-service (nová mikroslužba)
# Fáze 3: Postupná migrace
/api/users → user-service
/api/orders → order-service
/api/products → monolit (zatím)
/api/payments → payment-service
Klíčové: nikdy neděláte big bang rewrite. Každá migrace je malý, reversibilní krok. Pokud nová služba nefunguje, přepnete routing zpět na monolit.
Domain-Driven Design — kde řezat¶
Nejčastější chyba: řezat mikroslužby podle technických vrstev (UI service, business logic service, data service). Správný přístup je řezat podle business domén (bounded contexts).
- Order context — vytvoření objednávky, stav objednávky, historie
- Payment context — platební brána, refunds, invoicing
- Inventory context — skladové zásoby, rezervace, reorder
- User context — registrace, autentizace, profil, preferences
Každý bounded context má vlastní databázi. Žádné sdílení tabulek mezi službami. Toto je nejdůležitější pravidlo a zároveň nejtěžší dodržet.
API Gateway¶
Klienti by neměli komunikovat s desítkami mikroslužeb přímo. API Gateway je single entry point:
- Kong — open-source, Lua plugins, vysoký výkon (nginx-based)
- Netflix Zuul — Java, integrovaný s Spring Cloud ekosystémem
- AWS API Gateway — managed, integrovaný s Lambda
- Traefik — nativní Docker/Kubernetes integrace, automatická service discovery
API Gateway zajišťuje: routing, rate limiting, authentication, request/response transformation, aggregation (BFF — Backend for Frontend pattern).
Distribuované transakce — Saga pattern¶
V monolitu máte ACID transakce. V mikroslužbách ne — každá služba má vlastní databázi. Saga pattern řeší distribuované transakce jako sekvenci lokálních transakcí s kompenzačními akcemi:
Saga: Vytvoření objednávky
1. Order Service → Vytvořit objednávku (PENDING)
2. Payment Service → Autorizovat platbu
3. Inventory Service → Rezervovat zboží
4. Order Service → Potvrdit objednávku (CONFIRMED)
Kompenzace (pokud krok 3 selže):
3c. Inventory Service → (skip — selhal)
2c. Payment Service → Zrušit autorizaci platby
1c. Order Service → Zrušit objednávku (CANCELLED)
Implementace: choreografie (events přes message broker — jednodušší, decentralizované) nebo orchestrace (centrální saga orchestrátor — složitější, lepší visibility).
Komunikace mezi službami¶
Dva základní přístupy:
- Synchronní (REST/gRPC) — jednodušší, ale vytváří temporal coupling. Pokud je downstream služba nedostupná, caller selže.
- Asynchronní (events) — Kafka, RabbitMQ. Služby jsou decoupled, ale eventual consistency je těžší debugovat.
Pravidlo: commands synchronně, events asynchronně. „Vytvoř objednávku” je REST call. „Objednávka byla vytvořena” je event na Kafka topic.
Observability — musíte vidět, co se děje¶
Distribuovaný systém bez observability je noční můra. Tři pilíře:
- Logging — centralizované logy s correlation ID (ELK Stack, Fluentd)
- Metrics — Prometheus + Grafana, RED metriky (Rate, Errors, Duration)
- Tracing — Jaeger, Zipkin pro vizualizaci request flow přes služby
Bez distributed tracingu strávíte hodiny hledáním, která z 15 služeb způsobila timeout. S Jaegerem to vidíte za 10 sekund.
Databázová dekompozice¶
Nejtěžší část migrace. Monolit typicky má jednu velkou databázi s foreign keys mezi tabulkami. Postup:
- Krok 1: Oddělte tabulky logicky (schema per bounded context)
- Krok 2: Nahraďte JOINy mezi kontexty API calls
- Krok 3: Fyzicky oddělte databáze
- Krok 4: Implementujte event-driven synchronizaci tam, kde služby potřebují data z jiného kontextu
Mikroslužby jsou maraton, ne sprint¶
Dekompozice monolitu je proces, který trvá měsíce až roky. Strangler Fig pattern zajistí, že produkce běží po celou dobu. Začněte jednou službou — ideálně tou, která má nejjasnější domain boundary a největší deployment pain. Naučte se na ní provoz mikroslužeb (monitoring, deployment, debugging) a pak pokračujte s dalšími.