Modulární monolit vs mikroslužby. Jak zvolit architekturu

Fakturace a sklad čekají na společné vydání, přestože je vyvíjejí různé týmy. Rozhodnutí o mikroslužbách začíná tímto omezením a cenou jeho odstranění. Samostatná služba umožní nezávislé nasazení, ale přidá síťová volání a další provoz.

Modulární monolit běží jako jedna aplikace a uvnitř odděluje obchodní schopnosti. Objednávky, fakturace a sklad mají vlastní rozhraní. Mikroslužby přesouvají podobné hranice do samostatných procesů a zpravidla i úložišť. Rozdíl spočívá v provozní ceně hranice.

1. 01

   Modulární monolit

   Jeden proces a deployment. Moduly komunikují přes vnitřní kontrakty.

2. 02

   Mikroslužby

   Samostatné procesy a deploymenty. Každá hranice přidává síť a provoz.

Začněme doménou

Pokud tým neumí vymezit doménu uvnitř jednoho procesu, síť ji sama nenajde. Nejasné rozdělení vytvoří častá vzdálená volání, sdílené tabulky a stále koordinovaná vydání. Systém získá distribuované chyby bez skutečné nezávislosti.

Modul potřebuje veřejný kontrakt. Fakturace nemá číst interní tabulky skladu. Požádá skladový modul o rezervaci přes jeho rozhraní. Pravidla závislostí a architektonické testy mohou hranici chránit. Stabilní lokální kontrakt se později přesouvá za API s menším rizikem.

Dobré moduly sledují schopnosti firmy, nikoli technické složky typu controller a repository. Změna cen tak zůstává v cenotvorbě. Stejný princip popisujeme na úrovni kódu v článku o návrhových vzorech v praxi.

Co mikroslužba kupuje

Samostatně nasazovaná služba se může měnit vlastním tempem. Vyhledávání lze vydat bez nasazení celého produktu. Výpočetně náročná část se škáluje odděleně a citlivá schopnost může mít přísnější bezpečnostní režim. Nezávislost má hodnotu, pokud ji organizace umí využít.

Cena přichází ihned. Volání funkce se změní na síťový požadavek. Může být pomalý, duplicitní nebo nedostupný. Systém potřebuje časové limity, idempotentní opakování, trasování a plán pro částečné selhání. Jedna databázová transakce již neudrží celý obchodní krok pohromadě.

Mění se i testování. Úspěšný jednotkový test nedokazuje, že nasazené služby stále souhlasí. Kontrakty vyžadují kontrolu kompatibility. Produkce potřebuje logy, metriky a stopy, které ukážou místo zastavení požadavku. Bez nich roste doba diagnostiky rychleji než počet služeb.

Data ukazují skutečnou hranici

Služba s vlastním kódem, která čte cizí tabulky, není nezávislá. Změna schématu ji poškodí bez zásahu do jejího repozitáře. Vlastnictví dat proto patří do rozhodnutí o architektuře.

Samostatná úložiště zároveň znamenají dočasně neaktuální pohledy. Objednávka může být potvrzena dřív, než fakturace zpracuje událost. Tým musí určit, kde je zpoždění bezpečné. Účetní zůstatek nebo rezervace posledního kusu mohou potřebovat jiný model než report.

Distribuovanou transakci nemá skrývat křehký řetězec synchronních volání. Pomoci mohou události, idempotentní příjemci a obnovitelné procesy. Také je však musíme sledovat a testovat. Pokud produkt nepotřebuje nezávislé vlastnictví dat, společná databáze za chráněnými moduly bývá levnější.

Vlastnictví týmu mění odpověď

Mikroslužby fungují nejlépe, když týmy vlastní službu od návrhu po produkční incident. Samostatný repozitář bez stálého vlastníka odpovědnost rozptýlí. Změny čekají na lidi, kteří rozumějí jinému článku řetězce.

Menší produktový tým často získá víc z jednoho nasazení, jednoho vývojového prostředí a přímých refaktorů napříč moduly. To neznamená neuspořádaný monolit. Distribuce je pouze drahý způsob, jak vynucovat kázeň v kódu.

Poměr se mění, když nezávislé týmy pravidelně blokují společné vydání, doménová hranice je stabilní a části potřebují vlastní provozní rytmus. Oddělení pak může snížit koordinaci. Důkaz vychází z pozorované práce, nikoli z módního diagramu.

1. 01

   Samostatný rytmus změn

   Jeden modul blokuje vydání ostatních.

2. 02

   Odlišné škálování

   Zátěž je izolovaná a opakovaně změřená.

3. 03

   Jasný vlastník

   Tým umí převzít vývoj i provoz.

4. 04

   Stabilní kontrakt

   Hranice domény se už nemění každý sprint.

Signály pro oddělení modulu

Jedním signálem je nezávislý důvod ke změně. Modul má vlastní plán a většina práce nevyžaduje úpravy jinde. Druhým je odlišný provozní požadavek. Potřebuje jiné škálování, dostupnost nebo technologii, kterou zbytek aplikace nepotřebuje.

Stejně podstatný je stabilní kontrakt. Tým umí pojmenovat vstupy, výstupy, vlastnictví dat a chování při chybě. Pokud se kontrakt mění každý sprint, samostatné nasazení pouze převede lokální nestabilitu na správu verzí API.

Praktický postup nejprve posílí hranici v monolitu. Odstraní přímé databázové zkratky, přidá kontraktové testy a změří interakce. Potom lze porovnat přínos oddělení s cenou distribuce. Služba je závěr podložený důkazy.

Rozhodnutí musí zůstat vratné

Pro nový firemní systém je modulární monolit často rozumný začátek, dokud produkt a hranice dozrávají. Jedno nasazení urychluje zpětnou vazbu. Dobře chráněné moduly zachovají možnost oddělit část, která si později nezávislost zaslouží.

Mikroslužby dávají smysl, když firma už platí měřitelnou cenu za společná vydání, škálování nebo nejasné vlastnictví. Odhad musí zahrnout platformu, pozorovatelnost a řešení incidentů. Samotné rozdělení zdrojového kódu tyto schopnosti nevytvoří.

Při vývoji softwaru na míru zapisujeme předpoklady jako rozhodnutí, které lze později přezkoumat. Pokud starší systém už změny brzdí, navazuje průvodce modernizací legacy systému bez velkého přepisu. Rozhodnutí posuzujte podle ceny bezpečné změny.

Před oddělením má existovat i cesta zpět. Metriky modulu ukážou zátěž, chyby a četnost změn. Teprve tato data dovolují rozumně spočítat náklady. Pokud po oddělení každé vydání nadále vyžaduje několik týmů současně, byla hranice zvolena špatně. Je lepší ji opravit než chránit název architektury.

Záznam rozhodnutí má pojmenovat vlastníka služby, spravovaná data, rytmus nasazování a přijatelné selhání. Po několika vydáních porovnejte koordinaci a řešení incidentů s původním stavem. Výsledek může odůvodnit další oddělení i spojení modulu zpět.