Sündmuste hankimise arhitektuur: põhjalik ülevaade domeeni sündmuste salvestussüsteemidest

Sündmuste hankimine on arhitektuurne muster, kus rakenduse olek määratakse sündmuste jadaga. Selle asemel, et salvestada olemite praegust olekut, säilitame me muutumatute sündmuste rea, mis esindavad selle olemiga seotud muudatusi. See blogipostitus uurib sündmuste hankimise arhitektuuri üksikasjalikult, keskendudes spetsiifiliselt domeeni sündmuste salvestussüsteemidele.

Mis on sündmuste hankimine?

Traditsioonilistes süsteemides salvestatakse olemite praegune olek otse andmebaasi. Kui toimub uuendus, muudetakse või kirjutatakse olemasolev kirje üle. See lähenemine toimib paljude rakenduste puhul hästi, kuid sellel on piirangud, kui:

• Auditid ja ajaloo jälgimine on üliolulised.
• Vaja on keerulisi olekuüleminekuid taastada.
• Vaja on reaalajas andmete levikut ja sündmustepõhiseid arhitektuure.

Sündmuste hankimine lahendab need piirangud, salvestades iga olekumuutuse muutumatuna sündmusena. Need sündmused säilitatakse ainult lisatavas sündmustepoes. Olemi praeguse oleku taastamiseks esitatakse sündmused uuesti selles järjekorras, milles need toimusid. Mõelge sellele nagu pearaamatule, kus iga tehing on registreeritud ja saldo arvutatakse kõigi tehingute summeerimise teel.

Põhikontseptsioonid

• Domeeni sündmus: Fakt, mis esindab midagi, mis on domeenis juhtunud. See on olekumuutuse muutumatu kirje. Näited: TellimusLoodud, TellimusSaadetud, MakseSaadud.
• Sündmustepood: Ainult lisatav andmehoidla, mis on optimeeritud domeeni sündmuste salvestamiseks ja toomiseks. See pakub mehhanisme sündmuste säilitamiseks, toomiseks ja tellimiseks.
• Sündmuste käitlejad: Komponendid, mis reageerivad domeeni sündmustele. Nad võivad uuendada lugemismudeleid, käivitada väliseid integratsioone või teha muid toiminguid.
• Lugemismudelid: Denormaliseeritud andmete esitused, mis on optimeeritud konkreetsete päringumustrite jaoks. Neid uuendavad sündmuste käitlejad ja need pakuvad andmete kirjutuskaitstud vaadet.
• Hetkeseisuga tegemine: Tehnika, mida kasutatakse oleku taastamise optimeerimiseks, säilitades perioodiliselt olemi praeguse oleku. Oleku taastamisel laadib süsteem viimase hetkeseisu ja esitab uuesti ainult sündmused, mis toimusid pärast hetkeseisu tegemist.

Sündmuste hankimise eelised

Sündmuste hankimine pakub mitmeid eeliseid võrreldes traditsiooniliste CRUD (Create, Read, Update, Delete) arhitektuuridega:

• Täielik auditi jälgi: Iga olekumuutus registreeritakse sündmusena, pakkudes rakenduse andmete põhjalikku ajalugu. See on hindamatu väärtusega auditeerimiseks, silumiseks ja vastavuseks.
• Ajalised päringud: Võimalus päringutele vastata olemi olekule igal ajahetkel. See võimaldab ajalugu analüüsida ja aruandeid koostada. Näiteks saate määrata konkreetse piirkonna tellimuste arvu konkreetsel kuupäeval.
• Lihtsustatud silumine: Sündmuste uuesti esitamisega saate rakenduse mis tahes varasema oleku taastada, muutes vigade tuvastamise ja parandamise lihtsamaks.
• Parema jõudluse saavutamine teatud toimingute puhul: Kuigi oleku taastamine võib olla aeglasem, saab lugemismudeleid konkreetsete päringumustrite jaoks väga optimeerida.
• Sündmustepõhine arhitektuur: Sündmuste hankimine sobib loomulikult sündmustepõhiste arhitektuuridega, võimaldades reaalajas andmete levikut ja integratsiooni teiste süsteemidega.
• Lihtsam arendamine: Uute funktsioonide lisamine või olemasolevate muutmine on sageli lihtsam, kuna saate lihtsalt uusi sündmuste käitlejaid lisada, mõjutamata olemasolevat sündmuste voogu.
• Suurem skaleeritavus: Sündmuste töötlemise jaotamine mitme sõlme vahel võib parandada skaleeritavust ja vastupidavust.

Sündmuste hankimise väljakutsed

Sündmuste hankimine esitab ka mõningaid väljakutseid, mida tuleb hoolikalt kaaluda:

• Keerukus: Sündmuste hankimise rakendamine nõuab teistsugust mõtteviisi ja sügavamat arusaamist domeeni modelleerimisest ja sündmustepõhistest põhimõtetest.
• Lõplik järjepidevus: Lugemismudelid on lõpuks järjepidevad sündmuste poega, mis võib kasutajaliideses põhjustada viivitusi ja ebakõlasid. Vaja on rakendada lõpliku järjepidevuse haldamise strateegiaid, nagu optimistlik lukustamine või kompensatsioonitehingud.
• Sündmuste versioonimine: Rakenduse arenedes võib domeeni sündmuste struktuur muutuda. Vaja on rakendada sündmuste versioonimise strateegiaid, nagu sündmuste migreerimine või skeemi areng, et tagada tagasiühilduvus.
• Oleku taastamine: Olemi oleku taastamine sündmuste uuesti esitamisega võib olla aeganõudev, eriti olemite puhul, millel on suur hulk sündmusi. Hetkeseisu tegemine aitab seda probleemi leevendada.
• Õige sündmuste poe valimine: Rakenduse jõudluse, skaleeritavuse ja töökindluse nõuetele vastava sündmuste poe valimine on ülioluline.

Domeeni sündmuste salvestussüsteemid: võrdlev ülevaade

Sündmustepood on sündmuste hankimise süsteemi süda. See vastutab domeeni sündmuste säilitamise ja toomise eest. Sündmustepoe valik sõltub erinevatest teguritest, sealhulgas rakenduse jõudlusnõuetest, skaleeritavuse vajadustest, andmete järjepidevuse garantiidest ja eelarvepiirangutest. Siin on erinevate sündmuste salvestussüsteemide võrdlev ülevaade:

1. Relatsioonilised andmebaasid (SQL)

Relatsioonilisi andmebaase, nagu PostgreSQL, MySQL ja SQL Server, saab kasutada sündmuste poodidena. Kuigi need pakuvad ACID (Aatomi-, Järjepidevus-, Isolatsioon-, Püsivus-) omadusi ja tugevat andmete järjepidevust, ei pruugi need olla kõige tõhusam valik suure läbilaskevõimega sündmuste töötlemiseks.

Plussid:

• ACID omadused: Tagab andmete terviklikkuse ja järjepidevuse.
• Küps tehnoloogia: Hästi väljakujunenud tehnoloogia ulatusliku tööriistade ja toega.
• Tuttavus: Enamik arendajaid on relatsiooniliste andmebaasidega tuttavad.
• Tugev järjepidevus: Pakub tugevaid järjepidevuse garantiisid.

Miinused:

• Jõudluse kitsaskohad: Võivad muutuda jõudluse kitsaskohaks suure mahuga sündmuste voogude puhul.
• Skeemi arengu väljakutsed: Skeemimuudatuste käsitlemine võib olla keeruline ja nõuda hoolikat planeerimist.
• Skaleeritavuse piirangud: Relatsiooniliste andmebaaside skaleerimine võib olla keeruline, eriti kirjutustööd nõudvate töökoormuste puhul.
• Ei ole optimeeritud ainult lisatavate toimingute jaoks: Relatsioonilised andmebaasid ei ole spetsiaalselt loodud ainult lisatavate toimingute jaoks, mis võib jõudlust mõjutada.

Rakendusnäide (PostgreSQL):

Looge tabel domeeni sündmuste salvestamiseks:

            CREATE TABLE events (
  event_id UUID PRIMARY KEY,
  aggregate_id UUID NOT NULL,
  event_type VARCHAR(255) NOT NULL,
  event_data JSONB NOT NULL,
  created_at TIMESTAMP WITHOUT TIME ZONE NOT NULL DEFAULT (NOW() AT TIME ZONE 'utc')
);

            

              
                Copy
              
            
          

Sisestage uus sündmus:

            INSERT INTO events (event_id, aggregate_id, event_type, event_data)
VALUES (uuid_generate_v4(), 'a1b2c3d4-e5f6-7890-1234-567890abcdef', 'OrderCreated', '{"orderId": "ORD-123", "customerId": "CUST-456", "amount": 100}');

            

              
                Copy
              
            
          

2. NoSQL-andmebaasid

NoSQL-andmebaasid, nagu MongoDB, Cassandra ja Couchbase, pakuvad rohkem paindlikkust ja skaleeritavust võrreldes relatsiooniliste andmebaasidega. Need sobivad hästi suuremahuliste sündmuste voogude käsitlemiseks, kuid need võivad pakkuda nõrgemaid andmete järjepidevuse garantiisid.

Plussid:

• Skaleeritavus: Loodud horisontaalseks skaleerimiseks ja suudavad hallata suuri andmemahte.
• Paindlikkus: Skeemita või paindlik skeem võimaldab lihtsamat sündmuste versioonimist.
• Jõudlus: Optimeeritud suure läbilaskevõimega lugemis- ja kirjutustoimingute jaoks.
• Kuluefektiivne: Võib olla kuluefektiivsem kui relatsioonilised andmebaasid teatud töökoormuste puhul.

Miinused:

• Lõplik järjepidevus: Võib pakkuda nõrgemaid andmete järjepidevuse garantiisid võrreldes relatsiooniliste andmebaasidega.
• Keerukus: Nõuab sügavamat arusaamist NoSQL-andmebaasi kontseptsioonidest ja andmete modelleerimise tehnikatest.
• Küpsus: Mõned NoSQL-andmebaasid on vähem küpsed kui relatsioonilised andmebaasid.
• Päringuvõimaluste piirangud: Päringuvõimalused võivad olla piiratud võrreldes relatsiooniliste andmebaasidega.

Rakendusnäide (MongoDB):

Salvestage domeeni sündmused kollektsiooni:

            {
  "event_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "aggregate_id": "f1g2h3i4-j5k6-l7m8-n9o0-p1q2r3s4t5uv",
  "event_type": "OrderCreated",
  "event_data": {
    "orderId": "ORD-123",
    "customerId": "CUST-456",
    "amount": 100
  },
  "created_at": ISODate("2023-10-27T10:00:00.000Z")
}

            

              
                Copy
              
            
          

3. Spetsialiseerunud sündmuste poodid

Spetsialiseerunud sündmuste poodid, nagu EventStoreDB ja AxonDB, on loodud spetsiaalselt sündmuste hankimiseks. Need pakuvad funktsioone, nagu ainult lisatav salvestus, sündmuste versioonimine ja voogude haldamine. Need andmebaasid on tavaliselt parim valik, kui suhtute sündmuste hankimisse tõsiselt.

Plussid:

• Optimeeritud sündmuste hankimiseks: Loodud spetsiaalselt sündmuste hankimiseks, kasutades selliseid funktsioone nagu ainult lisatav salvestus, voogude haldamine ja sündmuste versioonimine.
• Suur jõudlus: Optimeeritud suure läbilaskevõimega sündmuste töötlemiseks.
• Lõpliku järjepidevuse haldamine: Sisseehitatud mehhanismid lõpliku järjepidevuse haldamiseks.
• Voogude haldamine: Lihtsustab sündmuste voo haldamist ja päringuid.

Miinused:

• Müüja lukustumise: Võib tutvustada müüja lukustumist.
• Kulu: Võib olla kallim kui muud valikud.
• Õppekõver: Nõuab uue tehnoloogia õppimist.
• Piiratud kasutuselevõtt: Vähem laialdaselt kasutusele võetud kui relatsioonilised ja NoSQL-andmebaasid.

Rakendusnäide (EventStoreDB):

EventStoreDB kasutab sündmuste salvestamiseks vooge. Sündmusi saate voole lisada, kasutades EventStoreDB klienditeeki.

4. Sõnumijärjekorrad (Kafka, RabbitMQ)

Sõnumijärjekordi, nagu Apache Kafka ja RabbitMQ, saab kasutada sündmuste poodidena, eriti koos voogude töötlemise raamistikega. Need pakuvad suurt läbilaskevõimet, skaleeritavust ja tõrketaluvust, muutes need sobivaks suuremahuliste sündmustepõhiste rakenduste jaoks. Need on aga üldiselt rohkem mööduva transpordimehhanismina kui püsiva poena.

Plussid:

• Suur läbilaskevõime: Loodud suure läbilaskevõimega sõnumite töötlemiseks.
• Skaleeritavus: Väga skaleeritav ja suudab hallata suuri sündmuste mahte.
• Tõrketaluvus: Sisseehitatud tõrketaluvusmehhanismid.
• Reaalajas töötlemine: Võimaldab reaalajas sündmuste töötlemist.

Miinused:

• Keerukus: Nõuab sügavamat arusaamist sõnumijärjekorra kontseptsioonidest ja voogude töötlemise raamistikest.
• Andmete püsivus: Andmete püsivus tuleb hoolikalt seadistada.
• Sündmuste taasesitus: Sündmuste taasesitus võib olla keerulisem kui spetsialiseerunud sündmuste poodidega.
• Tellimuse garantiid: Tellimuse garantiid võivad olla piiratud sõltuvalt konfiguratsioonist.

Rakendusnäide (Apache Kafka):

Avaldamine domeeni sündmused Kafka teemas:

            // Tootja konfiguratsioon
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);

// Loo kirje
ProducerRecord<String, String> record = new ProducerRecord<>("order-events", "ORD-123", "{"event_type": "OrderCreated", "customerId": "CUST-456", "amount": 100}");

// Saada kirje
producer.send(record);

producer.close();

            

              
                Copy
              
            
          

5. Pilvepõhised sündmuste poodid

Pilvepakkujad pakuvad hallatavaid sündmuste poodide teenuseid, nagu Azure Event Hubs, AWS Kinesis ja Google Cloud Pub/Sub. Need teenused pakuvad skaleeritavust, töökindlust ja kasutuslihtsust, muutes need hea valikuks pilvepõhistele rakendustele.

Plussid:

• Skaleeritavus: Väga skaleeritav ja suudab hallata suuri sündmuste mahte.
• Töökindlus: Sisseehitatud töökindlus ja tõrketaluvus.
• Kasutuslihtsus: Hallatavad teenused lihtsustavad juurutamist ja hooldust.
• Integratsioon: Sujuv integratsioon teiste pilveteenustega.

Miinused:

• Müüja lukustumise: Tutvustab müüja lukustumist.
• Kulu: Võib olla kallim kui isehallatavad lahendused.
• Latentsus: Võrgu latentsus võib jõudlust mõjutada.
• Juhtimine: Vähem kontrolli aluseks oleva infrastruktuuri üle.

Jõudluse kaalutlused

Jõudlus on domeeni sündmuste salvestussüsteemi valimisel kriitiline tegur. Siin on mõned jõudluse kaalutlused, mida meeles pidada:

• Kirjutamise läbilaskevõime: Võime käsitseda suurt hulka sissetulevaid sündmusi.
• Lugemise latentsus: Aeg, mis kulub sündmuste toomiseks ja olemi oleku taastamiseks.
• Konkurents: Võime käsitseda samaaegseid lugemis- ja kirjutustoiminguid.
• Salvestusmaht: Sündmuste salvestamiseks vajaminev salvestusruumi hulk.
• Võrgu latentsus: Latentsus rakenduse ja sündmuste poe vahel.

Jõudluse optimeerimiseks kaaluge järgmisi tehnikaid:

• Patside tegemine: Sündmuste partii tegemine enne nende sündmustepoodi kirjutamist võib parandada kirjutamise läbilaskevõimet.
• Vahemällu salvestamine: Sagedasti kasutatavate sündmuste vahemällu salvestamine võib vähendada lugemise latentsust.
• Hetkeseisu tegemine: Hetkeseisu tegemine võib vähendada sündmuste arvu, mis tuleb olemi oleku taastamisel uuesti esitada.
• Indekseerimine: Sündmuste indekseerimine agregeerimise ID ja muude asjakohaste atribuutide põhjal võib parandada päringute jõudlust.
• Sharding: Sündmustepoe jagamine mitme sõlme vahel võib parandada skaleeritavust ja jõudlust.

Andmete terviklikkus

Andmete terviklikkus on sündmuste hankimisel ülimalt oluline. On ülioluline tagada, et sündmused säiliksid usaldusväärselt ja õiges järjekorras. Siin on mõned strateegiad andmete terviklikkuse säilitamiseks:

• Tehingud: Kasutage tehinguid, et tagada sündmuste atomiline kirjutamine sündmustepoodi.
• Idempotentsus: Kujundage sündmuste käitlejad idempotentseks, mis tähendab, et nad saavad sama sündmust töödelda mitu korda, põhjustamata soovimatuid kõrvalmõjusid.
• Optimistlik lukustamine: Kasutage optimistlikku lukustust, et vältida sama agregatsiooni samaaegseid värskendusi.
• Sündmuste valideerimine: Valideerige sündmused enne nende sündmustepoodi säilitamist, et tagada nende kehtivus ja järjepidevus.
• Kontrollsummad: Arvutage sündmuste kontrollsummad ja salvestage need koos sündmustega. Kontrollige kontrollsummasid sündmuste toomisel, et tagada nende mitte kahjustamine.

Sündmuste versioonimine

Rakenduse arenedes võib domeeni sündmuste struktuur muutuda. Sündmuste versioonimise käsitlemine on tagasiühilduvuse tagamiseks ja andmete kadumise vältimiseks ülioluline. Siin on mõned strateegiad sündmuste versioonimise käsitlemiseks:

• Sündmuste üleskastmine: Teisendage vanemad sündmuste versioonid uusimaks versiooniks, kui neid sündmuste poest loete.
• Skeemi areng: Arendage sündmuste skeemi aja jooksul, lisades uusi välju või muutes olemasolevaid. Veenduge, et vanemaid sündmuste versioone saab siiski õigesti töödelda.
• Sündmuste migreerimine: Migreerige vanemad sündmused uusimale skeemi versioonile. Seda saab teha taustaprotsessina.

Reaalmaailma näited

Sündmuste hankimist kasutatakse mitmesugustes tööstusharudes ja rakendustes. Siin on mõned reaalmaailma näited:

• E-kaubandus: Tellimuste ajaloo, varude muutuste ja kliendi tegevuse jälgimine. Näiteks ülemaailmne e-kaubanduse platvorm võib kasutada sündmuste hankimist tellimuste jälgimiseks erinevatest riikidest, valuutavahetuste käsitlemiseks ja varude haldamiseks mitmes laos.
• Pangandus: Tehingute salvestamine, kontode saldode jälgimine ja finantstegevuse auditeerimine. Rahvusvaheline pank võiks kasutada sündmuste hankimist tehingute jälgimiseks erinevatest filiaalidest ja valuutadest, tagades täieliku auditi jälje.
• Mängud: Mängijate tegevuste, mängu olekumuutuste ja sündmuste ajaloo jälgimine. Online-multimeeskonnamängud kasutavad sageli sündmuste hankimist, et säilitada ühtlane mängu olek mitme mängija ja serveri vahel.
• Tarneahela haldamine: Toote liikumiste, varude tasemete ja tarnegraafikute jälgimine. Ülemaailmne logistikaettevõte saab kasutada sündmuste hankimist saadetiste jälgimiseks erinevates riikides, tollivormistuse käsitlemiseks ja tarnegraafikute haldamiseks.

Õige salvestussüsteemi valimine: otsustusmaatriks

Et aidata teil otsustada, milline domeeni sündmuste salvestussüsteem on teie rakenduse jaoks õige, kaaluge järgmist otsustusmaatriksit:

Rakendatavad teadmised

Siin on mõned rakendatavad teadmised sündmuste hankimise rakendamiseks:

• Alustage väikesest: Alustage väikesest, hästi määratletud domeenist, et saada kogemusi sündmuste hankimisega, enne kui rakendate seda suurematele, keerukamate domeenidele.
• Keskenduge domeenile: Modelleerige hoolikalt oma domeeni ja tuvastage peamised domeeni sündmused.
• Valige õige salvestussüsteem: Valige sündmuste pood, mis vastab teie rakenduse jõudluse, skaleeritavuse ja andmete järjepidevuse nõuetele.
• Rakendage sündmuste versioonimine: Planeerige sündmuste versioonimine algusest peale, et tagada tagasiühilduvus.
• Jälgige jõudlust: Jälgige oma sündmuste poe ja sündmuste käitlejate jõudlust, et tuvastada potentsiaalseid kitsaskohti.
• Automatiseerige juurutamine: Automatiseerige oma sündmuste hankimise infrastruktuuri juurutamine ja haldamine.
• Kaaluge kompromisse: Sündmuste hankimine hõlmab kompromisse. Mõistke, et mustrist tulenevate eeliste saavutamiseks tekivad keerukused.

Järeldus

Sündmuste hankimine on võimas arhitektuurne muster, mis pakub arvukalt eeliseid, sealhulgas täielik auditi jälgi, ajalisi päringuid ja paremat jõudlust teatud toimingute jaoks. Samas esitab see ka väljakutseid, mida tuleb hoolikalt kaaluda, nagu keerukus, lõplik järjepidevus ja sündmuste versioonimine. Valides hoolikalt domeeni sündmuste salvestussüsteemi ja rakendades parimaid tavasid, saate edukalt kasutada sündmuste hankimist skaleeritavate, vastupidavate ja auditeeritavate rakenduste loomiseks.

See juhend andis ülevaate sündmuste hankimisest ja mitmetest populaarsetest domeeni sündmuste salvestussüsteemidest. Valige parim süsteem, et vastata oma projekti erivajadustele.

Pidage meeles, et see sisu on mõeldud ülemaailmsele publikule, seega kohandage ja rakendage kontseptsioone oma ainulaadsetele asjaoludele ja kultuurikontekstile. Sündmuste hankimise põhimõtted on universaalsed, kuid rakendamine võib varieeruda sõltuvalt teie konkreetsetest vajadustest ja ressurssidest.