NatusAI
Debata „monolit verzus mikroslužby“ sa často začína diagramom nasadenia. Jeden box, alebo veľa? Užitočnejšia otázka však prichádza skôr: ktorú zložitosť má vlastniť váš tím a ktorú má spravovať platforma?
Malý tím potrebuje jasný model a krátku cestu od nápadu k fungujúcej aplikácii. Rastúca organizácia potrebuje aj kapacitu, odolnosť a priestor, aby tímy mohli pracovať nezávisle. Tieto potreby spolu súvisia, no nie sú rovnaké.
Cygnus skúma inú rovnováhu: udržať aplikačnú logiku a dáta v jednom logickom modeli a postupne meniť, kde a ako sa tento model umiestňuje a vykonáva. Cieľom je znížiť integračnú prácu, ktorú vývojári opakovane stavajú okolo samostatných databáz, služieb a nástrojov AI.
01 / Voľba architektúry
Monolity a mikroslužby riešia rôzne problémy.
Monolit balí aplikáciu ako jednu nasaditeľnú jednotku. Môže byť modulárny, dôkladne otestovaný a replikovaný za load balancerom. Jeho príťažlivosť je praktická: lokálne volania, jednoduché ladenie a menej pohyblivých častí. Jeho obmedzenia sa často prejavia pri spoločných vydaniach, hraniciach vlastníctva alebo nerovnomerných nárokoch na zdroje.
Mikroslužby delia aplikáciu na nezávisle nasaditeľné služby. Sú užitočné, keď domény a tímy potrebujú vlastné cykly vydaní, pravidlá škálovania alebo prevádzkové hranice. Táto nezávislosť so sebou nesie prácu: sieťové volania, verzované kontrakty, pozorovateľnosť, spracovanie zlyhaní a často aj konzistenciu naprieč samostatnými dátovými úložiskami.
Ani jedno nie je automaticky rýchlejšie alebo škálovateľnejšie. Dobre navrhnutý monolit zvládne veľkú záťaž. Zle rozdelený systém mikroslužieb dokáže svoje úzke miesta rozptýliť a urobiť ich ťažšie viditeľnými.
Monolit
Jedno nasadenie. Vnútorné hranice závisia od návrhu kódu.
Mikroslužby
Nezávislé služby a vlastníctvo. Časti spájajú sieťové kontrakty.
Návrh Cygnus
Jednotný model vývoja. Distribuované nasadenie je smer nad rámec v1.
Rozdiel je dôležitý, pretože distribúcia nasadenia a modularita biznisu sú samostatné rozhodnutia. Môžete mať moduly bez samostatných služieb; môžete mať veľa serverov bez rozdrobenia logického modelu aplikácie.
02 / Jeden logický model
Priblížte databázu a backend k sebe.
Cygnus je plánovaný základ NatusAI pre jazyk, databázu a backend. Návrh spája typovanú aplikačnú logiku, perzistentné dáta a sprístupnené funkcie do jedného uceleného prostredia. Namiesto udržiavania samostatného mapovania na každej hranici pracujú vývojári s prepojenými objektmi a funkciami, ktoré nad nimi operujú.
To je mimoriadne dôležité pri digitálnom dvojčati alebo prevádzkovej aplikácii. Loď, budova či priemyselné zariadenie majú identitu, vzťahy, polohu, merania, dokumenty a históriu. Rozdeliť každý pohľad do nesúvisiaceho systému znamená znovu budovať prepojenia, ktoré vo firme už existujú.
Jednotný model má tieto prepojenia zachovať. Runtime navyše dostane viac informácií o dátach, dopytoch a vykonávaní – informácií, ktoré môžu podporiť budúce rozhodnutia o umiestnení a koordinácii.
Jeden model pre aplikáciu.
Viac možností, kde beží.
Ide o princíp návrhu, nie o sľub, že každá záťaž sa bude škálovať transparentne. Partičné kľúče, vzory dopytov, hranice transakcií a latencia stále ovplyvňujú, ako treba aplikáciu postaviť.
03 / Štyri spôsoby rastu
Škálujte požiadavky a dáta ako samostatné potreby.
„Potrebujeme škálovať“ môže znamenať viac súbežných požiadaviek, väčšiu dátovú sadu, vyššiu dostupnosť – alebo všetky tri. Replikácia a sharding riešia rôzne časti tohto problému. Nasledujúca interaktívna ukážka ilustruje smer distribuovaného návrhu Cygnus; nejde o živý klaster ani o vydanú funkciu nasadenia.
01 · Jeden uzol
Začnite jednou ucelenou aplikáciou
Aplikačná logika a celá dátová sada sú spolu na jednom serveri. To je rozsah plánovaného profilu nasadenia Cygnus v1.
Najjednoduchší prevádzkový model. Kapacita a dostupnosť závisia od jedného servera a jeho postupov obnovy.
02 · Repliky
Skopírujte model na viac uzlov
V smere distribuovaného návrhu nesú uzly ten istý aplikačný kód a úplnú kópiu dát. Replikácia môže podporiť redundanciu a dodatočnú kapacitu pre požiadavky – v závislosti od modelu konzistencie a smerovania zápisov.
Kópie musia koordinovať aktualizácie. Viac replík automaticky neznásobí priepustnosť zápisov.
03 · Shardy
Rozdeľte dáta, zachovajte model
Aplikačný kód zostáva spoločný, zatiaľ čo každý uzol vlastní jednu partíciu dát. Umiestnenie sa môže riadiť geografiou, časovými rozsahmi alebo rozsahmi kľúčov – podľa záťaže.
Smerovanie a dopyty naprieč partíciami potrebujú explicitné pravidlá. Nerovnomerné dáta alebo vzory prístupu môžu vytvoriť horúce miesta.
04 · Oboje
Replikujte každú partíciu
Spojte kapacitu naprieč shardmi s redundanciou v rámci každého shardu. Zamýšľaný zážitok pre vývojárov zostáva jedna logická databáza a backend, zatiaľ čo runtime spravuje zložitejšiu fyzickú topológiu.
Umiestnenie replík, failover, rebalancovanie a distribuované transakcie si vyžadujú kvalifikáciu. Ide o smer návrhu nad rámec v1.
úplná kópia dát jedna partícia dát · Iba ilustrácia: nie živý klaster ani vydaná funkcia nasadenia.
Začnite na jednom uzle
Plánovaný profil v1 sa začína jedným serverom. Aplikačný kód a dáta sú spolu, takže prvé nasadenie zostáva zvládnuteľné. Zálohy, obnova, oprávnenia a limity zdrojov zostávajú súčasťou zodpovednej prevádzky.
Replikujte kvôli redundancii a kapacite pre požiadavky
V budúcom distribuovanom modeli by niekoľko uzlov mohlo niesť ten istý kód a úplnú kópiu dátovej sady. Vznikne tak viac miest na obsluhu vhodných požiadaviek a systém môže zniesť výpadok niektorých uzlov. Výsledok závisí od smerovania, oneskorenia replikácie, záruk konzistencie a od toho, ktoré operácie sa môžu vykonávať na ktorých replikách.
Shardujte kvôli kapacite dát
Keď dátová sada prerastie server, pridávanie úplných kópií problém s úložiskom nevyrieši. Sharding rozdelí dáta medzi uzly. Záťaž môže byť rozdelená podľa geografie, časového rozsahu alebo rozsahu kľúčov. Dopyty, ktoré tieto partície prekračujú, potrebujú smerovanie a niekedy aj distribuované vykonávanie.
Jednoduchá ilustrácia kapacity: 30 TB logických dát potrebuje najmenej osem serverov so 4 TB, a to ešte pred replikami, indexmi, prevádzkovou rezervou či inou réžiou. Ide o aritmetiku, nie o meranie kapacity Cygnus.
Skombinujte oboje
Každý shard môže mať vlastné repliky. Shardy prinášajú celkovú kapacitu dát; repliky pridávajú redundanciu a možnosti obsluhy požiadaviek. Práve túto kombinovanú topológiu si ľudia často predstavujú pod databázou distribuovanou naprieč flotilou serverov.
Rastite a zmenšujte sa podľa dopytu
Dlhodobým smerom je automatizovať tieto voľby podľa pravidiel pre záťaž: pridať kapacitu, keď dopyt rastie, presunúť vykonávanie k dátam, ktoré potrebuje, a uvoľniť kapacitu, keď dopyt klesá. Cieľom je zachovať logický model aplikácie aj pri zmenách umiestnenia.
Zmenšovanie musí najprv dokončiť prácu a bezpečne presunúť alebo zachovať potrebné kópie dát. Plánovanie, rebalancovanie, konzistencia a obnova potrebujú explicitné pravidlá a kvalifikáciu. Automatické rozširovanie a zmenšovanie sú budúce ciele návrhu klastra, mimo plánovaného v1 pre jeden server.
04 / Zodpovednosť runtimu
Presuňte koordináciu do platformy.
Zamýšľaný zážitok s Cygnus zachováva jednu kódovú základňu aplikácie a jednu logickú databázu, aj keď sa nasadenie vyvíja. Distribúcia spravovaná runtimom by prevzala umiestnenie, smerovanie, replikáciu a mechaniku koordinácie zúčastnených uzlov.
Táto mechanika nezmizne. Siete prinášajú latenciu a výpadky spojenia. Aktualizácie potrebujú pravidlá konzistencie. Transakcie naprieč shardmi potrebujú definovaný protokol. Obnova musí vedieť, čo bolo potvrdené, a rebalancovanie nesmie pri presune stratiť vlastníctvo dát.
Príležitosťou je implementovať tieto zodpovednosti raz v platforme, s explicitnými kontraktmi a prevádzkovými nástrojmi, namiesto toho, aby si každá aplikácia skladala vlastnú verziu. Aplikácia stále potrebuje hranice, ktoré zodpovedajú jej záťaži.
05 / Dáta v čase
Prepojený model potrebuje pamäť.
Mnohé biznisové otázky majú časový rozmer, aj keď ho nikto nevysloví. Kde bolo toto zariadenie pred incidentom? Ktorá organizácia ho vtedy riadila? Čo systém vedel, keď dal toto odporúčanie?
Návrh Cygnus spája grafové vzťahy, geopriestorové dáta, vektory, trojice, časové rady a fulltextové vyhľadávanie v rovnakom logickom základe. Sú to spôsoby, ako skúmať jeden subjekt, nie samostatné definície toho, čo tento subjekt je.
- Graf a trojice
Čo je prepojené – a ako?
- Geopriestorové dáta
Kde bolo v danom čase?
- Časové rady
Ako sa vyvíjali jeho namerané hodnoty?
- Fulltext a vektory
Ktoré záznamy sa zhodujú alebo znamenajú niečo podobné?
Koncepčný model. Historické odpovede potrebujú aj uchované verzie zdrojov a záznam o pôvode vyhľadávania, modelu a promptu.
História pre dáta – a pôvod pre AI
Temporálne dáta môžu opísať, ako sa mení zariadenie, jeho namerané hodnoty alebo vzťahy. Historická odpoveď AI si vyžaduje viac. Závisí aj od zdrojových dokumentov, embeddingov, konfigurácie vyhľadávania, verzie modelu a promptu, ktoré ju vytvorili.
Uchovávanie histórie dát automaticky neuchová každý vektorový index ani nezopakuje minulú odpoveď modelu. Užitočný návrh tieto verzie zámerne prepája a zaznamenáva ich pôvod, aby odpoveď mohla odkázať späť na doklady a kontext, ktoré ju podporili.
Jeden základ pre aplikácie a nástroje
Plánované natívne schopnosti MCP a chatu umožňujú sprístupniť povolené funkcie a klásť dopyty nad prepojenými znalosťami. Nástroj alebo konverzačné rozhranie by mali pracovať s tým istým modelom a pravidlami prístupu ako aplikácia. Historický dopyt sa potom môže pýtať na zvolený čas a zároveň vysvetliť, ktoré doklady a konfigurácia AI sú pre danú odpoveď k dispozícii.
Práve tu sa jednotný backend stáva viac než jednoduchším príbehom nasadenia: môže poskytnúť spoločný základ pre prevádzkové dáta, históriu firmy a prácu s podporou AI.
06 / Voľba hraníc
Udržte architektúru v súlade s prácou.
Mikroslužby zostávajú užitočné, keď ich ospravedlňujú nezávislé tímy, odlišné bezpečnostné hranice alebo rozdielne prevádzkové požiadavky. Modulárny monolit zostáva užitočný, keď spoločné nasadenie udržiava tím produktívny. Smer Cygnus pridáva ďalšiu možnosť: jednotný model aplikácie a dát s distribúciou spravovanou hlbšie v runtime.
Správna voľba sa začína pri záťaži. Ktoré požiadavky prevládajú? Ako rýchlo musia byť aktualizácie viditeľné? Ktoré dáta patria k sebe? Čo sa stane pri výpadku siete? Ktoré zodpovednosti potrebujú nezávislé vlastníctvo?
Naším cieľom je, aby vývojári trávili viac času týmito zmysluplnými rozhodnutiami a menej času opätovným budovaním prepojení medzi svojimi nástrojmi. Začnite uceleným modelom. Zachovajte biznisové vzťahy. Fyzické nasadenie rozširujte, keď sú na to pripravené záťaž aj platforma.
Odporúčané čítanie
- Martin Fowler: Monolith First (externá stránka) – ako sa architektúra môže vyvíjať s lepším pochopením hraníc domén.
- PostgreSQL: Warm Standby (externá stránka) – príklad replikácie, prevádzky v pohotovostnom režime a kompromisov medzi synchrónnymi a asynchrónnymi aktualizáciami.
- Microsoft Azure Architecture Center: Sharding pattern (externá stránka) – partičné kľúče, smerovanie a úvahy pri distribúcii dát.
- Rozsah Cygnus v1 a neskoršie profily – verejný rozsah a stav, z ktorých tento pohľad na návrh vychádza.