Arhitektura Event Sourcing: Poglobljen pogled v sisteme za shranjevanje domenskih dogodkov

Event Sourcing je arhitekturni vzorec, kjer stanje aplikacije določa zaporedje dogodkov. Namesto shranjevanja trenutnega stanja entitete, shranjujemo vrsto nespremenljivih dogodkov, ki predstavljajo spremembe te entitete. Ta objava na blogu bo podrobno raziskala arhitekturo Event Sourcing, s poudarkom na sistemih za shranjevanje domenskih dogodkov.

Kaj je Event Sourcing?

V tradicionalnih sistemih se trenutno stanje entitete neposredno shranjuje v bazi podatkov. Ko pride do posodobitve, se obstoječi zapis spremeni ali prepiše. Ta pristop dobro deluje za številne aplikacije, vendar ima omejitve, ko:

• So revizija in sledenje zgodovine ključnega pomena.
• Je treba rekonstruirati kompleksne prenose stanja.
• Sta potrebna širjenje podatkov v realnem času in arhitekture, ki temeljijo na dogodkih.

Event Sourcing obravnava te omejitve tako, da vsako spremembo stanja shrani kot nespremenljiv dogodek. Ti dogodki se shranjujejo v shrambi dogodkov, ki omogoča samo dodajanje. Za rekonstrukcijo trenutnega stanja entitete se dogodki ponovijo v vrstnem redu, v katerem so se zgodili. Predstavljajte si to kot knjigo, kjer je vsaka transakcija zabeležena, stanje pa se izračuna s seštevanjem vseh transakcij.

Ključni koncepti

• Domenski dogodek: Dejstvo, ki predstavlja nekaj, kar se je zgodilo v domeni. Je nespremenljiv zapis spremembe stanja. Primeri vključujejo OrderCreated, OrderShipped, PaymentReceived.
• Shramba dogodkov: Shramba podatkov, ki omogoča samo dodajanje in je optimizirana za shranjevanje in pridobivanje domenskih dogodkov. Zagotavlja mehanizme za vztrajnost dogodkov, pridobivanje in naročnino.
• Obravnavalci dogodkov: Komponente, ki se odzivajo na domenske dogodke. Lahko posodabljajo modele branja, sprožijo zunanje integracije ali izvajajo druge dejanja.
• Modeli branja: Denormalizirane predstavitve podatkov, optimizirane za specifične vzorce poizvedb. Posodabljajo jih obravnavalci dogodkov in zagotavljajo pogled na podatke, ki je samo za branje.
• Posnetki: Tehnika, ki se uporablja za optimizacijo rekonstrukcije stanja s periodičnim shranjevanjem trenutnega stanja entitete. Pri rekonstrukciji stanja sistem naloži najnovejši posnetek in ponovi samo dogodke, ki so se zgodili po posnetku.

Prednosti Event Sourcing

Event Sourcing ponuja več prednosti pred tradicionalnimi arhitekturami CRUD (Create, Read, Update, Delete):

• Popolna sled revizije: Vsaka sprememba stanja je zabeležena kot dogodek, kar zagotavlja celovito zgodovino podatkov aplikacije. To je neprecenljivo za revizijo, odpravljanje napak in skladnost.
• Časovne poizvedbe: Sposobnost poizvedovanja o stanju entitete kadar koli. To omogoča zgodovinsko analizo in poročanje. Na primer, lahko ugotovite število naročil, oddanih v določeni regiji na določen datum.
• Poenostavljeno odpravljanje napak: S ponavljanjem dogodkov lahko znova ustvarite katero koli preteklo stanje aplikacije, kar olajša prepoznavanje in odpravljanje napak.
• Izboljšana zmogljivost za določene operacije: Medtem ko je rekonstrukcija stanja lahko počasnejša, je mogoče posodabljanje modelov branja visoko optimizirati za specifične vzorce poizvedb.
• Arhitektura, ki temelji na dogodkih: Event Sourcing se naravno ujema z arhitekturami, ki temeljijo na dogodkih, kar omogoča širjenje podatkov v realnem času in integracijo z drugimi sistemi.
• Lažja evolucija: Dodajanje novih funkcij ali spreminjanje obstoječih je pogosto lažje, ker lahko preprosto dodate nove obravnavalce dogodkov, ne da bi vplivali na obstoječi tok dogodkov.
• Izboljšana razširljivost: Distribucija obdelave dogodkov na več vozlišč lahko izboljša razširljivost in odpornost.

Izzivi Event Sourcing

Event Sourcing predstavlja tudi nekaj izzivov, ki jih je treba skrbno preučiti:

• Kompleksnost: Izvajanje Event Sourcing zahteva drugačno miselnost in globlje razumevanje modeliranja domene in načel, ki temeljijo na dogodkih.
• Eventualna konsistentnost: Modeli branja so eventualno konsistentni s shrambo dogodkov, kar lahko povzroči zamude in nedoslednosti v uporabniškem vmesniku. Izvajati je treba strategije za obravnavo eventualne konsistentnosti, kot so optimistično zaklepanje ali kompenzacijske transakcije.
• Različice dogodkov: Ko se aplikacija razvija, se lahko spremeni struktura domenskih dogodkov. Izvajati je treba strategije za obravnavo različic dogodkov, kot je migracija dogodkov ali evolucija sheme, da se zagotovi združljivost nazaj.
• Rekonstrukcija stanja: Rekonstrukcija stanja entitete s ponavljanjem dogodkov lahko vzame veliko časa, zlasti za entitete z velikim številom dogodkov. Posnetki lahko pomagajo ublažiti to težavo.
• Izbira prave shrambe dogodkov: Izbira ustrezne shrambe dogodkov, ki izpolnjuje zahteve aplikacije glede zmogljivosti, razširljivosti in zanesljivosti, je ključnega pomena.

Sistemi za shranjevanje domenskih dogodkov: Primerjalni pregled

1. Relacijske baze podatkov (SQL)

Relacijske baze podatkov, kot so PostgreSQL, MySQL in SQL Server, se lahko uporabljajo kot shrambe dogodkov. Čeprav ponujajo lastnosti ACID (Atomicity, Consistency, Isolation, Durability) in močno doslednost podatkov, morda niso najbolj učinkovita izbira za obdelavo dogodkov z visoko prepustnostjo.

Prednosti:

• Lastnosti ACID: Zagotavlja celovitost in doslednost podatkov.
• Zrela tehnologija: Uveljavljena tehnologija z obsežnim orodjem in podporo.
• Poznavanje: Večina razvijalcev pozna relacijske baze podatkov.
• Močna doslednost: Zagotavlja močna jamstva za doslednost.

Slabosti:

• Ozka grla pri zmogljivosti: Lahko postane ozko grlo pri zmogljivosti za tokove dogodkov z veliko količino.
• Izzivi pri evoluciji sheme: Obravnavanje sprememb sheme je lahko zapleteno in zahteva skrbno načrtovanje.
• Omejitve razširljivosti: Razširjanje relacijskih baz podatkov je lahko zahtevno, zlasti za delovne obremenitve, ki so močno odvisne od pisanja.
• Ni optimizirano za operacije samo za dodajanje: Relacijske baze podatkov niso posebej zasnovane za operacije samo za dodajanje, kar lahko vpliva na zmogljivost.

Primer implementacije (PostgreSQL):

Ustvarite tabelo za shranjevanje domenskih dogodkov:

            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
              
            
          

Vstavite nov dogodek:

            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 baze podatkov

NoSQL baze podatkov, kot so MongoDB, Cassandra in Couchbase, ponujajo večjo prilagodljivost in razširljivost v primerjavi z relacijskimi bazami podatkov. Dobro so primerne za obravnavo tokov dogodkov z veliko količino, vendar lahko zagotavljajo šibkejša jamstva za doslednost podatkov.

Prednosti:

• Razširljivost: Zasnovan za horizontalno razširljivost in lahko obravnava velike količine podatkov.
• Prilagodljivost: Shema brez sheme ali prilagodljiva shema omogoča lažje različice dogodkov.
• Zmogljivost: Optimiziran za operacije branja in pisanja z visoko prepustnostjo.
• Stroškovno učinkovito: Za določene delovne obremenitve je lahko stroškovno učinkovitejši od relacijskih baz podatkov.

Slabosti:

• Eventualna konsistentnost: Lahko zagotavlja šibkejša jamstva za doslednost podatkov v primerjavi z relacijskimi bazami podatkov.
• Kompleksnost: Zahteva globlje razumevanje konceptov baz podatkov NoSQL in tehnik modeliranja podatkov.
• Zrelost: Nekatere baze podatkov NoSQL so manj zrele kot relacijske baze podatkov.
• Omejitve poizvedovanja: Zmožnosti poizvedovanja so lahko omejene v primerjavi z relacijskimi bazami podatkov.

Primer implementacije (MongoDB):

Shranite domenske dogodke v zbirki:

            {
  "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. Specializirane shrambe dogodkov

Specializirane shrambe dogodkov, kot sta EventStoreDB in AxonDB, so zasnovane posebej za Event Sourcing. Zagotavljajo funkcije, kot so shranjevanje samo za dodajanje, različice dogodkov in upravljanje tokov. Te baze podatkov so običajno najboljša izbira, če ste resni glede event sourcinga.

Prednosti:

• Optimizirano za Event Sourcing: Zasnovano posebej za event sourcing s funkcijami, kot so shranjevanje samo za dodajanje, upravljanje tokov in različice dogodkov.
• Visoka zmogljivost: Optimizirano za obdelavo dogodkov z visoko prepustnostjo.
• Obravnavanje eventualne konsistentnosti: Vgrajeni mehanizmi za obravnavanje eventualne konsistentnosti.
• Upravljanje tokov: Poenostavlja upravljanje in poizvedovanje tokov dogodkov.

Slabosti:

• Zaklepanje dobavitelja: Lahko uvede zaklepanje dobavitelja.
• Stroški: Je lahko dražji od drugih možnosti.
• Krivulja učenja: Zahteva učenje nove tehnologije.
• Omejena uporaba: Manj razširjena kot relacijske baze podatkov in baze podatkov NoSQL.

Primer implementacije (EventStoreDB):

EventStoreDB uporablja tokove za shranjevanje dogodkov. Dogodke lahko dodate v tok s knjižnico odjemalca EventStoreDB.

4. Vrste sporočil (Kafka, RabbitMQ)

Vrste sporočil, kot sta Apache Kafka in RabbitMQ, se lahko uporabljajo kot shrambe dogodkov, zlasti v povezavi z okviri za obdelavo tokov. Zagotavljajo visoko prepustnost, razširljivost in toleranco napak, zaradi česar so primerne za obsežne aplikacije, ki temeljijo na dogodkih. Vendar pa se na splošno uporabljajo bolj kot prehodni transportni mehanizem kot pa trajna shramba.

Prednosti:

• Visoka prepustnost: Zasnovan za obdelavo sporočil z visoko prepustnostjo.
• Razširljivost: Zelo razširljiv in lahko obravnava velike količine dogodkov.
• Toleranca napak: Vgrajeni mehanizmi za toleranco napak.
• Obdelava v realnem času: Omogoča obdelavo dogodkov v realnem času.

Slabosti:

• Kompleksnost: Zahteva globlje razumevanje konceptov vrst sporočil in okvirov za obdelavo tokov.
• Trajnost podatkov: Trajnost podatkov je treba skrbno konfigurirati.
• Ponavljanje dogodkov: Ponavljanje dogodkov je lahko bolj zapleteno kot pri specializiranih shrambah dogodkov.
• Jamstva za vrstni red: Jamstva za vrstni red so lahko omejena, odvisno od konfiguracije.

Primer implementacije (Apache Kafka):

Objavite domenske dogodke v temi Kafka:

            // Producer configuration
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);

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

// Send the record
producer.send(record);

producer.close();

            

              
                Copy
              
            
          

5. Shrambe dogodkov v oblaku

Prednosti:

• Razširljivost: Zelo razširljiv in lahko obravnava velike količine dogodkov.
• Zanesljivost: Vgrajena zanesljivost in toleranca napak.
• Enostavnost uporabe: Upravljane storitve poenostavljajo uvajanje in vzdrževanje.
• Integracija: Brezhibna integracija z drugimi storitvami v oblaku.

Slabosti:

• Zaklepanje dobavitelja: Uvede zaklepanje dobavitelja.
• Stroški: Je lahko dražji od rešitev, ki jih upravljate sami.
• Latenca: Omrežna latenca lahko vpliva na zmogljivost.
• Nadzor: Manj nadzora nad osnovno infrastrukturo.

Premisleki glede zmogljivosti

Zmogljivost je kritičen dejavnik pri izbiri sistema za shranjevanje domenskih dogodkov. Tukaj je nekaj premislekov glede zmogljivosti, ki jih morate upoštevati:

• Prepustnost pisanja: Sposobnost obravnave velike količine dohodnih dogodkov.
• Latenca branja: Čas, ki je potreben za pridobitev dogodkov in rekonstrukcijo stanja entitete.
• Sočasnost: Sposobnost obravnave sočasnih operacij branja in pisanja.
• Kapaciteta shranjevanja: Količina prostora za shranjevanje, potrebnega za shranjevanje dogodkov.
• Omrežna latenca: Latenca med aplikacijo in shrambo dogodkov.

Za optimizacijo zmogljivosti razmislite o naslednjih tehnikah:

• Združevanje: Združevanje dogodkov pred pisanjem v shrambo dogodkov lahko izboljša prepustnost pisanja.
• Predpomnjenje: Predpomnjenje pogosto dostopanih dogodkov lahko zmanjša latenco branja.
• Posnetki: Posnetki lahko zmanjšajo število dogodkov, ki jih je treba ponoviti pri rekonstrukciji stanja entitete.
• Indeksiranje: Indeksiranje dogodkov na podlagi ID-ja agregata in drugih ustreznih atributov lahko izboljša zmogljivost poizvedb.
• Razdelitev: Razdelitev shrambe dogodkov na več vozlišč lahko izboljša razširljivost in zmogljivost.

Celovitost podatkov

Celovitost podatkov je najpomembnejša pri Event Sourcing. Ključnega pomena je zagotoviti, da se dogodki shranjujejo zanesljivo in v pravilnem vrstnem redu. Tukaj je nekaj strategij za ohranjanje celovitosti podatkov:

• Transakcije: Uporabite transakcije, da zagotovite, da se dogodki atomsko zapisujejo v shrambo dogodkov.
• Idempotenca: Zasnovajte obravnavalce dogodkov tako, da bodo idempotentni, kar pomeni, da lahko obdelajo isti dogodek večkrat, ne da bi povzročili nenamerne stranske učinke.
• Optimistično zaklepanje: Uporabite optimistično zaklepanje, da preprečite sočasne posodobitve istega agregata.
• Validacija dogodkov: Validirajte dogodke pred shranjevanjem v shrambo dogodkov, da zagotovite, da so veljavni in dosledni.
• Kontrolne vsote: Izračunajte kontrolne vsote za dogodke in jih shranite skupaj z dogodki. Preverite kontrolne vsote pri pridobivanju dogodkov, da zagotovite, da niso bili poškodovani.

Različice dogodkov

Ko se aplikacija razvija, se lahko spremeni struktura domenskih dogodkov. Obravnavanje različic dogodkov je ključnega pomena za zagotovitev združljivosti nazaj in preprečitev izgube podatkov. Tukaj je nekaj strategij za obravnavanje različic dogodkov:

• Pretvorba dogodkov navzgor: Pretvorite starejše različice dogodkov v najnovejšo različico, ko jih berete iz shrambe dogodkov.
• Evolucija sheme: Sčasoma razvijajte shemo dogodkov z dodajanjem novih polj ali spreminjanjem obstoječih. Zagotovite, da je še vedno mogoče pravilno obdelati starejše različice dogodkov.
• Migracija dogodkov: Migrirajte starejše dogodke v najnovejšo različico sheme. To lahko storite kot proces v ozadju.

Primeri iz resničnega sveta

Event Sourcing se uporablja v različnih panogah in aplikacijah. Tukaj je nekaj primerov iz resničnega sveta:

• E-trgovina: Sledenje zgodovini naročil, spremembam zalog in dejavnosti strank. Na primer, globalna platforma za e-trgovino bi lahko uporabila Event Sourcing za sledenje naročilom iz različnih držav, obravnavo pretvorb valut in upravljanje zalog v več skladiščih.
• Banke: Beleženje transakcij, sledenje stanju na računu in revidiranje finančnih dejavnosti. Mednarodna banka bi lahko uporabila Event Sourcing za sledenje transakcijam v različnih poslovalnicah in valutah, kar bi zagotovilo popolno sled revizije.
• Igre: Sledenje dejanjem igralcev, spremembam stanja igre in zgodovini dogodkov. Spletne igre za več igralcev pogosto uporabljajo Event Sourcing za ohranjanje doslednega stanja igre med več igralci in strežniki.
• Upravljanje dobavne verige: Sledenje premikom izdelkov, ravni zalog in urnikom dostave. Globalno logistično podjetje lahko uporabi Event Sourcing za sledenje pošiljkam v različnih državah, obravnavo carinjenja in upravljanje urnikov dostave.

Izbira pravega sistema za shranjevanje: Odločitvena matrika

Da bi vam pomagali pri odločitvi, kateri sistem za shranjevanje domenskih dogodkov je pravi za vašo aplikacijo, razmislite o naslednji odločitveni matriki:

Praktični vpogledi

• Začnite majhno: Začnite z majhno, dobro definirano domeno, da pridobite izkušnje z Event Sourcing, preden jo uporabite za večje, bolj zapletene domene.
• Osredotočite se na domeno: Skrbno modelirajte svojo domeno in prepoznajte ključne domenske dogodke.
• Izberite pravi sistem za shranjevanje: Izberite shrambo dogodkov, ki izpolnjuje zahteve vaše aplikacije glede zmogljivosti, razširljivosti in doslednosti podatkov.
• Implementirajte različice dogodkov: Načrtujte različice dogodkov že od začetka, da zagotovite združljivost nazaj.
• Spremljajte zmogljivost: Spremljajte zmogljivost svoje shrambe dogodkov in obravnavalcev dogodkov, da prepoznate morebitna ozka grla.
• Avtomatizirajte uvajanje: Avtomatizirajte uvajanje in upravljanje infrastrukture Event Sourcing.
• Upoštevajte kompromise: Event Sourcing vključuje kompromise. Zavedajte se, da se zaradi prednosti, pridobljenih iz vzorca, pojavijo zapletenosti.

Zaključek

Event Sourcing je zmogljiv arhitekturni vzorec, ki ponuja številne prednosti, vključno s popolno sledjo revizije, časovnimi poizvedbami in izboljšano zmogljivostjo za določene operacije. Vendar pa predstavlja tudi izzive, ki jih je treba skrbno preučiti, kot so kompleksnost, eventualna konsistentnost in različice dogodkov. S skrbno izbiro sistema za shranjevanje domenskih dogodkov in izvajanjem najboljših praks lahko uspešno izkoristite Event Sourcing za izgradnjo razširljivih, odpornih in revidiranih aplikacij.

Ta vodnik ponuja pregled Event Sourcing in več priljubljenih sistemov za shranjevanje domenskih dogodkov. Izberite najboljši sistem, ki ustreza specifičnim potrebam vaših projektnih zahtev.

Ne pozabite, da je ta vsebina namenjena globalnemu občinstvu, zato prilagodite in uporabite koncepte svojim edinstvenim okoliščinam in kulturnemu kontekstu. Načela Event Sourcing so univerzalna, vendar se lahko izvajanje razlikuje glede na vaše posebne potrebe in vire.