Jądro Event-Driven
Czym jest jądro Event-Driven
Event-Driven Core (EDC) jest „kręgosłupem” architektury, w którym fakty biznesowe są przechwytywane i rozpowszechniane jako zdarzenia niezmienne, a reszta funkcjonalności (czytanie, integracja, analityka, bufory, powiadomienia) jest zbudowana na szczycie przepływu tych wydarzeń. Jądro ustawia kontrakt na zdarzenie, zasady dostawy i niezmienność zamówienia/idempotencji, zapewniając słabą łączność i skalowalność.
Kluczowy pomysł: najpierw zapisz fakt (rdzeń), a następnie niezależnie wzbogacić i przenieść go do pożądanych modeli. Zmniejsza to łączność i zwiększa odporność na częściowe awarie.
Cele i właściwości EDC
Prawda o faktach: Każde wydarzenie jest niezmiennym zapisem „tego, co się stało”.
Słaba łączność: Producenci nie znają konsumentów; rozszerzenie systemu - poprzez dodanie abonentów.
Skalowanie: wzrost horyzontalny według partii/tematu, niezależnych konsumentów.
Obserwowalność i audyt: identyfikatory typu end-to-end, odtwarzalność, retencje i powtórzenie.
Ewolucja zarządzana: wersje schematu, kompatybilność, deprecacja.
Elementy architektoniczne
1. Bus/event broker: Kafka/NATS/Pulsar/SNS + SQS - kanały, imprezy, retencje.
2. Rejestr schematu: JSON Schema/Avro/Protobuf dla kompatybilności i ewolucji.
3. Kontur Outbox/CDC: naprawianie faktów atomowych + publikowanie bez „podwójnego zapisu”.
4. Projekcje/odczyty (CQRS): zmaterializowane widoki dla szybkich zapytań.
5. Sagi/orkiestra: koordynacja długotrwałych procesów poprzez wydarzenia/zespoły.
6. Wzbogacanie: poszczególne tematy '.enriched '/' .derived' without wpływające na ścieżkę krytyczną.
7. Obserwowalność: śledzenie, rejestrowanie, mierzenie według zdarzeń i opóźnień.
Model zdarzenia
Typy zdarzeń
Zdarzenia domeny: Fakty biznesowe ('płatność. autoryzowany „,” kyc. zatwierdzone ").
Wydarzenia integracyjne: skoncentrowane na systemach zewnętrznych (stabilne, powoli zmieniające się).
Zmiana przechwytywania danych (CDC): techniczne zmiany w zapisie (wykorzystanie do migracji/integracji).
Audyt/telemetria: działania aktorskie, bezpieczeństwo, SLA.
Wymagane atrybuty (rdzeń)
json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}Zalecenia: 'event _ id' jest globalnie unikalny,' partition _ key 'ustawia kolejność dla podmiotu,' trace _ id' zapewnia korelację.
Semantyka dostawy i idempotencja
Przynajmniej raz (domyślnie dla wielu brokerów): Konsumenci muszą być idempotentni.
Najwyższa dopuszczalna tylko dla telemetrii wtórnej.
Dokładnie raz: osiągnięty na poziomie przepływu i magazynowania poprzez transakcje/idempotent keys/podlewania puszek (droższe, potrzebują dobrego powodu).
Wzorzec idempotencji konsumentów
Dedup table by 'event _ id'/' (event_id, consumer_id)' with TTL ≥ topic retention.
Upsert zamiast wstawić; projekcje versioning przez 'sequence '/' occurred _ at'.
Transakcje w ramach transakcji: znak „saw” + zmiana stanu.
Zamówienie i podział
Gwarantowane zamówienie w ramach strony.
Wybierz 'partition _ key' tak, aby wszystkie zdarzenia tego samego zagregowanego podmiotu wchodziły w tę samą partię ('user _ id',' payment _ id').
Unikaj „gorących klawiszy”: skrótu z soli/subkluczy, jeśli trzeba rozprowadzić ładunek.
Programy i ewolucja
Dodatek-pierwszy: nowe pola opcjonalne, zakaz zmiany typów/semantyki bez większej wersji.
Zgodność: BACKWARD/FORWARD w rejestrze schematu; CI blokuje niezgodne zmiany.
Nazwa: 'domena. działania. v {major} '("płatność. autoryzowany. v1 ").
Migracje: publikować równolegle pary 'v1' i 'v2', dostarczać podwójne zapisy przez skrzynkę zewnętrzną, strzelać 'v1' po przejściu.
Outbox (CDC)
Outbox (zalecane dla usług transakcyjnych)
1. W jednej transakcji bazodanowej: zapisz rekord domeny i zdarzenie do skrzynki outbox.
2. Tło wydawca czyta skrzynkę, publikuje brokerowi, znaki „wysłane”.
3. Gwarancje: brak „utraty” faktów w upadkach, brak desynchronizacji.
CDC (Zmiana przechwytywania danych)
nadaje się do istniejących systemów/migracji; source - dziennik replikacji DB.
Wymaga filtrowania/transkodowania do zdarzeń domeny (nie tłumaczyć tabel surowych na zewnątrz).
CQRS i projekcje
Polecenia zmieniają stan (często synchronicznie), zdarzenia tworzą projekcje (asynchronicznie).
Projekcje przeznaczone są dla zapytań (wyszukiwanie, listy, raporty), aktualizowanych przez abonentów.
Tymczasowa desynchronizacja jest normą: pokaż stabilny UX („dane będą aktualizowane w ciągu kilku sekund”).
Sagi: Koordynacja procesów
Orkiestra: Jeden koordynator wysyła polecenia i czeka na wydarzenia.
Choreografia: uczestnicy reagują na swoje wydarzenia (prostsze, ale wymaga dyscypliny w umowach).
Zasady: jasne rekompensaty i terminy, powtarzalne kroki, opiekunowie idempotent.
Obserwowalność
Trace/Span: Trace 'trace _ id'/' span _ id' przez nagłówki podczas generowania zdarzeń.
Wskaźniki: opóźnienie konsumenckie, wskaźnik publikacji/konsumpcji, wskaźnik martwych listów, udział w deduplikacji.
DLQ/parking: nieudane wiadomości - na osobny temat z powiadomieniem; zapewnić ponowne przetwarzanie.
Bezpieczeństwo i zgodność
Klasyfikacja danych: rdzeń zawiera tylko wymagane minimum danych PII/finansowych (model odwrotnej piramidy), szczegóły - w wzbogaceniu.
Podpis/hash atrybutów krytycznych, kontrola integralności.
Szyfrowanie podczas lotu i podczas odpoczynku, prawa podziału według tematu/użytkownika (IAM/ACL).
Polityka zatrzymywania i prawa do zapomnienia: jasno określone dla każdego tematu.
Wydajność i stabilność
Wsparcie: konsumenci mają ograniczoną konkurencję, pośrednik ma limity/limity.
Rekordy grupy partii i kompresji w celu zmniejszenia napowietrzności.
Retrai z jitter i DLQ zamiast niekończących się prób.
Rezystancja: przechowywać przesunięcia transakcyjne/zewnętrzne, przyspieszyć zimny start z migawkami.
Typowe szablony zdarzeń
Rdzeń płatności
"płatność. zainicjowane. v1 „→” płatność. autoryzowany. v1 „→” płatność. schwytany. v1 „→” płatność. załatwione. v1 "
Odmowa: "płatność. odmówił. v1 „,” płatność. zwrócone. v1 "
Podział: 'payment _ id'
SLA: rdzeń lag ≤ 2c p95; Idempotencja konsumentów jest obowiązkowa.
CCM/weryfikacja
'kyc. zaczęło się. v1 '→' kyc. dokument. otrzymane. v1 '→' kyc. zatwierdzone. v1 '/' kyc. odrzucone. v1 "
PII - minimalne; szczegóły dokumentu - in 'kyc. wzbogacony. v1 'z ograniczonym dostępem.
Audyt/Bezpieczeństwo
'audit. zarejestrowane. v1 „z atrybutami” aktor „,” subject „,” action „,” occurred _ at „,” trace _ id'.
Ciągłe przechowywanie/archiwizowanie; Zwiększona integralność (WORM)
Antypattery
Fat Event: przeładowane ładunki bez konieczności, wycieki PII.
Ukryty RPC poprzez wydarzenia: czekanie na synchroniczne odpowiedzi „tutaj i teraz”.
Surowe płyty CDC na zewnątrz: Bliskie połączenie z schematem DB.
Brak idempotencji u konsumentów: podwójne działania prowadzą do podwójnych skutków ubocznych.
Jeden wspólny temat „za wszystko”: konflikt interesów, problematyczny porządek, złożona ewolucja.
Wdrażanie EDC krok po kroku
1. Mapowanie domeny: Podświetl agregaty kluczy i cykle życia.
2. Katalog wydarzeń: nazwy, znaczenia, niezmienne, wymagane pola.
3. Schematy i rejestr - Wybierz format, włącz zasady kompatybilności.
4. Outbox/CDC: Dla każdego producenta należy określić mechanizm publikowania faktów.
5. Partycjonowanie: Wybierz klucze i ocenić gorące klucze/rozkład.
6. Idempotencja: schemat deduplikacji + transakcje konsumenckie.
7. Projekcje-Zdefiniuj zmaterializowane modele i aktualizuj SLA.
8. Obserwowalność: śledzenie, lagi, DLQ, alerty.
9. Bezpieczeństwo/PII: klasyfikacja danych, szyfrowanie, ACL.
10. Przewodnik po ewolucji: polityka wersji, deprecate, dual-write dla migracji.
Lista kontrolna produkcji
- Każde zdarzenie ma 'event _ id',' trace _ id', 'occurred _ at', 'partition _ key'.
- Systemy w rejestrze, włączone kontrole zgodności.
- Tożsamość konsumenta wdrożona i przetestowana.
- DLQ/parking i alerty są skonfigurowane dla błędów publikowania/konsumpcji.
- Projekcje są odtwarzane z dziennika (powtórka) z dopuszczalnym czasem.
- Ograniczony dostęp do PII; minimalny ładunek jest w jądrze.
- SLA według opóźnień/dostawy są mierzone i widoczne na deskach rozdzielczych.
- Istnieje plan migracji wersji zdarzeń i zdeprecate okien.
NAJCZĘŚCIEJ ZADAWANE PYTANIA
Jak EDC różni się od „tylko autobusem”?
Rdzeniem jest nie tylko broker, ale także kontrakt na imprezy, zasady porządku/idempotencji, procesy ewolucji i obserwowalność.
Możemy budować tylko na CDC?
CDC nadaje się do integracji/migracji, ale zdarzenia domeny wyrażają znaczenie jaśniej i doświadczają bardziej stabilnych zmian bazy danych.
A co z konsystencją?
Akceptujemy ewentualną spójność i projektowanie UX/procesów dla niego (wskaźniki aktualizacji, przekwalifikowania, kompensacji).
Kiedy jest potrzebny?
Rzadko: gdy podwojenie jest ściśle niedopuszczalne i niemożliwe do zrekompensowania. Częściej wystarczy przynajmniej raz + idempotencja.
Razem
Jądro Event-Driven przekształca przepływ faktów biznesowych w niezawodny fundament systemu. Jasne kontrakty na imprezy, dyscyplina dostaw i obserwowalność wydajność skalowalność, odporność i tempo ewolucji - bez delikatnych połączeń synchronicznych i „burza” regresji w trakcie zmian.