Architektura Event Sourcing: Dogłębne spojrzenie na systemy przechowywania zdarzeń domenowych

Event Sourcing to wzorzec architektoniczny, w którym stan aplikacji jest określany przez sekwencję zdarzeń. Zamiast przechowywać bieżący stan encji, zapisujemy serię niezmiennych zdarzeń, które reprezentują zmiany w tej encji. Ten post na blogu szczegółowo omówi architekturę Event Sourcing, koncentrując się w szczególności na systemach przechowywania zdarzeń domenowych.

Co to jest Event Sourcing?

W tradycyjnych systemach bieżący stan encji jest przechowywany bezpośrednio w bazie danych. Gdy nastąpi aktualizacja, istniejący rekord jest modyfikowany lub nadpisywany. To podejście sprawdza się w wielu aplikacjach, ale ma ograniczenia, gdy:

• Audyt i śledzenie historii są kluczowe.
• Złożone przejścia stanu wymagają rekonstrukcji.
• Wymagana jest propagacja danych w czasie rzeczywistym i architektury oparte na zdarzeniach.

Event Sourcing rozwiązuje te ograniczenia, przechowując każdą zmianę stanu jako niezmienne zdarzenie. Zdarzenia te są zapisywane w magazynie zdarzeń tylko do zapisu. Aby odtworzyć bieżący stan encji, zdarzenia są odtwarzane w kolejności, w jakiej wystąpiły. Pomyśl o tym jak o księdze, w której każda transakcja jest rejestrowana, a saldo jest obliczane przez zsumowanie wszystkich transakcji.

Kluczowe Koncepcje

• Zdarzenie Domenowe: Fakt reprezentujący coś, co wydarzyło się w domenie. Jest to niezmienny zapis zmiany stanu. Przykłady to OrderCreated, OrderShipped, PaymentReceived.
• Magazyn Zdarzeń: Magazyn danych tylko do zapisu, zoptymalizowany do przechowywania i pobierania zdarzeń domenowych. Zapewnia mechanizmy trwałości zdarzeń, pobierania i subskrypcji.
• Obsługa Zdarzeń: Komponenty, które reagują na zdarzenia domenowe. Mogą aktualizować modele odczytu, wyzwalać integracje zewnętrzne lub wykonywać inne działania.
• Modele Odczytu: Zdenormalizowane reprezentacje danych zoptymalizowane pod kątem określonych wzorców zapytań. Są one aktualizowane przez programy obsługi zdarzeń i zapewniają widok danych tylko do odczytu.
• Snapshotting: Technika służąca do optymalizacji rekonstrukcji stanu poprzez okresowe przechowywanie bieżącego stanu encji. Podczas rekonstrukcji stanu system ładuje najnowszą migawkę i odtwarza tylko zdarzenia, które wystąpiły po zrobieniu migawki.

Korzyści z Event Sourcing

Event Sourcing oferuje kilka zalet w porównaniu z tradycyjnymi architekturami CRUD (Create, Read, Update, Delete):

• Kompletny Ślad Audytowy: Każda zmiana stanu jest rejestrowana jako zdarzenie, zapewniając kompleksową historię danych aplikacji. Jest to nieocenione w przypadku audytu, debugowania i zgodności.
• Zapytania Czasowe: Możliwość zapytania o stan encji w dowolnym momencie. Umożliwia to analizę historyczną i raportowanie. Na przykład możesz określić liczbę zamówień złożonych w określonym regionie w konkretnym dniu.
• Uproszczone Debugowanie: Odtwarzając zdarzenia, możesz odtworzyć dowolny przeszły stan aplikacji, co ułatwia identyfikację i naprawę błędów.
• Poprawiona Wydajność dla Niektórych Operacji: Chociaż rekonstrukcja stanu może być wolniejsza, aktualizacja modeli odczytu może być wysoce zoptymalizowana pod kątem określonych wzorców zapytań.
• Architektura Oparta na Zdarzeniach: Event Sourcing naturalnie współgra z architekturami opartymi na zdarzeniach, umożliwiając propagację danych w czasie rzeczywistym i integrację z innymi systemami.
• Łatwiejsza Ewolucja: Dodawanie nowych funkcji lub modyfikowanie istniejących jest często łatwiejsze, ponieważ możesz po prostu dodać nowe programy obsługi zdarzeń bez wpływu na istniejący strumień zdarzeń.
• Większa Skalowalność: Rozproszenie przetwarzania zdarzeń na wielu węzłach może poprawić skalowalność i odporność.

Wyzwania Event Sourcing

Event Sourcing stwarza również pewne wyzwania, które należy dokładnie rozważyć:

• Złożoność: Implementacja Event Sourcing wymaga innego sposobu myślenia i głębszego zrozumienia modelowania domeny i zasad sterowanych zdarzeniami.
• Spójność Ostateczna: Modele odczytu są ostatecznie spójne z magazynem zdarzeń, co może wprowadzać opóźnienia i niespójności w interfejsie użytkownika. Należy wdrożyć strategie radzenia sobie ze spójnością ostateczną, takie jak optymistyczne blokowanie lub transakcje kompensacyjne.
• Wersjonowanie Zdarzeń: Wraz z rozwojem aplikacji struktura zdarzeń domenowych może ulec zmianie. Należy wdrożyć strategie radzenia sobie z wersjonowaniem zdarzeń, takie jak migracja zdarzeń lub ewolucja schematu, aby zapewnić kompatybilność wsteczną.
• Rekonstrukcja Stanu: Rekonstrukcja stanu encji poprzez odtwarzanie zdarzeń może być czasochłonna, szczególnie w przypadku encji z dużą liczbą zdarzeń. Snapshotting może pomóc złagodzić ten problem.
• Wybór Właściwego Magazynu Zdarzeń: Wybór odpowiedniego magazynu zdarzeń, który spełnia wymagania aplikacji dotyczące wydajności, skalowalności i niezawodności, jest kluczowy.

Systemy Przechowywania Zdarzeń Domenowych: Porównawcze Omówienie

1. Relacyjne Bazy Danych (SQL)

Relacyjne bazy danych, takie jak PostgreSQL, MySQL i SQL Server, mogą być używane jako magazyny zdarzeń. Chociaż oferują właściwości ACID (Atomicity, Consistency, Isolation, Durability) i silną spójność danych, mogą nie być najbardziej wydajnym wyborem do przetwarzania zdarzeń o dużej przepustowości.

Zalety:

• Właściwości ACID: Zapewnia integralność i spójność danych.
• Dojrzała Technologia: Ugruntowana technologia z rozbudowanymi narzędziami i wsparciem.
• Znajomość: Większość programistów zna relacyjne bazy danych.
• Silna Spójność: Zapewnia silne gwarancje spójności.

Wady:

• Wąskie Gardła Wydajności: Mogą stać się wąskim gardłem wydajności dla strumieni zdarzeń o dużej objętości.
• Wyzwania Ewolucji Schematu: Obsługa zmian schematu może być złożona i wymagać starannego planowania.
• Ograniczenia Skalowalności: Skalowanie relacyjnych baz danych może być trudne, szczególnie w przypadku obciążeń intensywnie zapisujących.
• Niezoptymalizowane pod kątem Operacji Tylko Dołączenia: Relacyjne bazy danych nie są specjalnie zaprojektowane do operacji tylko dołączania, co może wpływać na wydajność.

Przykład Implementacji (PostgreSQL):

Utwórz tabelę do przechowywania zdarzeń domenowych:

            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
              
            
          

Wstaw nowe zdarzenie:

            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. Bazy Danych NoSQL

Bazy danych NoSQL, takie jak MongoDB, Cassandra i Couchbase, oferują większą elastyczność i skalowalność w porównaniu z relacyjnymi bazami danych. Dobrze nadają się do obsługi strumieni zdarzeń o dużej objętości, ale mogą zapewniać słabsze gwarancje spójności danych.

Zalety:

• Skalowalność: Zaprojektowane do skalowania w poziomie i mogą obsługiwać duże ilości danych.
• Elastyczność: Schemat bezschematowy lub elastyczny schemat umożliwia łatwiejsze wersjonowanie zdarzeń.
• Wydajność: Zoptymalizowane pod kątem operacji odczytu i zapisu o dużej przepustowości.
• Opłacalność: Mogą być bardziej opłacalne niż relacyjne bazy danych dla niektórych obciążeń.

Wady:

• Spójność Ostateczna: Mogą zapewniać słabsze gwarancje spójności danych w porównaniu z relacyjnymi bazami danych.
• Złożoność: Wymaga głębszego zrozumienia koncepcji baz danych NoSQL i technik modelowania danych.
• Dojrzałość: Niektóre bazy danych NoSQL są mniej dojrzałe niż relacyjne bazy danych.
• Ograniczenia Zapytań: Możliwości wykonywania zapytań mogą być ograniczone w porównaniu z relacyjnymi bazami danych.

Przykład Implementacji (MongoDB):

Przechowuj zdarzenia domenowe w kolekcji:

            {
  "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. Specjalizowane Magazyny Zdarzeń

Specjalizowane magazyny zdarzeń, takie jak EventStoreDB i AxonDB, są zaprojektowane specjalnie do Event Sourcing. Zapewniają funkcje, takie jak przechowywanie tylko do zapisu, wersjonowanie zdarzeń i zarządzanie strumieniami. Te bazy danych są zwykle najlepszym wyborem, jeśli poważnie myślisz o event sourcingu.

Zalety:

• Zoptymalizowane pod kątem Event Sourcing: Zaprojektowane specjalnie do event sourcingu z funkcjami, takimi jak przechowywanie tylko do zapisu, zarządzanie strumieniami i wersjonowanie zdarzeń.
• Wysoka Wydajność: Zoptymalizowane pod kątem przetwarzania zdarzeń o dużej przepustowości.
• Obsługa Spójności Ostatecznej: Wbudowane mechanizmy obsługi spójności ostatecznej.
• Zarządzanie Strumieniami: Upraszcza zarządzanie strumieniami zdarzeń i wykonywanie zapytań.

Wady:

• Uzależnienie od Dostawcy: Może wprowadzać uzależnienie od dostawcy.
• Koszt: Mogą być droższe niż inne opcje.
• Krzywa Uczenia się: Wymaga nauczenia się nowej technologii.
• Ograniczone Wdrażanie: Mniej powszechnie wdrażane niż relacyjne i NoSQL bazy danych.

Przykład Implementacji (EventStoreDB):

EventStoreDB używa strumieni do przechowywania zdarzeń. Możesz dołączać zdarzenia do strumienia za pomocą biblioteki klienta EventStoreDB.

4. Kolejki Komunikatów (Kafka, RabbitMQ)

Kolejki komunikatów, takie jak Apache Kafka i RabbitMQ, mogą być używane jako magazyny zdarzeń, szczególnie w połączeniu z ramami przetwarzania strumieniowego. Zapewniają wysoką przepustowość, skalowalność i odporność na błędy, dzięki czemu nadają się do aplikacji opartych na zdarzeniach na dużą skalę. Jednak są one generalnie używane bardziej jako mechanizm transportu tymczasowego niż trwały magazyn.

Zalety:

• Wysoka Przepustowość: Zaprojektowane do przetwarzania komunikatów o dużej przepustowości.
• Skalowalność: Wysoce skalowalne i mogą obsługiwać duże ilości zdarzeń.
• Odporność na Błędy: Wbudowane mechanizmy odporności na błędy.
• Przetwarzanie w Czasie Rzeczywistym: Umożliwia przetwarzanie zdarzeń w czasie rzeczywistym.

Wady:

• Złożoność: Wymaga głębszego zrozumienia koncepcji kolejek komunikatów i ram przetwarzania strumieniowego.
• Trwałość Danych: Trwałość danych musi być starannie skonfigurowana.
• Odtwarzanie Zdarzeń: Odtwarzanie zdarzeń może być bardziej złożone niż w przypadku specjalistycznych magazynów zdarzeń.
• Gwarancje Kolejności: Gwarancje kolejności mogą być ograniczone w zależności od konfiguracji.

Przykład Implementacji (Apache Kafka):

Publikuj zdarzenia domenowe w temacie 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. Magazyny Zdarzeń Oparte na Chmurze

Zalety:

• Skalowalność: Wysoce skalowalne i mogą obsługiwać duże ilości zdarzeń.
• Niezawodność: Wbudowana niezawodność i odporność na błędy.
• Łatwość Użycia: Zarządzane usługi upraszczają wdrażanie i konserwację.
• Integracja: Bezproblemowa integracja z innymi usługami w chmurze.

Wady:

• Uzależnienie od Dostawcy: Wprowadza uzależnienie od dostawcy.
• Koszt: Może być droższy niż rozwiązania zarządzane samodzielnie.
• Opóźnienie: Opóźnienie sieciowe może wpływać na wydajność.
• Kontrola: Mniejsza kontrola nad podstawową infrastrukturą.

Rozważania dotyczące Wydajności

• Przepustowość Zapisu: Zdolność do obsługi dużej ilości przychodzących zdarzeń.
• Opóźnienie Odczytu: Czas potrzebny na pobranie zdarzeń i odtworzenie stanu encji.
• Współbieżność: Zdolność do obsługi współbieżnych operacji odczytu i zapisu.
• Pojemność Pamięci: Ilość pamięci wymagana do przechowywania zdarzeń.
• Opóźnienie Sieciowe: Opóźnienie między aplikacją a magazynem zdarzeń.

Aby zoptymalizować wydajność, rozważ następujące techniki:

• Przetwarzanie Grupowe: Przetwarzanie grupowe zdarzeń przed zapisaniem ich w magazynie zdarzeń może poprawić przepustowość zapisu.
• Buforowanie: Buforowanie często używanych zdarzeń może zmniejszyć opóźnienie odczytu.
• Snapshotting: Snapshotting może zmniejszyć liczbę zdarzeń, które należy odtworzyć podczas rekonstrukcji stanu encji.
• Indeksowanie: Indeksowanie zdarzeń na podstawie identyfikatora agregatu i innych istotnych atrybutów może poprawić wydajność zapytań.
• Partycjonowanie: Partycjonowanie magazynu zdarzeń na wiele węzłów może poprawić skalowalność i wydajność.

Integralność Danych

Integralność danych jest najważniejsza w Event Sourcing. Ważne jest, aby zapewnić, że zdarzenia są utrwalane niezawodnie i we właściwej kolejności. Oto kilka strategii utrzymania integralności danych:

• Transakcje: Używaj transakcji, aby zapewnić, że zdarzenia są zapisywane atomowo w magazynie zdarzeń.
• Idempotentność: Projektuj programy obsługi zdarzeń tak, aby były idempotentne, co oznacza, że mogą przetwarzać to samo zdarzenie wielokrotnie bez powodowania niezamierzonych skutków ubocznych.
• Optymistyczne Blokowanie: Używaj optymistycznego blokowania, aby zapobiec współbieżnym aktualizacjom tego samego agregatu.
• Walidacja Zdarzeń: Waliduj zdarzenia przed utrwaleniem ich w magazynie zdarzeń, aby upewnić się, że są one poprawne i spójne.
• Sumy Kontrolne: Obliczaj sumy kontrolne dla zdarzeń i przechowuj je wraz ze zdarzeniami. Weryfikuj sumy kontrolne podczas pobierania zdarzeń, aby upewnić się, że nie zostały uszkodzone.

Wersjonowanie Zdarzeń

Wraz z rozwojem aplikacji struktura zdarzeń domenowych może ulec zmianie. Obsługa wersjonowania zdarzeń jest kluczowa, aby zapewnić kompatybilność wsteczną i zapobiec utracie danych. Oto kilka strategii obsługi wersjonowania zdarzeń:

• Podnoszenie Wersji Zdarzeń: Przekształcaj starsze wersje zdarzeń do najnowszej wersji podczas odczytywania ich z magazynu zdarzeń.
• Ewolucja Schematu: Ewoluuj schemat zdarzeń w czasie, dodając nowe pola lub modyfikując istniejące. Upewnij się, że starsze wersje zdarzeń mogą być nadal poprawnie przetwarzane.
• Migracja Zdarzeń: Migruj starsze zdarzenia do najnowszej wersji schematu. Można to zrobić jako proces w tle.

Przykłady z Życia Wzięte

Event Sourcing jest używany w różnych branżach i aplikacjach. Oto kilka przykładów z życia wziętych:

• E-commerce: Śledzenie historii zamówień, zmian zapasów i aktywności klientów. Na przykład globalna platforma e-commerce może używać Event Sourcing do śledzenia zamówień z różnych krajów, obsługi przeliczeń walut i zarządzania zapasami w wielu magazynach.
• Bankowość: Rejestrowanie transakcji, śledzenie sald kont i audyt działań finansowych. Międzynarodowy bank może używać Event Sourcing do śledzenia transakcji w różnych oddziałach i walutach, zapewniając pełny ślad audytowy.
• Gry: Śledzenie działań graczy, zmian stanu gry i historii zdarzeń. Gry online dla wielu graczy często używają Event Sourcing do utrzymywania spójnego stanu gry u wielu graczy i na serwerach.
• Zarządzanie Łańcuchem Dostaw: Śledzenie ruchów produktów, poziomów zapasów i harmonogramów dostaw. Globalna firma logistyczna może używać Event Sourcing do śledzenia przesyłek w różnych krajach, obsługi odpraw celnych i zarządzania harmonogramami dostaw.

Wybór Właściwego Systemu Przechowywania: Macierz Decyzyjna

Aby pomóc Ci zdecydować, który system przechowywania zdarzeń domenowych jest odpowiedni dla Twojej aplikacji, rozważ następującą macierz decyzyjną:

Działania, które Możesz Podjąć

Oto kilka działań, które możesz podjąć w celu wdrożenia Event Sourcing:

• Zacznij od Małego: Zacznij od małej, dobrze zdefiniowanej domeny, aby zdobyć doświadczenie z Event Sourcing przed zastosowaniem go do większych, bardziej złożonych domen.
• Skoncentruj się na Domenie: Starannie modeluj swoją domenę i zidentyfikuj kluczowe zdarzenia domenowe.
• Wybierz Właściwy System Przechowywania: Wybierz magazyn zdarzeń, który spełnia wymagania aplikacji dotyczące wydajności, skalowalności i spójności danych.
• Wdróż Wersjonowanie Zdarzeń: Zaplanuj wersjonowanie zdarzeń od samego początku, aby zapewnić kompatybilność wsteczną.
• Monitoruj Wydajność: Monitoruj wydajność swojego magazynu zdarzeń i programów obsługi zdarzeń, aby zidentyfikować potencjalne wąskie gardła.
• Zautomatyzuj Wdrażanie: Zautomatyzuj wdrażanie i zarządzanie swoją infrastrukturą Event Sourcing.
• Rozważ Kompromisy: Event Sourcing wiąże się z kompromisami. Zrozum, że pojawiają się złożoności dla korzyści uzyskanych ze wzorca.

Wniosek

Event Sourcing to potężny wzorzec architektoniczny, który oferuje liczne korzyści, w tym kompletny ślad audytowy, zapytania czasowe i poprawioną wydajność dla niektórych operacji. Stwarza jednak również wyzwania, które należy dokładnie rozważyć, takie jak złożoność, spójność ostateczna i wersjonowanie zdarzeń. Starannie wybierając system przechowywania zdarzeń domenowych i wdrażając najlepsze praktyki, możesz z powodzeniem wykorzystać Event Sourcing do tworzenia skalowalnych, odpornych i podlegających audytowi aplikacji.

Ten przewodnik zawierał przegląd Event Sourcing i kilku popularnych systemów przechowywania zdarzeń domenowych. Wybierz najlepszy system, który jest zgodny z konkretnymi potrzebami wymagań Twojego projektu.

Pamiętaj, że ta treść jest przeznaczona dla globalnej publiczności, więc dostosuj i zastosuj koncepcje do swoich unikalnych okoliczności i kontekstu kulturowego. Zasady Event Sourcing są uniwersalne, ale implementacja może się różnić w zależności od Twoich konkretnych potrzeb i zasobów.