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

Spor mezi monolitem a mikroslužbami se často vydává za volbu mezi starým a moderním řešením. Takový rámec při investičním rozhodnutí nepomáhá. Architektura má odpovídat způsobu, jakým tým vyvíjí, nasazuje a provozuje produkt. Každá hranice služby přináší nezávislost, ale také síť, další nasazení a nové způsoby selhání.

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. Smyslem není vyhrát debatu o architektuře. Smyslem je snížit cenu 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.

Co má obsahovat záznam rozhodnutí

Krátký záznam architektury uvádí současný problém, možnosti a ověřitelné předpoklady. U mikroslužby má být jasné, kdo ji vlastní, která data spravuje, jaký rytmus nasazení potřebuje a jaké částečné selhání musí zvládnout. Bez těchto odpovědí se rozdělení obtížně vyhodnocuje.

K rozhodnutí patří náklady, které se v diagramu neobjeví. Vývojář potřebuje lokální prostředí. Provoz potřebuje upozornění, služební pohotovost a postup při obnově. Bezpečnost musí spravovat identity mezi službami a rotaci tajemství. Každá položka je oprávněná pouze tehdy, když zakoupená nezávislost přinese větší užitek.

Po několika vydáních se záznam znovu otevře. Porovná se rychlost změn, počet koordinovaných nasazení a doba řešení incidentů. Architektura tak není jednorázový rozsudek. Je to hypotéza, kterou provoz potvrzuje nebo vyvrací. Tým může modul spojit zpět, posílit jeho hranici nebo oddělit jinou část bez toho, aby předchozí volbu považoval za selhání.