Keskustelu monoliiteista ja mikropalveluista alkaa usein käyttöönottokaaviosta. Yksi laatikko vai monta? Hyödyllisempi kysymys tulee kuitenkin aiemmin: minkä monimutkaisuuden tiimisi pitäisi omistaa, ja minkä monimutkaisuuden alustan pitäisi hoitaa?

Pieni tiimi tarvitsee selkeän mallin ja lyhyen polun ideasta toimivaan sovellukseen. Kasvava organisaatio tarvitsee lisäksi kapasiteettia, häiriönsietokykyä ja tilaa tiimien itsenäiselle työlle. Tarpeet liittyvät toisiinsa, mutta ne eivät ole samat.

Cygnus hakee toisenlaista tasapainoa: sovelluslogiikka ja data pidetään yhdessä loogisessa mallissa, ja sitä, miten malli sijoitetaan ja suoritetaan, kehitetään vaiheittain. Tavoitteena on vähentää integraatiotyötä, jota kehittäjät rakentavat yhä uudelleen erillisten tietokantojen, palvelujen ja tekoälytyökalujen ympärille.

01 / Arkkitehtuurivalinta

Monoliitit ja mikropalvelut ratkaisevat eri ongelmia.

Monoliitti paketoi sovelluksen yhdeksi käyttöönotettavaksi kokonaisuudeksi. Se voi olla modulaarinen, huolellisesti testattu ja kuormantasaajan takana replikoitu. Sen vetovoima on käytännöllinen: paikalliset kutsut, suoraviivainen virheenjäljitys ja vähemmän liikkuvia osia. Rajoitukset tulevat usein vastaan yhteisissä julkaisuissa, omistajuusrajoissa tai epätasaisissa resurssitarpeissa.

Mikropalvelut jakavat sovelluksen itsenäisesti käyttöönotettaviin palveluihin. Niistä on hyötyä, kun toimialueet ja tiimit tarvitsevat omat julkaisusyklinsä, skaalauskäytäntönsä tai operatiiviset rajansa. Itsenäisyys tuo mukanaan työtä: verkkokutsuja, versioituja sopimuksia, havainnoitavuutta, virheiden käsittelyä ja usein johdonmukaisuuden ylläpitoa erillisten tietovarastojen välillä.

Kumpikaan ei ole automaattisesti nopeampi tai skaalautuvampi. Hyvin suunniteltu monoliitti voi palvella suurta työkuormaa. Huonosti jaettu mikropalvelujärjestelmä voi hajauttaa pullonkaulansa ja tehdä niistä vaikeammin havaittavia.

Kolme tapaa järjestää sovellus

Monoliitti

Yksi sovellusLiiketoimintalogiikka · moduulit
Yhteinen tietokanta

Yksi käyttöönotto. Sisäiset rajat riippuvat koodin suunnittelusta.

Mikropalvelut

Palvelu APalvelu BPalvelu C
Data AData BData C

Itsenäiset palvelut ja omistajuus. Verkkosopimukset yhdistävät osat.

Cygnusin suunnittelu

Yksi looginen malliKieli · data · taustajärjestelmä
Ajonaikainen sijoittelu ja koordinointi

Yhtenäinen kehitysmalli. Hajautettu käyttöönotto on suunta v1:n jälkeen.

Ero on tärkeä, koska käyttöönoton hajauttaminen ja liiketoiminnan modulaarisuus ovat erillisiä päätöksiä. Moduuleja voi olla ilman erillisiä palveluja, ja palvelimia voi olla monta ilman, että sovelluksen looginen malli pirstoutuu.

02 / Yksi looginen malli

Tuo tietokanta ja taustajärjestelmä lähemmäs toisiaan.

Cygnus on NatusAI:n suunniteltu kieli-, tietokanta- ja taustajärjestelmäperusta. Suunnittelu tuo tyypitetyn sovelluslogiikan, pysyvän datan ja julkaistut funktiot yhteen yhtenäiseen ympäristöön. Sen sijaan, että jokaisella rajalla ylläpidettäisiin erillistä muunnosta, kehittäjät työskentelevät yhdistettyjen objektien ja niitä käsittelevien funktioiden kanssa.

Tämä on erityisen olennaista digitaaliselle kaksoselle tai operatiiviselle sovellukselle. Aluksella, rakennuksella tai teollisuuden omaisuuserällä on identiteetti, suhteet, sijainti, mittaukset, dokumentit ja historia. Jos jokainen näkymä jaetaan omaan, muista irralliseen järjestelmäänsä, joudutaan rakentamaan uudelleen yhteyksiä, jotka liiketoiminnassa ovat jo olemassa.

Yhtenäisen mallin tavoitteena on säilyttää nämä yhteydet. Se antaa myös ajoympäristölle enemmän tietoa datasta, kyselyistä ja suorituksesta – tietoa, joka voi tukea tulevia sijoittelu- ja koordinointipäätöksiä.

Yksi malli sovellukselle.
Enemmän vaihtoehtoja sille, missä se toimii.

Tämä on suunnitteluperiaate, ei lupaus siitä, että jokainen työkuorma skaalautuu läpinäkyvästi. Osiointiavaimet, kyselymallit, transaktiorajat ja viive vaikuttavat yhä siihen, miten sovellus kannattaa rakentaa.

03 / Neljä tapaa kasvaa

Skaalaa pyynnöt ja data erillisinä tarpeina.

”Meidän täytyy skaalata” voi tarkoittaa useampia samanaikaisia pyyntöjä, suurempaa datajoukkoa, parempaa käytettävyyttä – tai kaikkia kolmea. Replikointi ja sirpalointi ratkaisevat ongelman eri osia. Seuraava havainnollistus esittelee Cygnusin hajautetun suunnittelun suuntaa; se ei ole toiminnassa oleva klusteri eikä julkaistu käyttöönotto-ominaisuus.

Neljä topologiaa Cygnusin hajautetun suunnittelun suunnassa

  1. 01 · Yksi solmu

    Aloita yhdestä yhtenäisestä sovelluksesta

    Sovelluslogiikka ja koko datajoukko ovat yhdessä yhdellä palvelimella. Tämä on suunnitellun Cygnus v1 -käyttöönottoprofiilin laajuus.

    Yksinkertaisin toimintamalli. Kapasiteetti ja käytettävyys riippuvat yhdestä palvelimesta ja sen palautusmenettelyistä.

  2. 02 · Replikat

    Kopioi malli solmujen välillä

    Hajautetun suunnittelun suunnassa solmuilla on sama sovelluskoodi ja täydellinen kopio datasta. Replikointi voi tukea redundanssia ja lisätä pyyntökapasiteettia johdonmukaisuus- ja kirjoitusten reititysmallin puitteissa.

    Kopioiden on koordinoitava päivitykset. Useampi replika ei automaattisesti moninkertaista kirjoitusten läpäisykykyä.

  3. 03 · Sirpaleet

    Jaa data, säilytä malli

    Sovelluskoodi pysyy yhteisenä, ja kukin solmu omistaa osion datasta. Sijoittelu voi seurata maantiedettä, aikavälejä tai avainvälejä työkuorman mukaan.

    Reititys ja osioiden yli ulottuvat kyselyt vaativat selkeät säännöt. Epätasainen data tai käyttöprofiili voi luoda kuumia pisteitä.

  4. 04 · Molemmat

    Replikoi jokainen osio

    Yhdistä sirpaleiden yhteenlaskettu kapasiteetti ja kunkin sirpaleen sisäinen redundanssi. Tavoiteltu kehittäjäkokemus pysyy yhtenä loogisena tietokantana ja taustajärjestelmänä, ja ajoympäristö hoitaa monimutkaisemman fyysisen topologian.

    Replikoiden sijoittelu, vikasietoisuus, uudelleentasapainotus ja hajautetut transaktiot vaativat kvalifioinnin. Tämä on suunta v1:n jälkeen.

täydellinen kopio datasta yksi osio datasta · Vain havainnollistus: ei toiminnassa oleva klusteri eikä julkaistu käyttöönotto-ominaisuus.

Aloita yhdestä solmusta

Suunniteltu v1-profiili alkaa yhdestä palvelimesta. Sovelluskoodi ja data ovat yhdessä, joten ensimmäinen käyttöönotto pysyy helposti lähestyttävänä. Varmuuskopiot, palautus, käyttöoikeudet ja resurssirajat kuuluvat edelleen vastuulliseen ylläpitoon.

Replikoi redundanssin ja pyyntökapasiteetin vuoksi

Tulevassa hajautetussa mallissa usealla solmulla voisi olla sama koodi ja täydellinen kopio datajoukosta. Näin soveltuvia pyyntöjä voidaan palvella useammasta paikasta, ja järjestelmä voi sietää joidenkin solmujen vikaantumisen. Tulos riippuu reitityksestä, replikoinnin viiveestä, johdonmukaisuustakuista ja siitä, mitä operaatioita voidaan suorittaa millä replikalla.

Sirpaloi datakapasiteetin vuoksi

Kun datajoukko kasvaa palvelinta suuremmaksi, täydellisten kopioiden lisääminen ei ratkaise tallennustilan rajoitetta. Sirpalointi jakaa datan solmujen kesken. Työkuorma voidaan osioida maantieteen, aikavälin tai avainvälin mukaan. Osioiden yli ulottuvat kyselyt tarvitsevat reititystä ja joskus hajautettua suoritusta.

Yksinkertainen kapasiteettiesimerkki: 30 TB loogista dataa vaatii vähintään kahdeksan palvelinta, joissa kussakin on 4 TB, ennen replikoita, indeksejä, käyttövaraa tai muuta lisäkuormaa. Tämä on aritmetiikkaa, ei Cygnusin kapasiteettimittaus.

Yhdistä molemmat

Jokaisella sirpaleella voi olla omat replikansa. Sirpaleet tuovat yhteenlaskettua datakapasiteettia; replikat lisäävät redundanssia ja mahdollisuuksia palvella pyyntöjä. Tätä yhdistettyä topologiaa tarkoitetaan usein, kun puhutaan palvelinlaivastoon hajautetusta tietokannasta.

Kasva ja supistu kysynnän mukaan

Pidemmän aikavälin suuntana on automatisoida nämä valinnat työkuormakäytäntöjen ympärille: lisätä kapasiteettia kysynnän kasvaessa, siirtää suoritus sen tarvitseman datan luo ja vapauttaa kapasiteettia kysynnän laskiessa. Tavoitteena on säilyttää sovelluksen looginen malli sijoittelun muuttuessa.

Supistaminen edellyttää, että työ ensin tyhjennetään ja tarvittavat datakopiot siirretään tai säilytetään turvallisesti. Ajoitus, uudelleentasapainotus, johdonmukaisuus ja palautus vaativat selkeät säännöt ja kvalifioinnin. Automaattinen laajentaminen ja supistaminen ovat tulevan klusterisuunnittelun tavoitteita, eivätkä ne kuulu suunniteltuun yhden palvelimen v1:een.

04 / Ajoympäristön vastuu

Siirrä koordinointi alustalle.

Cygnusin tavoiteltu käyttökokemus säilyttää yhden sovelluskoodikannan ja yhden loogisen tietokannan käyttöönoton kehittyessä. Ajoympäristön hallitsema hajautus ottaisi hoitaakseen sijoittelun, reitityksen, replikoinnin ja osallistuvien solmujen koordinoinnin mekaniikan.

Mekaniikka ei katoa. Verkot tuovat mukanaan viivettä ja osioitumista. Päivitykset tarvitsevat johdonmukaisuussäännöt. Sirpaleiden yli ulottuvat transaktiot tarvitsevat määritellyn protokollan. Palautuksen on tiedettävä, mitä on vahvistettu, ja uudelleentasapainotuksessa datan omistajuus ei saa kadota siirron aikana.

Mahdollisuus on toteuttaa nämä vastuut kerran alustassa, selkeine sopimuksineen ja käyttötyökaluineen, sen sijaan että jokainen sovellus kokoaisi oman versionsa. Sovellus tarvitsee silti työkuormaansa sopivat rajat.

05 / Data ajan halki

Yhdistetty malli tarvitsee muistin.

Monessa liiketoimintakysymyksessä on aikaulottuvuus, vaikka kukaan ei sano sitä ääneen. Missä tämä omaisuuserä oli ennen häiriötä? Mikä organisaatio hallitsi sitä silloin? Mitä järjestelmä tiesi antaessaan suosituksensa?

Cygnusin suunnittelu yhdistää graafisuhteet, paikkatiedon, vektorit, triplet, aikasarjat ja kokotekstihaun samaan loogiseen perustaan. Ne ovat tapoja tarkastella kohdetta, eivät erillisiä määritelmiä siitä, mikä kohde on.

Yksi yhdistetty kohde, monta tapaa tarkastella sitä
Omaisuuserä ajan halkiIdentiteetti · tila · suhteet
  • Graafi ja triplet

    Mikä liittyy mihin – ja miten?

  • Paikkatieto

    Missä se oli tiettynä hetkenä?

  • Aikasarjat

    Miten sen lukemat kehittyivät?

  • Kokoteksti ja vektorit

    Mitkä tietueet vastaavat hakua tai tarkoittavat jotain samankaltaista?

Sovellus · API · MCP · chatOikeuksiin perustuva pääsy samaan loogiseen malliin

Käsitteellinen malli. Historialliset vastaukset vaativat myös säilytetyt lähdeversiot sekä haun, mallin ja kehotteen alkuperätiedot.

Käsitteellinen kuvitus yhdistetystä tiedosta ja omaisuuserän historiasta aikaulottuvuudessa
Sijainti, suhteet ja tieto ovat hyödyllisempiä, kun ne voidaan ymmärtää historiallisessa kontekstissaan.

Historia datalle – ja alkuperätiedot tekoälylle

Ajallinen data voi kuvata, miten omaisuuserä, sen lukemat tai suhteet muuttuvat. Historiallinen tekoälyvastaus vaatii enemmän: se riippuu myös lähdedokumenteista, upotuksista, hakukonfiguraatiosta, malliversiosta ja kehotteesta, joilla se tuotettiin.

Datahistorian säilyttäminen ei automaattisesti säilytä jokaista vektori-indeksiä eikä toista mennyttä mallin vastausta. Hyvä suunnittelu yhdistää nämä versiot ja kirjaa niiden alkuperän tietoisesti, jotta vastaus voi viitata takaisin sitä tukeneisiin perusteisiin ja kontekstiin.

Yksi perusta sovelluksille ja työkaluille

Suunnitellut natiivit MCP- ja chat-kyvykkyydet tarjoavat tavat julkaista sallittuja funktioita ja kysyä yhdistetystä tiedosta. Työkalun tai keskustelukäyttöliittymän pitäisi toimia saman mallin ja käyttöoikeuskäytännön varassa kuin sovellus. Historiallinen kysely voi silloin kohdistua valittuun ajankohtaan ja samalla kertoa, mitkä perusteet ja tekoälykonfiguraatio vastausta varten ovat saatavilla.

Tässä yhtenäinen taustajärjestelmä on enemmän kuin yksinkertaisempi käyttöönottotarina: se voi tarjota yhteisen perustan operatiiviselle datalle, liiketoiminnan historialle ja tekoälyavusteiselle työlle.

06 / Rajojen valinta

Pidä arkkitehtuuri linjassa työn kanssa.

Mikropalvelut ovat yhä hyödyllisiä, kun itsenäiset tiimit, erilliset tietoturvarajat tai erilaiset käyttövaatimukset sitä edellyttävät. Modulaarinen monoliitti on yhä hyödyllinen, kun yhteinen käyttöönotto pitää tiimin tuottavana. Cygnusin suunta tuo kolmannen vaihtoehdon: yhtenäinen sovellus- ja datamalli, jossa hajautusta hallitaan syvemmällä ajoympäristössä.

Oikea valinta alkaa työkuormasta. Mitkä pyynnöt hallitsevat? Kuinka nopeasti päivitysten on näyttävä? Mikä data kuuluu yhteen? Mitä tapahtuu verkkovian aikana? Mitkä vastuut tarvitsevat itsenäisen omistajan?

Tavoitteemme on, että kehittäjät voivat käyttää enemmän aikaa näihin merkityksellisiin päätöksiin ja vähemmän aikaa työkalujensa välisten yhteyksien uudelleenrakentamiseen. Aloita yhtenäisestä mallista. Pidä liiketoiminnan suhteet ehjinä. Kasvata fyysistä käyttöönottoa, kun työkuorma ja alusta ovat valmiita.

Lisälukemista