Event Sourcing -arkkitehtuuri: Syväsukellus domain-tapahtumien tallennusjärjestelmiin

Event Sourcing on arkkitehtoninen malli, jossa sovelluksen tila määritellään tapahtumien sekvenssinä. Sen sijaan, että tallennettaisiin entiteetin nykyinen tila, säilytämme sarjan muuttumattomia tapahtumia, jotka edustavat muutoksia kyseiseen entiteettiin. Tämä blogikirjoitus tutkii Event Sourcing -arkkitehtuuria yksityiskohtaisesti, keskittyen erityisesti domain-tapahtumien tallennusjärjestelmiin.

Mikä on Event Sourcing?

Perinteisissä järjestelmissä entiteetin nykyinen tila tallennetaan suoraan tietokantaan. Kun päivitys tapahtuu, olemassa oleva tietue muokataan tai ylikirjoitetaan. Tämä lähestymistapa toimii hyvin monissa sovelluksissa, mutta sillä on rajoituksia, kun:

• Tarkastus ja historiatiedon seuranta ovat ratkaisevan tärkeitä.
• Monimutkaiset tilanmuutokset on rekonstruoitava.
• Reaaliaikainen tietojen levitys ja tapahtumapohjaiset arkkitehtuurit ovat välttämättömiä.

Event Sourcing ratkaisee nämä rajoitukset tallentamalla jokaisen tilanmuutoksen muuttumattomana tapahtumana. Nämä tapahtumat tallennetaan vain liitettävään (append-only) tapahtumakauppaan (event store). Entiteetin nykyisen tilan rekonstruoimiseksi tapahtumat toistetaan siinä järjestyksessä, jossa ne tapahtuivat. Ajattele sitä kirjanpitona, johon jokainen tapahtuma tallennetaan ja saldo lasketaan summaamalla kaikki tapahtumat.

Keskeiset käsitteet

• Domain-tapahtuma: Totuus, joka edustaa jotain, mitä on tapahtunut domainissa. Se on muuttumaton kirjaus tilanmuutoksesta. Esimerkkejä ovat OrderCreated (TilausLuotu), OrderShipped (TilausLähetetty), PaymentReceived (MaksuVastaanotettu).
• Tapahtumakauppa (Event Store): Vain liitettävä datatallennusjärjestelmä, joka on optimoitu domain-tapahtumien tallentamiseen ja hakemiseen. Se tarjoaa mekanismit tapahtumien säilytykseen, hakuun ja tilaukseen.
• Tapahtumankäsittelijät (Event Handlers): Komponentit, jotka reagoivat domain-tapahtumiin. Ne voivat päivittää lukumalleja (read models), käynnistää ulkoisia integraatioita tai suorittaa muita toimintoja.
• Lukumallit (Read Models): Denormalisoidut datan esitykset, jotka on optimoitu tietyille kyselymalleille. Tapahtumankäsittelijät päivittävät niitä ja ne tarjoavat vain luku -näkymän datasta.
• Tilannekuvaus (Snapshotting): Tekniikka, jota käytetään tilan rekonstruoinnin optimointiin tallentamalla ajoittain entiteetin nykyinen tila. Tilaa rekonstruoidessa järjestelmä lataa viimeisimmän tilannekuvan ja toistaa vain ne tapahtumat, jotka tapahtuivat tilannekuvan ottamisen jälkeen.

Event Sourcingin hyödyt

Event Sourcing tarjoaa useita etuja perinteisiin CRUD (Create, Read, Update, Delete) -arkkitehtuureihin verrattuna:

• Täydellinen tarkastuspolku: Jokainen tilanmuutos tallennetaan tapahtumana, mikä tarjoaa kattavan historian sovelluksen tiedoista. Tämä on korvaamatonta tarkastuksessa, vianetsinnässä ja säännösten noudattamisessa.
• Ajalliset kyselyt: Mahdollisuus kysellä entiteetin tilaa milloin tahansa. Tämä mahdollistaa historiallisten analyysien ja raportoinnin. Voit esimerkiksi määrittää tietyn alueen tilausten määrän tiettynä päivänä.
• Yksinkertaistettu vianetsintä: Toistamalla tapahtumia voit luoda uudelleen minkä tahansa aiemman sovelluksen tilan, mikä helpottaa virheiden tunnistamista ja korjaamista.
• Parannettu suorituskyky tietyissä toiminnoissa: Vaikka tilan rekonstruointi voi olla hitaampaa, lukumallien päivittäminen voidaan optimoida tehokkaasti tiettyjä kyselymalleja varten.
• Tapahtumapohjainen arkkitehtuuri: Event Sourcing sopii luonnostaan tapahtumapohjaisiin arkkitehtuureihin, mahdollistaen reaaliaikaisen tietojen levityksen ja integraation muihin järjestelmiin.
• Helpompi kehitys: Uusien ominaisuuksien lisääminen tai olemassa olevien muokkaaminen on usein helpompaa, koska voit yksinkertaisesti lisätä uusia tapahtumankäsittelijöitä vaikuttamatta olemassa olevaan tapahtumavirtaan.
• Parannettu skaalautuvuus: Tapahtumankäsittelyn jakaminen useisiin solmuihin voi parantaa skaalautuvuutta ja vikasietoisuutta.

Event Sourcingin haasteet

Event Sourcingiin liittyy myös joitakin haasteita, jotka on otettava huolellisesti huomioon:

• Monimutkaisuus: Event Sourcingin toteuttaminen vaatii erilaista ajattelutapaa ja syvempää ymmärrystä domain-mallinnuksesta ja tapahtumapohjaisista periaatteista.
• Lopullinen johdonmukaisuus (Eventual Consistency): Lukumallit ovat lopullisesti johdonmukaisia tapahtumakaupan kanssa, mikä voi aiheuttaa viiveitä ja epäjohdonmukaisuuksia käyttöliittymässä. Strategiat lopullisen johdonmukaisuuden hallintaan, kuten optimistinen lukitus tai korvaavat tapahtumat (compensating transactions), on toteutettava.
• Tapahtumien versiointi: Sovelluksen kehittyessä domain-tapahtumien rakenne voi muuttua. Tapahtumien versioinnin käsittelyyn, kuten tapahtumien siirtoon tai skeeman kehitykseen, on toteutettava strategiat taaksepäin yhteensopivuuden varmistamiseksi.
• Tilan rekonstruointi: Entiteetin tilan rekonstruointi tapahtumia toistamalla voi olla aikaa vievää, erityisesti entiteeteille, joilla on suuri määrä tapahtumia. Tilannekuvaus voi auttaa lieventämään tätä ongelmaa.
• Oikean tapahtumakaupan valinta: Sopivan tapahtumakaupan valinta, joka täyttää sovelluksen suorituskyky-, skaalautuvuus- ja luotettavuusvaatimukset, on ratkaisevan tärkeää.

Domain-tapahtumien tallennusjärjestelmät: Vertailu

1. Relaatiotietokannat (SQL)

Edut:

• ACID-ominaisuudet: Varmistaa tietojen eheyden ja johdonmukaisuuden.
• Kypsä teknologia: Vakiintunut teknologia laajoilla työkaluilla ja tuella.
• Tutuntuus: Useimmat kehittäjät tuntevat relaatiotietokannat.
• Vahva johdonmukaisuus: Tarjoaa vahvat johdonmukaisuus taeet.

Haitat:

• Suorituskyky pullonkaulat: Voi muodostua suorituskyvyn pullonkaulaksi korkean volyymin tapahtumavirroille.
• Skeeman kehityksen haasteet: Skeemamuutosten käsittely voi olla monimutkaista ja vaatia huolellista suunnittelua.
• Skaalautuvuus rajoitukset: Relaatiotietokantojen skaalaaminen voi olla haastavaa, erityisesti kirjoitusintensiivisille työkuormille.
• Ei optimoitu vain liitettäville toiminnoille: Relaatiotietokannat eivät ole erityisesti suunniteltu vain liitettäville toiminnoille, mikä voi vaikuttaa suorituskykyyn.

Toteutusesimerkki (PostgreSQL):

Luo taulu domain-tapahtumien tallentamiseen:

            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
              
            
          

Lisää uusi tapahtuma:

            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-tietokannat

NoSQL-tietokannat, kuten MongoDB, Cassandra ja Couchbase, tarjoavat enemmän joustavuutta ja skaalautuvuutta kuin relaatiotietokannat. Ne sopivat hyvin suurten tapahtumavirtojen käsittelyyn, mutta ne voivat tarjota heikompia datan johdonmukaisuus taeita.

Edut:

• Skaalautuvuus: Suunniteltu horisontaaliseen skaalautuvuuteen ja pystyy käsittelemään suuria datamääriä.
• Joustavuus: Skeematon tai joustava skeema mahdollistaa helpomman tapahtumien versioinnin.
• Suorituskyky: Optimoitu suurivolyymisiin luku- ja kirjoitusoperaatioihin.
• Kustannustehokas: Voi olla kustannustehokkaampi kuin relaatiotietokannat tietyissä työkuormissa.

Haitat:

• Lopullinen johdonmukaisuus: Voi tarjota heikompia datan johdonmukaisuus taeita verrattuna relaatiotietokantoihin.
• Monimutkaisuus: Vaatii syvempää ymmärrystä NoSQL-tietokantojen käsitteistä ja datan mallinnustekniikoista.
• Kypsyys: Jotkut NoSQL-tietokannat ovat vähemmän kypsiä kuin relaatiotietokannat.
• Kyselyrajoitukset: Kyselyominaisuudet voivat olla rajalliset verrattuna relaatiotietokantoihin.

Toteutusesimerkki (MongoDB):

Tallenna domain-tapahtumat kokoelmaan:

            {
  "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. Erikoistuneet tapahtumakaupat

Erikoistuneet tapahtumakaupat, kuten EventStoreDB ja AxonDB, on suunniteltu erityisesti Event Sourcingia varten. Ne tarjoavat ominaisuuksia, kuten vain liitettävä tallennus, tapahtumien versiointi ja virranhallinta. Nämä tietokannat ovat yleensä paras valinta, jos suhtaudut vakavasti Event Sourcingiin.

Edut:

• Optimoitu Event Sourcingille: Suunniteltu erityisesti Event Sourcingille, sisältäen ominaisuuksia, kuten vain liitettävä tallennus, virranhallinta ja tapahtumien versiointi.
• Korkea suorituskyky: Optimoitu suurivolyymiseen tapahtumien käsittelyyn.
• Lopullisen johdonmukaisuuden käsittely: Sisäänrakennetut mekanismit lopullisen johdonmukaisuuden käsittelyyn.
• Virranhallinta: Yksinkertaistaa tapahtumavirran hallintaa ja kyselyä.

Haitat:

• Toimittajalukko: Voi aiheuttaa toimittajalukon.
• Kustannukset: Voi olla kalliimpi kuin muut vaihtoehdot.
• Oppimiskäyrä: Vaatii uuden teknologian opettelua.
• Vähäinen käyttöönotto: Vähemmän laajasti käytössä kuin relaatio- ja NoSQL-tietokannat.

Toteutusesimerkki (EventStoreDB):

EventStoreDB käyttää virtoja (streams) tapahtumien tallentamiseen. Voit liittää tapahtumia virtaan EventStoreDB-asiakaskirjaston avulla.

4. Viestijonot (Kafka, RabbitMQ)

Viestijonoja, kuten Apache Kafka ja RabbitMQ, voidaan käyttää tapahtumakauppoina, erityisesti yhdessä virrankäsittelykehysten kanssa. Ne tarjoavat suuren läpimenon, skaalautuvuuden ja vikasietoisuuden, mikä tekee niistä sopivia suuriin tapahtumapohjaisiin sovelluksiin. Niitä käytetään kuitenkin yleensä enemmän väliaikaisena kuljetusmekanismina kuin pysyvänä tallennuksena.

Edut:

• Suuri läpimeno: Suunniteltu suurivolyymiseen viestien käsittelyyn.
• Skaalautuvuus: Erittäin skaalautuvia ja pystyy käsittelemään suuria tapahtumamääriä.
• Vikasietoisuus: Sisäänrakennetut vikasietoisuusmekanismit.
• Reaaliaikainen käsittely: Mahdollistaa reaaliaikaisen tapahtumien käsittelyn.

Haitat:

• Monimutkaisuus: Vaatii syvempää ymmärrystä viestijonojen käsitteistä ja virrankäsittelykehyksistä.
• Tietojen kestävyys: Tietojen kestävyys on määritettävä huolellisesti.
• Tapahtumien uudelleentoisto: Tapahtumien uudelleentoisto voi olla monimutkaisempaa kuin erikoistuneilla tapahtumakaupoilla.
• Järjestystakuut: Järjestystakuut voivat olla rajalliset riippuen konfiguraatiosta.

Toteutusesimerkki (Apache Kafka):

Julkaise domain-tapahtumat Kafka-aiheeseen (topic):

            // Tuottajan konfiguraatio
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);

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

// Lähetetään tietue
producer.send(record);

producer.close();

            

              
                Copy
              
            
          

5. Pilvipohjaiset tapahtumakaupat

Pilvipalveluntarjoajat tarjoavat hallinnoituja tapahtumakauppapalveluita, kuten Azure Event Hubs, AWS Kinesis ja Google Cloud Pub/Sub. Nämä palvelut tarjoavat skaalautuvuutta, luotettavuutta ja helppokäyttöisyyttä, mikä tekee niistä hyvän valinnan pilvinatiiveille sovelluksille.

Edut:

• Skaalautuvuus: Erittäin skaalautuvia ja pystyy käsittelemään suuria tapahtumamääriä.
• Luotettavuus: Sisäänrakennettu luotettavuus ja vikasietoisuus.
• Helppokäyttöisyys: Hallinnoidut palvelut yksinkertaistavat käyttöönottoa ja ylläpitoa.
• Integraatio: Saumaton integraatio muihin pilvipalveluihin.

Haitat:

• Toimittajalukko: Aiheuttaa toimittajalukon.
• Kustannukset: Voi olla kalliimpi kuin itse hallinnoidut ratkaisut.
• Latenssi: Verkko-latenssi voi vaikuttaa suorituskykyyn.
• Hallinta: Vähemmän hallintaa perustana olevaan infrastruktuuriin.

Suorituskyvyn huomioitavat seikat

Suorituskyky on kriittinen tekijä domain-tapahtumien tallennusjärjestelmää valittaessa. Tässä on joitain suorituskykyyn liittyviä näkökohtia, jotka on syytä ottaa huomioon:

• Kirjoitusläpimeno: Kyky käsitellä suuria määriä saapuvia tapahtumia.
• Lukuviive: Aika, joka kuluu tapahtumien hakemiseen ja entiteetin tilan rekonstruointiin.
• Samanaikaisuus: Kyky käsitellä samanaikaisia luku- ja kirjoitusoperaatioita.
• Tallennuskapasiteetti: Tapahtumien tallentamiseen tarvittava tallennustila.
• Verkon latenssi: Latenssi sovelluksen ja tapahtumakaupan välillä.

Suorituskyvyn optimoimiseksi harkitse seuraavia tekniikoita:

• Eräajo (Batching): Tapahtumien eräajo ennen niiden kirjoittamista tapahtumakauppaan voi parantaa kirjoitusläpimenoa.
• Välimuisti (Caching): Usein käytettyjen tapahtumien välimuistitus voi vähentää lukuviivettä.
• Tilannekuvaus (Snapshotting): Tilannekuvaus voi vähentää toistettavien tapahtumien määrää entiteetin tilan rekonstruoinnin yhteydessä.
• Indeksointi: Tapahtumien indeksointi aggregointitunnisteen ja muiden relevanttien attribuuttien perusteella voi parantaa kyselysuorituskykyä.
• Osiointi (Sharding): Tapahtumakaupan osiointi useiden solmujen kesken voi parantaa skaalautuvuutta ja suorituskykyä.

Tietojen eheys

Tietojen eheys on ensiarvoisen tärkeää Event Sourcingissa. On ratkaisevan tärkeää varmistaa, että tapahtumat tallennetaan luotettavasti ja oikeassa järjestyksessä. Tässä on joitain strategioita tietojen eheyden ylläpitämiseksi:

• Transaktiot: Käytä transaktioita varmistaaksesi, että tapahtumat kirjoitetaan atomisesti tapahtumakauppaan.
• Idempotenssi: Suunnittele tapahtumankäsittelijät idempotenttisiksi, eli ne voivat käsitellä saman tapahtuman useita kertoja aiheuttamatta tahattomia sivuvaikutuksia.
• Optimistinen lukitus: Käytä optimistista lukitusta estääksesi samanaikaiset päivitykset samaan aggregointiin.
• Tapahtumien validointi: Validoi tapahtumat ennen niiden tallentamista tapahtumakauppaan varmistaaksesi, että ne ovat kelvollisia ja johdonmukaisia.
• Tarkistussummat (Checksums): Laske tapahtumille tarkistussummat ja tallenna ne tapahtumien rinnalle. Tarkista tarkistussummat tapahtumia haettaessa varmistaaksesi, etteivät ne ole vioittuneet.

Tapahtumien versiointi

Sovelluksen kehittyessä domain-tapahtumien rakenne voi muuttua. Tapahtumien versioinnin käsittely on ratkaisevan tärkeää taaksepäin yhteensopivuuden varmistamiseksi ja tietojen menetyksen estämiseksi. Tässä on joitain strategioita tapahtumien versioinnin käsittelyyn:

• Tapahtumien ylöspäin päivitys (Event Upcasting): Muunna vanhemmat tapahtumaversiot uusimmaksi versioksi luettaessa niitä tapahtumakaupasta.
• Skeeman kehitys: Kehitä tapahtumaskeemaa ajan myötä lisäämällä uusia kenttiä tai muokkaamalla olemassa olevia. Varmista, että vanhemmat tapahtumaversiot voidaan edelleen käsitellä oikein.
• Tapahtumien siirto (Event Migration): Siirrä vanhemmat tapahtumat uusimpaan skeemaversioon. Tämä voidaan tehdä taustaprosessina.

Todellisen maailman esimerkkejä

Event Sourcingia käytetään monilla eri teollisuudenaloilla ja sovelluksissa. Tässä on muutamia todellisen maailman esimerkkejä:

• Verkkokauppa: Tilaushistorian, varastomuutosten ja asiakasaktiivisuuden seuranta. Esimerkiksi globaali verkkokauppa-alusta voi käyttää Event Sourcingia eri maiden tilausten seuraamiseen, valuutanmuunnosten käsittelyyn ja varaston hallintaan useissa varastoissa.
• Pankkitoiminta: Tapahtumien kirjaaminen, tilien saldojen seuranta ja taloudellisen toiminnan tarkastus. Monikansallinen pankki voisi käyttää Event Sourcingia tapahtumien seuraamiseen eri konttoreissa ja valuutoissa, varmistaen täydellisen tarkastuspolun.
• Pelaaminen: Pelaajatoimintojen, pelitilan muutosten ja tapahtumahistorian seuranta. Online-moninpelit käyttävät usein Event Sourcingia yhtenäisen pelitilan ylläpitämiseksi useiden pelaajien ja palvelinten välillä.
• Toimitusketjun hallinta: Tuotteiden liikkeiden, varastotasojen ja toimitusaikataulujen seuranta. Globaali logistiikkayritys voi käyttää Event Sourcingia lähetysten seuraamiseen eri maissa, tullimuodollisuuksien hoitamiseen ja toimitusaikataulujen hallintaan.

Oikean tallennusjärjestelmän valinta: Päätösmatriisi

Auttaaksemme sinua päättämään, mikä domain-tapahtumien tallennusjärjestelmä sopii sovellukseesi, harkitse seuraavaa päätösmatriisia:

Toiminnallisia oivalluksia

Tässä muutamia toiminnallisia oivalluksia Event Sourcingin toteuttamiseen:

• Aloita pienestä: Aloita pienellä, selkeästi määritellyllä domainilla saadaksesi kokemusta Event Sourcingista ennen sen soveltamista suurempiin, monimutkaisempiin domaineihin.
• Keskity domainiin: Mallinna domainisi huolellisesti ja tunnista keskeiset domain-tapahtumat.
• Valitse oikea tallennusjärjestelmä: Valitse tapahtumakauppa, joka täyttää sovelluksesi suorituskyky-, skaalautuvuus- ja tietojen johdonmukaisuusvaatimukset.
• Toteuta tapahtumien versiointi: Suunnittele tapahtumien versiointi alusta alkaen taaksepäin yhteensopivuuden varmistamiseksi.
• Valvo suorituskykyä: Valvo tapahtumakauppasi ja tapahtumankäsittelijöidesi suorituskykyä tunnistaaksesi mahdolliset pullonkaulat.
• Automatisoi käyttöönotto: Automatisoi Event Sourcing -infrastruktuurisi käyttöönotto ja hallinta.
• Harkitse kompromisseja: Event Sourcingiin liittyy kompromisseja. Ymmärrä, että monimutkaisuutta syntyy mallin tuomien hyötyjen saavuttamiseksi.

Yhteenveto

Event Sourcing on tehokas arkkitehtoninen malli, joka tarjoaa lukuisia etuja, kuten täydellisen tarkastuspolun, ajalliset kyselyt ja parannetun suorituskyvyn tietyissä toiminnoissa. Se esittää kuitenkin myös haasteita, jotka on otettava huolellisesti huomioon, kuten monimutkaisuus, lopullinen johdonmukaisuus ja tapahtumien versiointi. Valitsemalla huolellisesti domain-tapahtumien tallennusjärjestelmän ja toteuttamalla parhaita käytäntöjä voit hyödyntää Event Sourcingia onnistuneesti skaalautuvien, joustavien ja tarkastettavien sovellusten rakentamiseksi.

Tämä opas tarjosi yleiskatsauksen Event Sourcingiin ja useisiin suosittuihin domain-tapahtumien tallennusjärjestelmiin. Valitse paras järjestelmä vastaamaan projektisi erityistarpeita.

Muista, että tämä sisältö on tarkoitettu maailmanlaajuiselle yleisölle, joten mukauta ja sovella käsitteitä ainutlaatuisiin olosuhteisiisi ja kulttuurikontekstiisi. Event Sourcing -periaatteet ovat universaaleja, mutta toteutus voi vaihdella riippuen erityistarpeistasi ja resursseistasi.