Modulárny monolit vs mikroslužby. Ako si vybrať architektúru

Rozhodnutie medzi monolitom a mikroslužbami sa často zredukuje na otázku, čo je modernejšie. To je slabý základ. Architektúra má podporovať spôsob, akým tím vyvíja, nasadzuje a prevádzkuje produkt. Každá hranica služby prináša nezávislosť, no zároveň sieťovú komunikáciu, samostatné nasadenie a viac miest, na ktorých môže systém zlyhať.

Modulárny monolit beží ako jedna aplikácia, ale jeho vnútro je rozdelené podľa obchodných oblastí. Objednávky, fakturácia a sklad majú vlastné rozhrania a nevstupujú si priamo do tabuliek. Mikroslužby posúvajú podobné hranice do samostatných procesov a zvyčajne aj samostatných dátových úložísk. Rozdiel teda nie je iba v počte repozitárov. Je v prevádzkovej cene hranice.

1. 01

   Modulárny monolit

   Jeden proces a deploy. Moduly komunikujú cez vnútorné kontrakty.

2. 02

   Mikroslužby

   Samostatné procesy a deploye. Každá hranica prináša sieť a prevádzku.

Začnite doménou, nie infraštruktúrou

Ak nevieme rozumne rozdeliť obchodnú doménu v jednom procese, sieť nám s tým nepomôže. Nejasná hranica sa po rozdelení zmení na časté vzdialené volania, zdieľané databázové tabuľky a koordinované nasadenia. Systém sa tvári distribuovane, no tím ho stále musí meniť ako jeden celok.

Modul v monolite potrebuje verejný kontrakt. Kód fakturácie nemá čítať interné tabuľky skladu. Požiada skladový modul o rezerváciu cez jasné rozhranie. Takéto pravidlo sa dá strážiť testom architektúry, vlastníctvom balíkov a kontrolou závislostí. Keď hranica funguje lokálne, neskôr sa dá presunúť za sieťové API s menším rizikom.

Dobré moduly nie sú technické priečinky ako controllery, služby a repository. Sledujú schopnosti firmy. Vďaka tomu zmena cenotvorby zostáva pri cenotvorbe a nemení náhodne prepravu. Rovnaké uvažovanie používame pri návrhových vzoroch v praxi, iba na menšej úrovni kódu.

Čo si mikroslužba kupuje

Samostatná služba môže mať vlastný rytmus nasadenia. Tím upraví vyhľadávanie bez vydania celej aplikácie. Výpočtovo náročnú časť môže škálovať oddelene a kritický modul môže dostať prísnejší bezpečnostný režim. Táto nezávislosť má hodnotu tam, kde ju organizácia dokáže použiť.

Cena sa objaví okamžite. Lokálne volanie sa zmení na sieťové. Odpoveď môže meškať, prísť dvakrát alebo neprísť vôbec. Potrebujeme timeouty, opakovanie bezpečné voči duplikátom, sledovanie požiadavky cez viac služieb a spôsob, ako riešiť čiastočné zlyhanie. Jedna databázová transakcia už nedrží celý obchodný krok pokope.

To mení aj testovanie. Nestačí overiť jednu funkciu. Kontrakty medzi službami musia zostať kompatibilné a produkcia potrebuje metriky, logy a trasovanie, ktoré ukážu, kde požiadavka zastala. Bez tejto disciplíny rastie čas diagnostiky rýchlejšie než počet služieb.

Dáta určujú skutočnú hranicu

Služba, ktorá vlastní kód, ale číta cudzie tabuľky, nie je nezávislá. Zmena schémy ju môže poškodiť bez zmeny jej repozitára. Vlastníctvo dát preto patrí k jadru rozhodnutia.

Samostatné úložiská však znamenajú, že niektoré pohľady budú chvíľu neaktuálne. Objednávka sa potvrdí a fakturačný modul sa o udalosti dozvie o okamih neskôr. Tím musí pomenovať, kde je takáto oneskorená konzistencia prípustná. Pri účtovnom zostatku alebo rezervácii posledného kusu môže byť potrebný iný návrh než pri analytickom prehľade.

Rozdelená transakcia sa nemá maskovať reťazou krehkých volaní. Často pomôže udalosť, idempotentný konzument a proces, ktorý vie pokračovať po výpadku. To je však ďalší prevádzkový systém, ktorý treba pozorovať a skúšať. Ak produkt zatiaľ nepotrebuje nezávislé vlastníctvo dát, spoločná databáza za dobre chránenými modulmi býva lacnejšia.

Tímová štruktúra nie je poznámka pod čiarou

Mikroslužby dávajú najväčší zmysel, keď existujú tímy schopné vlastniť službu od návrhu po incident. Samostatný repozitár bez jasného vlastníka iba rozptýli zodpovednosť. Každá zmena potom čaká na ľudí, ktorí poznajú inú časť reťazca.

Menší produktový tím často získa viac z jedného nasadenia, jednotného vývojového prostredia a rýchlych refaktorov cez viac modulov. Neznamená to, že monolit musí byť neusporiadaný. Znamená to, že distribúcia nie je bezplatný spôsob, ako vynútiť disciplínu.

Naopak, keď dva tímy pravidelne blokujú spoločné vydanie, hranica je stabilná a každá časť potrebuje iný rytmus, oddelenie môže znížiť koordinačnú cenu. Rozhoduje pozorovaný problém, nie veľkosť diagramu.

1. 01

   Samostatný rytmus zmien

   Jeden modul blokuje vydania ostatných.

2. 02

   Odlišné škálovanie

   Záťaž je izolovaná a opakovane zmeraná.

3. 03

   Jasný vlastník

   Tím vie prevziať vývoj aj prevádzku.

4. 04

   Stabilný kontrakt

   Hranica domény sa už nemení každý sprint.

Signály, že modul dozrel na oddelenie

Prvým signálom je nezávislý dôvod na zmenu. Modul má vlastný produktový plán a väčšina jeho úprav nevyžaduje zmeny inde. Druhým je prevádzková odlišnosť. Potrebuje osobitné škálovanie, dostupnosť alebo technológiu, ktorú zvyšok aplikácie nepotrebuje.

Ďalším dôkazom je stabilný kontrakt. Tím vie pomenovať vstupy, výstupy, vlastníctvo dát a správanie pri chybe. Ak sa kontrakt mení pri každom sprinte, samostatné nasadenie iba presunie nestabilitu do verziovania API.

Praktický postup je najprv hranicu upevniť v monolite. Zastavíme priame databázové skratky, pridáme kontraktové testy a meriame volania. Až potom porovnáme prínos oddelenia s cenou distribúcie. Mikroslužba je výsledok dôkazu, nie východisková ambícia.

Rozhodnutie, ktoré sa dá neskôr zmeniť

Pre nový firemný systém je modulárny monolit často rozumný začiatok, ak produkt aj hranice ešte dozrievajú. Jedno nasadenie zrýchli spätnú väzbu. Moduly pritom zachovajú možnosť oddeliť časť, ktorá si nezávislosť neskôr zaslúži.

Mikroslužby sú správnou voľbou, keď už firma platí merateľnú cenu za spoločné vydania, škálovanie alebo vlastníctvo. Potom treba rozpočet počítať aj s platformou, pozorovateľnosťou a pohotovosťou. Samotné rozdelenie kódu nestačí.

Pri vývoji softvéru na mieru zapisujeme tieto predpoklady do rozhodnutia, ktoré sa dá po čase skontrolovať. Ak už systém brzdí zmeny, ďalší diel vysvetľuje modernizáciu legacy systému bez veľkého prepisu. Cieľ nie je vyhrať spor o architektúru. Cieľ je zmenšiť cenu bezpečnej zmeny.

Pred oddelením modulu treba pripraviť aj cestu späť a pomenovať meranie úspechu. Sledujeme frekvenciu zmien, záťaž, chyby a množstvo koordinácie pri vydaní. Ak po presune každá úprava stále vyžaduje súčasnú prácu viacerých tímov, hranica nebola zvolená dobre. Je rozumnejšie ju opraviť než chrániť názov architektúry.