Wzorzec określania źródła zdarzeń

Azure

Zamiast przechowywać tylko bieżący stan danych w relacyjnej bazie danych, należy przechowywać pełną serię akcji wykonywanych na obiekcie w magazynie tylko do dołączania. Magazyn działa jak system rejestrowania i może służyć do zmaterializowania obiektów domeny. Takie podejście może poprawić wydajność, skalowalność i możliwość inspekcji w złożonych systemach.

Ważne

Określanie źródła zdarzeń to złożony wzorzec, który przenika przez całą architekturę i wprowadza kompromisy w celu osiągnięcia zwiększonej wydajności, skalowalności i możliwości inspekcji. Gdy system stanie się systemem określania źródła zdarzeń, wszystkie przyszłe decyzje projektowe są ograniczone przez fakt, że jest to system określania źródła zdarzeń. Istnieje wysoki koszt migracji do lub z systemu określania źródła zdarzeń. Ten wzorzec najlepiej nadaje się do systemów, w których wydajność i skalowalność są najwyższymi wymaganiami. Złożoność dodawania źródła zdarzeń do systemu nie jest uzasadniona dla większości systemów.

Kontekst i problem

Większość aplikacji pracuje z danymi, a typowe podejście dotyczy aplikacji do przechowywania najnowszego stanu danych w relacyjnej bazie danych, wstawiania lub aktualizowania danych zgodnie z potrzebami. Na przykład w tradycyjnym modelu tworzenia, odczytu, aktualizowania i usuwania (CRUD) typowy proces danych polega na odczytywaniu danych z magazynu, dokonywaniu pewnych modyfikacji i aktualizowaniu bieżącego stanu danych przy użyciu nowych wartości — często przy użyciu transakcji, które blokują dane.

Podejście CRUD jest proste i szybkie w przypadku większości scenariuszy. Jednak w systemach o dużym obciążeniu takie podejście ma pewne wyzwania:

• Wydajność: w miarę skalowania systemu wydajność będzie spadać z powodu rywalizacji o zasoby i problemy z blokowaniem.

• Skalowalność: systemy CRUD są synchroniczne, a operacje danych blokują aktualizacje. Może to prowadzić do wąskich gardeł i większego opóźnienia w przypadku obciążenia systemu.

• Inspekcja: systemy CRUD przechowują tylko najnowszy stan danych. Jeśli nie istnieje mechanizm inspekcji, który rejestruje szczegóły każdej operacji w osobnym dzienniku, historia zostanie utracona.

Rozwiązanie

Wzorzec określania źródła zdarzeń definiuje podejście do obsługi operacji na danych, które są sterowane przez sekwencję zdarzeń, z których każde jest rejestrowane w magazynie tylko do dołączania. Kod aplikacji wywołuje zdarzenia, które imperatywnie opisują akcję podjętą w obiekcie. Zdarzenia są zwykle wysyłane do kolejki, w której oddzielny proces, program obsługi zdarzeń, nasłuchuje kolejki i utrzymuje zdarzenia w magazynie zdarzeń. Każde zdarzenie reprezentuje logiczną zmianę obiektu, taką jak AddedItemToOrder lub OrderCanceled.

Zdarzenia są utrwalane w magazynie zdarzeń, który działa jak system rejestrowania (autorytatywne źródło danych) wobec bieżącego stanu danych. Dodatkowe programy obsługi zdarzeń mogą nasłuchiwać zainteresowanych zdarzeń i podejmować odpowiednie działania. Odbiorca mógłby na przykład zainicjować zadania, które stosują operacje w zdarzeniach do innych systemów, lub wykonać inną powiązaną akcję, która jest wymagana do ukończenia operacji. Należy zauważyć, że kod aplikacji, który generuje zdarzenia, jest całkowicie niezależny od systemów, które subskrybują zdarzenia.

W dowolnym momencie aplikacje mogą odczytywać historię zdarzeń. Następnie można użyć zdarzeń, aby zmaterializować bieżący stan jednostki, odtwarzając i zużywając wszystkie zdarzenia powiązane z jednostką. Ten proces może wystąpić na żądanie, aby zmaterializować obiekt domeny podczas obsługi żądania.

Ponieważ zdarzenia odczytu i odtwarzania są stosunkowo kosztowne, aplikacje zazwyczaj implementują zmaterializowane widoki, projekcje tylko do odczytu magazynu zdarzeń zoptymalizowane pod kątem wykonywania zapytań. Na przykład system może obsługiwać zmaterializowany widok wszystkich zamówień klientów używanych do wypełniania interfejsu użytkownika. Gdy aplikacja dodaje nowe zamówienia, dodaje lub usuwa elementy w zamówieniu lub dodaje informacje o wysyłki, zdarzenia są zgłaszane i program obsługi aktualizuje zmaterializowany widok.

Na rysunku przedstawiono przegląd wzorca, w tym niektóre typowe implementacje ze wzorcem, w tym użycie kolejki, magazyn tylko do odczytu, integrowanie zdarzeń z aplikacjami zewnętrznymi i systemami oraz odtwarzanie zdarzeń w celu utworzenia projekcji bieżącego stanu określonych jednostek.

Przepływ pracy

Poniżej opisano typowy przepływ pracy dla tego wzorca:

1. Warstwa prezentacji wywołuje obiekt odpowiedzialny za odczytywanie z magazynu tylko do odczytu. Zwrócone dane są używane do wypełniania interfejsu użytkownika.
2. Warstwa prezentacji wywołuje programy obsługi poleceń, aby wykonywać akcje, takie jak tworzenie koszyka, lub dodawanie elementu do koszyka.
3. Procedura obsługi poleceń wywołuje magazyn zdarzeń, aby pobrać zdarzenia historyczne dla jednostki. Może na przykład pobrać wszystkie zdarzenia koszyka. Te zdarzenia są odtwarzane w obiekcie w celu zmaterializowania bieżącego stanu jednostki, przed podjęciem jakiejkolwiek akcji.
4. Logika biznesowa jest uruchamiana i są wywoływane zdarzenia. W większości implementacji zdarzenia są wypychane do kolejki lub tematu w celu oddzielenia producentów zdarzeń i odbiorców zdarzeń.
5. Programy obsługi zdarzeń nasłuchują zainteresowanych zdarzeń i wykonują odpowiednią akcję dla tej procedury obsługi. Oto niektóre typowe akcje obsługi zdarzeń:
   1. Zapisywanie zdarzeń w magazynie zdarzeń
   2. Aktualizowanie magazynu tylko do odczytu zoptymalizowanego pod kątem zapytań
   3. Integrowanie z systemami zewnętrznymi

Zalety wzorca

Wzorzec określania źródła zdarzeń zapewnia następujące korzyści:

• Zdarzenia są niezmienne i mogą być przechowywane przy użyciu operacji tylko do dołączania. Interfejs użytkownika, przepływ pracy lub proces, który zainicjował zdarzenie, może kontynuować działanie, a zadania, które obsługują zdarzenia, mogą działać w tle. Ten proces, w połączeniu z faktem, że nie ma rywalizacji podczas przetwarzania transakcji, może znacznie poprawić wydajność i skalowalność aplikacji, zwłaszcza w przypadku warstwy prezentacji.

• Zdarzenia to proste obiekty, które opisują jakąś akcję, która wystąpiła, wraz z skojarzonymi danymi wymaganymi do opisania akcji reprezentowanej przez zdarzenie. Zdarzenia nie aktualizują bezpośrednio magazynu danych. Są one po prostu rejestrowane w celu obsługi w odpowiednim czasie. Użycie zdarzeń może uprościć implementację i zarządzanie.

• Zdarzenia zwykle mają znaczenie dla eksperta domeny, podczas gdy niezgodność obiektów relacyjnych impedancji może sprawić, że złożone tabele bazy danych staną się trudne do zrozumienia. Tabele są sztucznymi konstrukcjami, które reprezentują bieżący stan systemu, a nie zdarzenia, które wystąpiły.

• Określanie źródła zdarzenia może zapobiec sytuacji, w której równoczesne aktualizacje będą powodować konflikty, ponieważ eliminuje wymóg bezpośredniej aktualizacji obiektów w magazynie danych. Jednak model domeny nadal musi być projektowany tak, aby zabezpieczać przed żądaniami, które mogłyby prowadzić do niespójnego stanu.

• Magazyn zdarzeń tylko do dołączania zawiera dziennik inspekcji, który może służyć do monitorowania akcji wykonywanych w magazynie danych. Może on ponownie wygenerować bieżący stan jako zmaterializowane widoki lub projekcje przez ponowne odtworzenie zdarzeń w dowolnym momencie i może pomóc w testowaniu i debugowaniu systemu. Ponadto wymóg użycia zdarzeń wyrównywujących w celu anulowania zmian może zapewnić historię zmian, które zostały odwrócone. Ta funkcja nie byłaby taka, gdyby model przechowywał bieżący stan. Lista zdarzeń może również służyć do analizowania wydajności aplikacji i wykrywania trendów zachowań użytkowników. Może też służyć do uzyskiwania innych przydatnych informacji biznesowych.

• Programy obsługi poleceń zgłaszają zdarzenia, a zadania wykonują operacje w odpowiedzi na te zdarzenia. To oddzielenie zadań od zdarzeń zapewnia elastyczność i rozszerzalność. Zadania mają informacje na temat typu zdarzenia i danych dotyczących zdarzenia, ale nie na temat operacji, która wyzwoliła zdarzenie. Ponadto wiele zadań może obsługiwać każde zdarzenie. Dzięki temu jest możliwa łatwa integracja z innymi usługami i systemami, które nasłuchują jedynie nowych zdarzeń wywołanych przez magazyn zdarzeń. Jednak zdarzenia określania źródła zdarzeń mogą być na bardzo niskim poziomie i zamiast tego może być konieczne wygenerowanie poszczególnych zdarzeń integracji.

Określanie źródła zdarzeń jest często łączone ze wzorcem CQRS przez wykonywanie zadań zarządzania danymi w odpowiedzi na zdarzenia i materializowanie widoków z przechowywanych zdarzeń.

Problemy i kwestie do rozważenia

Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:

• Spójność ostateczna — system będzie ostatecznie spójny tylko podczas tworzenia zmaterializowanych widoków lub generowania projekcji danych przez odtworzenie zdarzeń. Istnieje pewne opóźnienie między dodawaniem zdarzeń przez aplikację do magazynu zdarzeń w wyniku obsługi żądania, publikowania zdarzeń i odbiorców zdarzeń, które je obsługują. W tym okresie do magazynu zdarzeń mogły przybyć nowe zdarzenia opisujące dalsze zmiany jednostek. Klienci muszą być w porządku z faktem, że dane są ostatecznie spójne, a system powinien być zaprojektowany tak, aby uwzględnić spójność ostateczną w tych scenariuszach.

  Uwaga

  Aby uzyskać więcej informacji na temat spójności ostatecznej, zobacz temat Data Consistency Primer (Podstawy spójności danych).

• Zdarzenia przechowywania wersji — magazyn zdarzeń jest stałym źródłem informacji, dlatego dane zdarzenia nigdy nie powinny być aktualizowane. Jedynym sposobem zaktualizowania jednostki lub cofnięcia zmiany jest dodanie zdarzenia wyrównywujące do magazynu zdarzeń. Jeśli schemat (a nie dane) utrwałych zdarzeń musi ulec zmianie, być może podczas migracji, połączenie istniejących zdarzeń w magazynie z nową wersją może być trudne. Aplikacja będzie musiała obsługiwać zmiany w strukturach zdarzeń. This can be done in several ways.

  • Upewnij się, że programy obsługi zdarzeń obsługują wszystkie wersje zdarzeń. Może to być wyzwanie dla utrzymania i testowania. Wymaga to zaimplementowania sygnatury wersji dla każdej wersji schematu zdarzeń w celu zachowania zarówno starych, jak i nowych formatów zdarzeń.
  • Zaimplementuj program obsługi zdarzeń, aby obsługiwać określone wersje zdarzeń. Może to być wyzwanie związane z konserwacją, które może być konieczne w przypadku wprowadzenia zmian poprawki usterek w wielu programach obsługi. Wymaga to zaimplementowania sygnatury wersji dla każdej wersji schematu zdarzeń w celu zachowania zarówno starych, jak i nowych formatów zdarzeń.
  • Zaktualizuj zdarzenia historyczne do nowego schematu po zaimplementowaniu nowego schematu. Spowoduje to przerwanie niezmienności zdarzeń.

• Porządkowanie zdarzeń — aplikacje wielowątkowa i wiele wystąpień aplikacji może przechowywać zdarzenia w magazynie zdarzeń. Spójność zdarzeń znajdujących się w magazynie zdarzeń jest istotna, podobnie jak kolejność zdarzeń, która ma wpływ na poszczególne jednostki (kolejność, w jakiej występują zmiany jednostki, ma wpływ na jej bieżący stan). Dodanie sygnatury czasowej do każdego zdarzenia może pomóc uniknąć problemów. Inną powszechną praktyką jest adnotowanie identyfikatorem przyrostowym każdego zdarzenia wynikającego z żądania. Jeśli dwie akcje podejmują próbę dodania zdarzeń dla tej samej jednostki w tym samym czasie, magazyn zdarzeń może odrzucić zdarzenie pasujące do istniejącego identyfikatora jednostki i identyfikatora zdarzenia.

• Wykonywanie zapytań dotyczących zdarzeń — nie ma standardowego podejścia ani istniejących mechanizmów, takich jak zapytania SQL, do odczytywania zdarzeń w celu uzyskania informacji. Jedyne dane, które można wyodrębnić, to strumień zdarzeń wykorzystujący identyfikator zdarzenia jako kryterium. Identyfikator zdarzenia przeważnie wykonuje mapowanie na poszczególne jednostki. Bieżący stan jednostki można określić tylko przez odtworzenie wszystkich zdarzeń, które odnoszą się do niej, względem oryginalnego stanu tej jednostki.

• Koszt ponownego tworzenia stanu jednostek — długość każdego strumienia zdarzeń wpływa na zarządzanie systemem i aktualizowanie go. W przypadku dużych strumieni należy rozważyć utworzenie migawek w określonych odstępach czasu, takich jak określona liczba zdarzeń. Bieżący stan jednostki można uzyskać z migawki i przez odtworzenie dowolnych zdarzeń, które wystąpiły po tym punkcie w czasie. Aby uzyskać więcej informacji na temat tworzenia migawek danych, zobacz Podstawowo-podrzędna replikacja migawek.

• Konflikty — mimo że określanie źródła zdarzeń minimalizuje ryzyko konfliktu aktualizacji danych, aplikacja musi nadal mieć możliwość radzenia sobie z niespójnościami, które wynikają ze spójności ostatecznej i braku transakcji. Na przykład zdarzenie wskazujące zmniejszenie zapasów może pojawić się w magazynie danych podczas składania zamówienia dla tego elementu. Taka sytuacja skutkuje wymaganiem uzgodnienia dwóch operacji, doradzając klientowi lub tworząc zamówienie wsteczne.

• Potrzeba idempotentności — publikacja zdarzeń może być co najmniej raz, dlatego odbiorcy zdarzeń muszą być idempotentni. Nie mogą ponownie stosować aktualizacji opisanej w zdarzeniu, jeśli zdarzenie jest obsługiwane więcej niż raz. Wiele wystąpień konsumenta może obsługiwać i agregować właściwość jednostki, na przykład całkowitą liczbę złożonych zamówień. Tylko jeden z nich musi pomyślnie zwiększać agregację, gdy wystąpi zdarzenie złożone w zamówieniu. Chociaż ten wynik nie jest kluczową cechą określania źródła zdarzeń, jest to zwykła decyzja implementacji.

• Logika cykliczna — należy pamiętać o scenariuszach, w których przetwarzanie jednego zdarzenia obejmuje utworzenie jednego lub kilku nowych zdarzeń, ponieważ może to spowodować nieskończoną pętlę.

Kiedy używać tego wzorca

Tego wzorca należy używać w następujących scenariuszach:

• Gdy zachodzi potrzeba przechwycenia zamiaru, celu lub przyczyny w danych. Na przykład zmiany w jednostce klienta można przechwycić jako serię określonych typów zdarzeń, takich jak Przeniesiono do domu, Zamknięte konto lub Zmarły.

• Gdy konieczne jest zminimalizowanie lub całkowite wykluczenie wystąpienia konfliktu aktualizacji względem danych.

• Jeśli chcesz rejestrować zdarzenia, aby odtworzyć je w celu przywrócenia stanu systemu, wycofać zmiany lub zachować historię i dziennik inspekcji. Na przykład jeśli zadanie obejmuje wiele kroków, może być konieczne wykonanie akcji w celu przywrócenia aktualizacji, a następnie odtworzenie niektórych kroków w celu przywrócenia danych z powrotem do spójnego stanu.

• W przypadku korzystania ze zdarzeń. Jest to naturalna funkcja działania aplikacji i wymaga niewielkiego nakładu pracy nad programowaniem lub implementacją.

• Jeśli musisz rozdzielić proces wprowadzania danych lub zaktualizować dane z zadań wymaganych do zastosowania tych akcji. Ta zmiana może spowodować zwiększenie wydajności interfejsu użytkownika lub dystrybuowanie zdarzeń do innych odbiorników, które podejmują działania po wystąpieniu zdarzeń. Na przykład można zintegrować system płac z witryną internetową przesyłania wydatków. Zdarzenia zgłaszane przez magazyn zdarzeń w odpowiedzi na aktualizacje danych wprowadzone w witrynie internetowej będą używane zarówno przez witrynę internetową, jak i system płac.

• Jeśli chcesz, aby elastyczność była w stanie zmienić format zmaterializowanych modeli i danych jednostki, jeśli wymagania się zmieniają, lub — w przypadku użycia z usługą CQRS — musisz dostosować model odczytu lub widoki, które uwidaczniają dane.

• W przypadku użycia z usługą CQRS i spójność ostateczna jest akceptowalna podczas aktualizowania modelu odczytu lub wpływ na wydajność ponownego wypełniania jednostek i danych ze strumienia zdarzeń jest akceptowalny.

Ten wzorzec może nie być użyteczny w następujących sytuacjach:

• Aplikacje, które nie wymagają hiperskal lub wydajności.

• Małe lub proste domeny, systemy, które mają niewielką logikę biznesową lub nie mają jej wcale, lub systemy bezdomenowe, które naturalnie działają prawidłowo z tradycyjnymi mechanizmami zarządzania danymi CRUD.

• Systemy, w których jest wymagana spójność i aktualizacje w czasie rzeczywistym widoków danych.

• Systemy, w których występuje tylko małe wystąpienie konfliktowych aktualizacji danych bazowych. Na przykład systemy, które raczej głównie dodają, a nie aktualizują dane.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec określania źródła zdarzeń może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniu stać się odporne na awarię i zapewnić, że zostanie przywrócony do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Ze względu na przechwytywanie historii zmian w złożonym procesie biznesowym może ułatwić rekonstrukcję stanu, jeśli trzeba odzyskać magazyny stanów. - PARTYcjonowanie danych RE:06 - RE:09 Odzyskiwanie po awarii
Wydajność pomagawydajnie sprostać zapotrzebowaniu dzięki optymalizacjom skalowania, danych, kodu.	Ten wzorzec, zwykle w połączeniu z usługą CQRS, odpowiedni projekt domeny i strategiczne tworzenie migawek, może poprawić wydajność obciążenia ze względu na niepodzielne operacje tylko do dołączania i unikanie blokowania bazy danych dla zapisów i odczytów. - PE:08 Wydajność danych

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

System zarządzania konferencjami musi śledzić liczbę ukończonych rezerwacji na konferencji. W ten sposób może sprawdzić, czy są jeszcze dostępne miejsca, gdy potencjalny uczestnik próbuje dokonać rezerwacji. System może przechowywać łączną liczbę rezerwacji dla danej konferencji na co najmniej dwa sposoby:

• System może przechowywać informacje o całkowitej liczbie rezerwacji jako osobne jednostki w bazie danych, która przechowuje informacje o rezerwacji. W momencie dokonywania lub anulowania rezerwacji system może odpowiednio powiększyć lub pomniejszyć tę liczbę. Ta metoda teoretycznie jest prosta, lecz może powodować problemy ze skalowalnością w przypadku dużej liczby uczestników próbujących zarezerwować miejsce w krótkim czasie. Na przykład w ostatni dzień lub przed zamknięciem okresu rezerwacji.

• System może przechowywać informacje o dokonanych i anulowanych rezerwacjach jako zdarzenia przechowywane w magazynie zdarzeń. Następnie może obliczyć liczbę dostępnych miejsc przez odtworzenie tych zdarzeń. Ta metoda może być bardziej skalowalna dzięki niezmienności zdarzeń. System musi jedynie mieć możliwość odczytywania danych z magazynu zdarzeń lub dołączania danych do magazynu zdarzeń. Informacje zdarzeń o dokonaniu i anulowaniu rezerwacji nigdy nie są modyfikowane.

Na poniższym diagramie pokazano, w jaki sposób za pomocą określania źródła zdarzeń można zaimplementować podsystem rezerwacji miejsc systemu zarządzania konferencjami.

Sekwencja akcji mających na celu zarezerwowanie dwóch miejsc jest następująca:

1. Interfejs użytkownika wydaje polecenie w celu zarezerwowania miejsc dla dwóch uczestników. Polecenie jest obsługiwane przez oddzielny program obsługi poleceń. Jest to fragment logiki, który jest całkowicie niezależny od interfejsu użytkownika i który jest odpowiedzialny za obsługę żądań publikowanych jako polecenia.

2. Jednostka zawierająca informacje o wszystkich rezerwacjach konferencji jest tworzona przez wykonywanie zapytań dotyczących zdarzeń opisujących rezerwacje i anulowania. Ta jednostka jest nazywana SeatAvailability, i jest zawarta w modelu domeny, który uwidacznia metody wykonywania zapytań i modyfikowania danych w jednostce.

   Niektóre optymalizacje do rozważenia korzystają z migawek (dzięki czemu nie trzeba wykonywać zapytań i powtarzać pełnej listy zdarzeń w celu uzyskania bieżącego stanu jednostki) i obsługi buforowanej kopii jednostki w pamięci.

3. Program obsługi poleceń wywołuje metodę udostępnianą przez model domeny, aby dokonać rezerwacji.

4. Jednostka SeatAvailability zgłasza zdarzenie zawierające liczbę miejsc zarezerwowanych. Następnym razem, gdy jednostka zastosuje zdarzenia, wszystkie rezerwacje będą używane do obliczenia liczby pozostałych miejsc.

5. System dołącza nowe zdarzenie do listy zdarzeń w magazynie zdarzeń.

Jeśli użytkownik anuluje rezerwację, system wykonuje podobną procedurę, z tą różnicą, że program obsługi poleceń wydaje polecenie, które generuje zdarzenie anulowania miejsca i dołącza je do magazynu zdarzeń.

Oprócz zapewnienia większego zakresu skalowalności, korzystanie z magazynu zdarzeń zapewnia również pełną historię lub dziennik inspekcji rezerwacji i anulowania na konferencji. Zdarzenia w magazynie zdarzeń są precyzyjnymi rekordami. Nie ma potrzeby utrwalania agregacji w żaden inny sposób, ponieważ system może łatwo odtworzyć zdarzenia i przywrócić stan do dowolnego punktu w czasie.

Następne kroki

• Niezgodność impedancji relacyjnej obiektu

• Podstawy spójności danych. Jeśli używasz określania źródła zdarzeń z oddzielnym magazynem odczytu lub zmaterializowanymi widokami, dane odczytu nie będą natychmiast spójne. Zamiast tego dane będą ostatecznie spójne. W tym artykule przedstawiono podsumowanie problemów związanych z utrzymaniem spójności w przypadku danych rozproszonych.

• Data Partitioning Guidance (Wskazówki dotyczące partycjonowania danych). Dane są często partycjonowane w przypadku używania określania źródła zdarzeń w celu zwiększenia skalowalności, zmniejszenia rywalizacji i optymalizacji wydajności. W tym artykule opisano sposób dzielenia danych na odrębne partycje oraz problemy, które mogą wystąpić.

• Blog Martina Fowlera:

  • Określanie źródła zdarzeń
  • Migawka w witrynie internetowej Martina Fowlera Enterprise Application Architecture

Powiązane zasoby

Podczas implementowania tego wzorca mogą być istotne następujące wzorce i wskazówki:

• Wzorzec podziału odpowiedzialności polecenia i zapytania (CQRS). Magazyn zapisu, który zapewnia stałe źródło informacji dla implementacji CQRS, często opiera się na implementacji wzorca określania źródła zdarzeń. Opisuje sposób segregowania operacji, które odczytują dane w aplikacji, od operacji, które aktualizują dane przy użyciu osobnych interfejsów.

• Materialized View pattern (Wzorzec zmaterializowanego widoku). Magazyn danych używany w systemie opartym na określaniu źródła zdarzeń zwykle nie nadaje się do wydajnego wykonywania zapytań. Zamiast tego typowym podejściem jest generowanie wstępnie wypełnionych widoków danych w regularnych odstępach czasu lub po zmianie danych.

• Wzorzec transakcji wyrównującej. Istniejące dane w magazynie określania źródła zdarzeń nie są aktualizowane. Zamiast tego dodawane są nowe wpisy, które przechodzą stan jednostek do nowych wartości. Aby odwrócić zmianę, używane są wpisy wyrównywujące, ponieważ nie jest możliwe odwrócenie poprzedniej zmiany. Wzorzec opisuje, w jaki sposób cofnąć działanie wykonane przez poprzednią operację.

Zamiast przechowywać tylko bieżący stan danych w relacyjnej bazie danych, należy przechowywać pełną serię akcji wykonywanych na obiekcie w magazynie tylko do dołączania. Magazyn działa jak system rejestrowania i może służyć do zmaterializowania obiektów domeny. Takie podejście może poprawić wydajność, skalowalność i możliwość inspekcji w złożonych systemach.

Ważne

Określanie źródła zdarzeń to złożony wzorzec, który przenika przez całą architekturę i wprowadza kompromisy w celu osiągnięcia zwiększonej wydajności, skalowalności i możliwości inspekcji. Gdy system stanie się systemem określania źródła zdarzeń, wszystkie przyszłe decyzje projektowe są ograniczone przez fakt, że jest to system określania źródła zdarzeń. Istnieje wysoki koszt migracji do lub z systemu określania źródła zdarzeń. Ten wzorzec najlepiej nadaje się do systemów, w których wydajność i skalowalność są najwyższymi wymaganiami. Złożoność dodawania źródła zdarzeń do systemu nie jest uzasadniona dla większości systemów.

Kontekst i problem

Większość aplikacji pracuje z danymi, a typowe podejście dotyczy aplikacji do przechowywania najnowszego stanu danych w relacyjnej bazie danych, wstawiania lub aktualizowania danych zgodnie z potrzebami. Na przykład w tradycyjnym modelu tworzenia, odczytu, aktualizowania i usuwania (CRUD) typowy proces danych polega na odczytywaniu danych z magazynu, dokonywaniu pewnych modyfikacji i aktualizowaniu bieżącego stanu danych przy użyciu nowych wartości — często przy użyciu transakcji, które blokują dane.

Podejście CRUD jest proste i szybkie w przypadku większości scenariuszy. Jednak w systemach o dużym obciążeniu takie podejście ma pewne wyzwania:

• Wydajność: w miarę skalowania systemu wydajność będzie spadać z powodu rywalizacji o zasoby i problemy z blokowaniem.

• Skalowalność: systemy CRUD są synchroniczne, a operacje danych blokują aktualizacje. Może to prowadzić do wąskich gardeł i większego opóźnienia w przypadku obciążenia systemu.

• Inspekcja: systemy CRUD przechowują tylko najnowszy stan danych. Jeśli nie istnieje mechanizm inspekcji, który rejestruje szczegóły każdej operacji w osobnym dzienniku, historia zostanie utracona.

Rozwiązanie

Wzorzec określania źródła zdarzeń definiuje podejście do obsługi operacji na danych, które są sterowane przez sekwencję zdarzeń, z których każde jest rejestrowane w magazynie tylko do dołączania. Kod aplikacji wywołuje zdarzenia, które imperatywnie opisują akcję podjętą w obiekcie. Zdarzenia są zwykle wysyłane do kolejki, w której oddzielny proces, program obsługi zdarzeń, nasłuchuje kolejki i utrzymuje zdarzenia w magazynie zdarzeń. Każde zdarzenie reprezentuje logiczną zmianę obiektu, taką jak AddedItemToOrder lub OrderCanceled.

Zdarzenia są utrwalane w magazynie zdarzeń, który działa jak system rejestrowania (autorytatywne źródło danych) wobec bieżącego stanu danych. Dodatkowe programy obsługi zdarzeń mogą nasłuchiwać zainteresowanych zdarzeń i podejmować odpowiednie działania. Odbiorca mógłby na przykład zainicjować zadania, które stosują operacje w zdarzeniach do innych systemów, lub wykonać inną powiązaną akcję, która jest wymagana do ukończenia operacji. Należy zauważyć, że kod aplikacji, który generuje zdarzenia, jest całkowicie niezależny od systemów, które subskrybują zdarzenia.

W dowolnym momencie aplikacje mogą odczytywać historię zdarzeń. Następnie można użyć zdarzeń, aby zmaterializować bieżący stan jednostki, odtwarzając i zużywając wszystkie zdarzenia powiązane z jednostką. Ten proces może wystąpić na żądanie, aby zmaterializować obiekt domeny podczas obsługi żądania.

Ponieważ zdarzenia odczytu i odtwarzania są stosunkowo kosztowne, aplikacje zazwyczaj implementują zmaterializowane widoki, projekcje tylko do odczytu magazynu zdarzeń zoptymalizowane pod kątem wykonywania zapytań. Na przykład system może obsługiwać zmaterializowany widok wszystkich zamówień klientów używanych do wypełniania interfejsu użytkownika. Gdy aplikacja dodaje nowe zamówienia, dodaje lub usuwa elementy w zamówieniu lub dodaje informacje o wysyłki, zdarzenia są zgłaszane i program obsługi aktualizuje zmaterializowany widok.

Na rysunku przedstawiono przegląd wzorca, w tym niektóre typowe implementacje ze wzorcem, w tym użycie kolejki, magazyn tylko do odczytu, integrowanie zdarzeń z aplikacjami zewnętrznymi i systemami oraz odtwarzanie zdarzeń w celu utworzenia projekcji bieżącego stanu określonych jednostek.

Przepływ pracy

Poniżej opisano typowy przepływ pracy dla tego wzorca:

1. Warstwa prezentacji wywołuje obiekt odpowiedzialny za odczytywanie z magazynu tylko do odczytu. Zwrócone dane są używane do wypełniania interfejsu użytkownika.
2. Warstwa prezentacji wywołuje programy obsługi poleceń, aby wykonywać akcje, takie jak tworzenie koszyka, lub dodawanie elementu do koszyka.
3. Procedura obsługi poleceń wywołuje magazyn zdarzeń, aby pobrać zdarzenia historyczne dla jednostki. Może na przykład pobrać wszystkie zdarzenia koszyka. Te zdarzenia są odtwarzane w obiekcie w celu zmaterializowania bieżącego stanu jednostki, przed podjęciem jakiejkolwiek akcji.
4. Logika biznesowa jest uruchamiana i są wywoływane zdarzenia. W większości implementacji zdarzenia są wypychane do kolejki lub tematu w celu oddzielenia producentów zdarzeń i odbiorców zdarzeń.
5. Programy obsługi zdarzeń nasłuchują zainteresowanych zdarzeń i wykonują odpowiednią akcję dla tej procedury obsługi. Oto niektóre typowe akcje obsługi zdarzeń:
   1. Zapisywanie zdarzeń w magazynie zdarzeń
   2. Aktualizowanie magazynu tylko do odczytu zoptymalizowanego pod kątem zapytań
   3. Integrowanie z systemami zewnętrznymi

Zalety wzorca

Wzorzec określania źródła zdarzeń zapewnia następujące korzyści:

• Zdarzenia są niezmienne i mogą być przechowywane przy użyciu operacji tylko do dołączania. Interfejs użytkownika, przepływ pracy lub proces, który zainicjował zdarzenie, może kontynuować działanie, a zadania, które obsługują zdarzenia, mogą działać w tle. Ten proces, w połączeniu z faktem, że nie ma rywalizacji podczas przetwarzania transakcji, może znacznie poprawić wydajność i skalowalność aplikacji, zwłaszcza w przypadku warstwy prezentacji.

• Zdarzenia to proste obiekty, które opisują jakąś akcję, która wystąpiła, wraz z skojarzonymi danymi wymaganymi do opisania akcji reprezentowanej przez zdarzenie. Zdarzenia nie aktualizują bezpośrednio magazynu danych. Są one po prostu rejestrowane w celu obsługi w odpowiednim czasie. Użycie zdarzeń może uprościć implementację i zarządzanie.

• Zdarzenia zwykle mają znaczenie dla eksperta domeny, podczas gdy niezgodność obiektów relacyjnych impedancji może sprawić, że złożone tabele bazy danych staną się trudne do zrozumienia. Tabele są sztucznymi konstrukcjami, które reprezentują bieżący stan systemu, a nie zdarzenia, które wystąpiły.

• Określanie źródła zdarzenia może zapobiec sytuacji, w której równoczesne aktualizacje będą powodować konflikty, ponieważ eliminuje wymóg bezpośredniej aktualizacji obiektów w magazynie danych. Jednak model domeny nadal musi być projektowany tak, aby zabezpieczać przed żądaniami, które mogłyby prowadzić do niespójnego stanu.

• Magazyn zdarzeń tylko do dołączania zawiera dziennik inspekcji, który może służyć do monitorowania akcji wykonywanych w magazynie danych. Może on ponownie wygenerować bieżący stan jako zmaterializowane widoki lub projekcje przez ponowne odtworzenie zdarzeń w dowolnym momencie i może pomóc w testowaniu i debugowaniu systemu. Ponadto wymóg użycia zdarzeń wyrównywujących w celu anulowania zmian może zapewnić historię zmian, które zostały odwrócone. Ta funkcja nie byłaby taka, gdyby model przechowywał bieżący stan. Lista zdarzeń może również służyć do analizowania wydajności aplikacji i wykrywania trendów zachowań użytkowników. Może też służyć do uzyskiwania innych przydatnych informacji biznesowych.

• Programy obsługi poleceń zgłaszają zdarzenia, a zadania wykonują operacje w odpowiedzi na te zdarzenia. To oddzielenie zadań od zdarzeń zapewnia elastyczność i rozszerzalność. Zadania mają informacje na temat typu zdarzenia i danych dotyczących zdarzenia, ale nie na temat operacji, która wyzwoliła zdarzenie. Ponadto wiele zadań może obsługiwać każde zdarzenie. Dzięki temu jest możliwa łatwa integracja z innymi usługami i systemami, które nasłuchują jedynie nowych zdarzeń wywołanych przez magazyn zdarzeń. Jednak zdarzenia określania źródła zdarzeń mogą być na bardzo niskim poziomie i zamiast tego może być konieczne wygenerowanie poszczególnych zdarzeń integracji.

Określanie źródła zdarzeń jest często łączone ze wzorcem CQRS przez wykonywanie zadań zarządzania danymi w odpowiedzi na zdarzenia i materializowanie widoków z przechowywanych zdarzeń.

Problemy i kwestie do rozważenia

Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:

• Spójność ostateczna — system będzie ostatecznie spójny tylko podczas tworzenia zmaterializowanych widoków lub generowania projekcji danych przez odtworzenie zdarzeń. Istnieje pewne opóźnienie między dodawaniem zdarzeń przez aplikację do magazynu zdarzeń w wyniku obsługi żądania, publikowania zdarzeń i odbiorców zdarzeń, które je obsługują. W tym okresie do magazynu zdarzeń mogły przybyć nowe zdarzenia opisujące dalsze zmiany jednostek. Klienci muszą być w porządku z faktem, że dane są ostatecznie spójne, a system powinien być zaprojektowany tak, aby uwzględnić spójność ostateczną w tych scenariuszach.

  Uwaga

  Aby uzyskać więcej informacji na temat spójności ostatecznej, zobacz temat Data Consistency Primer (Podstawy spójności danych).

• Zdarzenia przechowywania wersji — magazyn zdarzeń jest stałym źródłem informacji, dlatego dane zdarzenia nigdy nie powinny być aktualizowane. Jedynym sposobem zaktualizowania jednostki lub cofnięcia zmiany jest dodanie zdarzenia wyrównywujące do magazynu zdarzeń. Jeśli schemat (a nie dane) utrwałych zdarzeń musi ulec zmianie, być może podczas migracji, połączenie istniejących zdarzeń w magazynie z nową wersją może być trudne. Aplikacja będzie musiała obsługiwać zmiany w strukturach zdarzeń. This can be done in several ways.

  • Upewnij się, że programy obsługi zdarzeń obsługują wszystkie wersje zdarzeń. Może to być wyzwanie dla utrzymania i testowania. Wymaga to zaimplementowania sygnatury wersji dla każdej wersji schematu zdarzeń w celu zachowania zarówno starych, jak i nowych formatów zdarzeń.
  • Zaimplementuj program obsługi zdarzeń, aby obsługiwać określone wersje zdarzeń. Może to być wyzwanie związane z konserwacją, które może być konieczne w przypadku wprowadzenia zmian poprawki usterek w wielu programach obsługi. Wymaga to zaimplementowania sygnatury wersji dla każdej wersji schematu zdarzeń w celu zachowania zarówno starych, jak i nowych formatów zdarzeń.
  • Zaktualizuj zdarzenia historyczne do nowego schematu po zaimplementowaniu nowego schematu. Spowoduje to przerwanie niezmienności zdarzeń.

• Porządkowanie zdarzeń — aplikacje wielowątkowa i wiele wystąpień aplikacji może przechowywać zdarzenia w magazynie zdarzeń. Spójność zdarzeń znajdujących się w magazynie zdarzeń jest istotna, podobnie jak kolejność zdarzeń, która ma wpływ na poszczególne jednostki (kolejność, w jakiej występują zmiany jednostki, ma wpływ na jej bieżący stan). Dodanie sygnatury czasowej do każdego zdarzenia może pomóc uniknąć problemów. Inną powszechną praktyką jest adnotowanie identyfikatorem przyrostowym każdego zdarzenia wynikającego z żądania. Jeśli dwie akcje podejmują próbę dodania zdarzeń dla tej samej jednostki w tym samym czasie, magazyn zdarzeń może odrzucić zdarzenie pasujące do istniejącego identyfikatora jednostki i identyfikatora zdarzenia.

• Wykonywanie zapytań dotyczących zdarzeń — nie ma standardowego podejścia ani istniejących mechanizmów, takich jak zapytania SQL, do odczytywania zdarzeń w celu uzyskania informacji. Jedyne dane, które można wyodrębnić, to strumień zdarzeń wykorzystujący identyfikator zdarzenia jako kryterium. Identyfikator zdarzenia przeważnie wykonuje mapowanie na poszczególne jednostki. Bieżący stan jednostki można określić tylko przez odtworzenie wszystkich zdarzeń, które odnoszą się do niej, względem oryginalnego stanu tej jednostki.

• Koszt ponownego tworzenia stanu jednostek — długość każdego strumienia zdarzeń wpływa na zarządzanie systemem i aktualizowanie go. W przypadku dużych strumieni należy rozważyć utworzenie migawek w określonych odstępach czasu, takich jak określona liczba zdarzeń. Bieżący stan jednostki można uzyskać z migawki i przez odtworzenie dowolnych zdarzeń, które wystąpiły po tym punkcie w czasie. Aby uzyskać więcej informacji na temat tworzenia migawek danych, zobacz Podstawowo-podrzędna replikacja migawek.

• Konflikty — mimo że określanie źródła zdarzeń minimalizuje ryzyko konfliktu aktualizacji danych, aplikacja musi nadal mieć możliwość radzenia sobie z niespójnościami, które wynikają ze spójności ostatecznej i braku transakcji. Na przykład zdarzenie wskazujące zmniejszenie zapasów może pojawić się w magazynie danych podczas składania zamówienia dla tego elementu. Taka sytuacja skutkuje wymaganiem uzgodnienia dwóch operacji, doradzając klientowi lub tworząc zamówienie wsteczne.

• Potrzeba idempotentności — publikacja zdarzeń może być co najmniej raz, dlatego odbiorcy zdarzeń muszą być idempotentni. Nie mogą ponownie stosować aktualizacji opisanej w zdarzeniu, jeśli zdarzenie jest obsługiwane więcej niż raz. Wiele wystąpień konsumenta może obsługiwać i agregować właściwość jednostki, na przykład całkowitą liczbę złożonych zamówień. Tylko jeden z nich musi pomyślnie zwiększać agregację, gdy wystąpi zdarzenie złożone w zamówieniu. Chociaż ten wynik nie jest kluczową cechą określania źródła zdarzeń, jest to zwykła decyzja implementacji.

• Logika cykliczna — należy pamiętać o scenariuszach, w których przetwarzanie jednego zdarzenia obejmuje utworzenie jednego lub kilku nowych zdarzeń, ponieważ może to spowodować nieskończoną pętlę.

Kiedy używać tego wzorca

Tego wzorca należy używać w następujących scenariuszach:

• Gdy zachodzi potrzeba przechwycenia zamiaru, celu lub przyczyny w danych. Na przykład zmiany w jednostce klienta można przechwycić jako serię określonych typów zdarzeń, takich jak Przeniesiono do domu, Zamknięte konto lub Zmarły.

• Gdy konieczne jest zminimalizowanie lub całkowite wykluczenie wystąpienia konfliktu aktualizacji względem danych.

• Jeśli chcesz rejestrować zdarzenia, aby odtworzyć je w celu przywrócenia stanu systemu, wycofać zmiany lub zachować historię i dziennik inspekcji. Na przykład jeśli zadanie obejmuje wiele kroków, może być konieczne wykonanie akcji w celu przywrócenia aktualizacji, a następnie odtworzenie niektórych kroków w celu przywrócenia danych z powrotem do spójnego stanu.

• W przypadku korzystania ze zdarzeń. Jest to naturalna funkcja działania aplikacji i wymaga niewielkiego nakładu pracy nad programowaniem lub implementacją.

• Jeśli musisz rozdzielić proces wprowadzania danych lub zaktualizować dane z zadań wymaganych do zastosowania tych akcji. Ta zmiana może spowodować zwiększenie wydajności interfejsu użytkownika lub dystrybuowanie zdarzeń do innych odbiorników, które podejmują działania po wystąpieniu zdarzeń. Na przykład można zintegrować system płac z witryną internetową przesyłania wydatków. Zdarzenia zgłaszane przez magazyn zdarzeń w odpowiedzi na aktualizacje danych wprowadzone w witrynie internetowej będą używane zarówno przez witrynę internetową, jak i system płac.

• Jeśli chcesz, aby elastyczność była w stanie zmienić format zmaterializowanych modeli i danych jednostki, jeśli wymagania się zmieniają, lub — w przypadku użycia z usługą CQRS — musisz dostosować model odczytu lub widoki, które uwidaczniają dane.

• W przypadku użycia z usługą CQRS i spójność ostateczna jest akceptowalna podczas aktualizowania modelu odczytu lub wpływ na wydajność ponownego wypełniania jednostek i danych ze strumienia zdarzeń jest akceptowalny.

Ten wzorzec może nie być użyteczny w następujących sytuacjach:

• Aplikacje, które nie wymagają hiperskal lub wydajności.

• Małe lub proste domeny, systemy, które mają niewielką logikę biznesową lub nie mają jej wcale, lub systemy bezdomenowe, które naturalnie działają prawidłowo z tradycyjnymi mechanizmami zarządzania danymi CRUD.

• Systemy, w których jest wymagana spójność i aktualizacje w czasie rzeczywistym widoków danych.

• Systemy, w których występuje tylko małe wystąpienie konfliktowych aktualizacji danych bazowych. Na przykład systemy, które raczej głównie dodają, a nie aktualizują dane.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec określania źródła zdarzeń może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniu stać się odporne na awarię i zapewnić, że zostanie przywrócony do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Ze względu na przechwytywanie historii zmian w złożonym procesie biznesowym może ułatwić rekonstrukcję stanu, jeśli trzeba odzyskać magazyny stanów. - PARTYcjonowanie danych RE:06 - RE:09 Odzyskiwanie po awarii
Wydajność pomagawydajnie sprostać zapotrzebowaniu dzięki optymalizacjom skalowania, danych, kodu.	Ten wzorzec, zwykle w połączeniu z usługą CQRS, odpowiedni projekt domeny i strategiczne tworzenie migawek, może poprawić wydajność obciążenia ze względu na niepodzielne operacje tylko do dołączania i unikanie blokowania bazy danych dla zapisów i odczytów. - PE:08 Wydajność danych

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

System zarządzania konferencjami musi śledzić liczbę ukończonych rezerwacji na konferencji. W ten sposób może sprawdzić, czy są jeszcze dostępne miejsca, gdy potencjalny uczestnik próbuje dokonać rezerwacji. System może przechowywać łączną liczbę rezerwacji dla danej konferencji na co najmniej dwa sposoby:

• System może przechowywać informacje o całkowitej liczbie rezerwacji jako osobne jednostki w bazie danych, która przechowuje informacje o rezerwacji. W momencie dokonywania lub anulowania rezerwacji system może odpowiednio powiększyć lub pomniejszyć tę liczbę. Ta metoda teoretycznie jest prosta, lecz może powodować problemy ze skalowalnością w przypadku dużej liczby uczestników próbujących zarezerwować miejsce w krótkim czasie. Na przykład w ostatni dzień lub przed zamknięciem okresu rezerwacji.

• System może przechowywać informacje o dokonanych i anulowanych rezerwacjach jako zdarzenia przechowywane w magazynie zdarzeń. Następnie może obliczyć liczbę dostępnych miejsc przez odtworzenie tych zdarzeń. Ta metoda może być bardziej skalowalna dzięki niezmienności zdarzeń. System musi jedynie mieć możliwość odczytywania danych z magazynu zdarzeń lub dołączania danych do magazynu zdarzeń. Informacje zdarzeń o dokonaniu i anulowaniu rezerwacji nigdy nie są modyfikowane.

Na poniższym diagramie pokazano, w jaki sposób za pomocą określania źródła zdarzeń można zaimplementować podsystem rezerwacji miejsc systemu zarządzania konferencjami.

Sekwencja akcji mających na celu zarezerwowanie dwóch miejsc jest następująca:

1. Interfejs użytkownika wydaje polecenie w celu zarezerwowania miejsc dla dwóch uczestników. Polecenie jest obsługiwane przez oddzielny program obsługi poleceń. Jest to fragment logiki, który jest całkowicie niezależny od interfejsu użytkownika i który jest odpowiedzialny za obsługę żądań publikowanych jako polecenia.

2. Jednostka zawierająca informacje o wszystkich rezerwacjach konferencji jest tworzona przez wykonywanie zapytań dotyczących zdarzeń opisujących rezerwacje i anulowania. Ta jednostka jest nazywana SeatAvailability, i jest zawarta w modelu domeny, który uwidacznia metody wykonywania zapytań i modyfikowania danych w jednostce.

   Niektóre optymalizacje do rozważenia korzystają z migawek (dzięki czemu nie trzeba wykonywać zapytań i powtarzać pełnej listy zdarzeń w celu uzyskania bieżącego stanu jednostki) i obsługi buforowanej kopii jednostki w pamięci.

3. Program obsługi poleceń wywołuje metodę udostępnianą przez model domeny, aby dokonać rezerwacji.

4. Jednostka SeatAvailability zgłasza zdarzenie zawierające liczbę miejsc zarezerwowanych. Następnym razem, gdy jednostka zastosuje zdarzenia, wszystkie rezerwacje będą używane do obliczenia liczby pozostałych miejsc.

5. System dołącza nowe zdarzenie do listy zdarzeń w magazynie zdarzeń.

Jeśli użytkownik anuluje rezerwację, system wykonuje podobną procedurę, z tą różnicą, że program obsługi poleceń wydaje polecenie, które generuje zdarzenie anulowania miejsca i dołącza je do magazynu zdarzeń.

Oprócz zapewnienia większego zakresu skalowalności, korzystanie z magazynu zdarzeń zapewnia również pełną historię lub dziennik inspekcji rezerwacji i anulowania na konferencji. Zdarzenia w magazynie zdarzeń są precyzyjnymi rekordami. Nie ma potrzeby utrwalania agregacji w żaden inny sposób, ponieważ system może łatwo odtworzyć zdarzenia i przywrócić stan do dowolnego punktu w czasie.

Następne kroki

• Niezgodność impedancji relacyjnej obiektu

• Podstawy spójności danych. Jeśli używasz określania źródła zdarzeń z oddzielnym magazynem odczytu lub zmaterializowanymi widokami, dane odczytu nie będą natychmiast spójne. Zamiast tego dane będą ostatecznie spójne. W tym artykule przedstawiono podsumowanie problemów związanych z utrzymaniem spójności w przypadku danych rozproszonych.

• Data Partitioning Guidance (Wskazówki dotyczące partycjonowania danych). Dane są często partycjonowane w przypadku używania określania źródła zdarzeń w celu zwiększenia skalowalności, zmniejszenia rywalizacji i optymalizacji wydajności. W tym artykule opisano sposób dzielenia danych na odrębne partycje oraz problemy, które mogą wystąpić.

• Blog Martina Fowlera:

  • Określanie źródła zdarzeń
  • Migawka w witrynie internetowej Martina Fowlera Enterprise Application Architecture

Powiązane zasoby

Podczas implementowania tego wzorca mogą być istotne następujące wzorce i wskazówki:

• Wzorzec podziału odpowiedzialności polecenia i zapytania (CQRS). Magazyn zapisu, który zapewnia stałe źródło informacji dla implementacji CQRS, często opiera się na implementacji wzorca określania źródła zdarzeń. Opisuje sposób segregowania operacji, które odczytują dane w aplikacji, od operacji, które aktualizują dane przy użyciu osobnych interfejsów.

• Materialized View pattern (Wzorzec zmaterializowanego widoku). Magazyn danych używany w systemie opartym na określaniu źródła zdarzeń zwykle nie nadaje się do wydajnego wykonywania zapytań. Zamiast tego typowym podejściem jest generowanie wstępnie wypełnionych widoków danych w regularnych odstępach czasu lub po zmianie danych.

• Wzorzec transakcji wyrównującej. Istniejące dane w magazynie określania źródła zdarzeń nie są aktualizowane. Zamiast tego dodawane są nowe wpisy, które przechodzą stan jednostek do nowych wartości. Aby odwrócić zmianę, używane są wpisy wyrównywujące, ponieważ nie jest możliwe odwrócenie poprzedniej zmiany. Wzorzec opisuje, w jaki sposób cofnąć działanie wykonane przez poprzednią operację.