גרעין מונע אירועים

מהו גרעין מונע אירועים

ה-Event-Drived Core (בראשי תיבות: EDC) הוא עמוד השדרה של הארכיטקטורה, שבו עובדות עסקיות נתפסות ומופצות כאירועים בלתי ניתנים לשינוי, ושאר הפונקציונליות (קריאה, אינטגרציה, אנליטיקה, מטמונים, הודעות) בנויה על גבי זרימת אירועים אלה. הליבה קובעת את חוזה האירוע, כללי המשלוח, וסדר/אידמפוטנטיות אינווריאנטים, מתן קישוריות חלשה וסקלביליות.

הרעיון המרכזי: תחילה לרשום את העובדה (ליבה), ולאחר מכן להעשיר באופן עצמאי ולהקרין אותו לתוך המודלים הרצויים. זה מפחית את הקישוריות ומגביר את העמידות לכישלונות חלקיים.

יעדים ומאפיינים EDC

אמת בעובדות: כל מאורע הוא תיעוד בל יתואר של ”מה שקרה”.
קישוריות חלשה: יצרנים לא מכירים צרכנים; הרחבת המערכת על ידי הוספת מנויים.
הגדלה אופקית לפי צד/נושא, צרכנים עצמאיים.
תצפית וביקורת: זיהוי מקצה לקצה, רבייה, חזרה ושידור חוזר.
אבולוציה מנוהלת: סכימה גרסאות, תאימות, ירידה.

רכיבים ארכיטקטוניים

1. Bus/Event Broker: Kafka/NATS/Pulsar/SNS + SQS - ערוצים, צדדים, חזרות.
2. סכימה: JSON Schema/Avro/Protobuf עבור תאימות ואבולוציה.
3. Outbox/CDC contour: עובדה אטומית מתקנת + publishing ללא ”כתיבה כפולה”.
4. תחזיות/קריאות (CQRS): תצוגות ממשיות לשאילתות מהירות.
5. Sagas/תזמור: תיאום של תהליכים ארוכי חיים באמצעות אירועים/צוותים.
6. העשרה: נושאים בודדים ". enriched '/'. נגזר 'ללא השפעה על הנתיב הקריטי.
7. תצפית: איתור, כריתת עצים, מדדים על ידי אירועים ופיגומים.

מודל האירוע

סוגי אירועים

אירועי דומיין: עובדות עסקיות ('תשלום. מורשה ", קיק. אושר).
אירועי אינטגרציה: התמקדות במערכות חיצוניות (יציבות, משתנות לאט).
Change Data Capture (CDC): שינויים טכניים ברישום (שימוש בנדידה/אינטגרציה).
Audit/Telemetry: פעולות שחקן, אבטחה, SLA.

תכונות דרושות (ליבה)

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"
}

המלצות: ”event _ id' הוא ייחודי גלובלית,” partion _ key ”קובע את הסדר עבור הישות,” trace _ id' מספק קורלציה.

סמנטיקה מסירה ואימפוטנציה

לפחות פעם אחת (ברירת המחדל של ברוקרים רבים): הצרכנים נדרשים להיות אידיוטים.
מקובלת רק על טלמטריה משנית.
בדיוק-פעם אחת: הושג ברמת הזרימה והאחסון באמצעות עסקאות/מפתחות אידמפוטנטים/פחיות השקיה (יקר יותר, צריך סיבה טובה).

תבנית אידמפוטנטיות צרכנית

טבלת dedup by "event _ id'/" (event_id, consumer_id)" עם שמירת נושא TTL.
עייף במקום להכניס; תחזיות versiening על ידי 'רצף '/' התרחש _ at'.
עסקאות במסגרת העסקה: סימן ”ראה” + שינוי מצב.

סדר ומחיצה

סדר מובטח בתוך המפלגה.
בחר ”מחיצה _ key” כך שכל האירועים של אותה ישות צבירה ייפלו לאותה קבוצה (”user _ id',” payment _ id').
הימנע מ ”מפתחות חמים”: חשיש עם מלח/תת-מפתחות אם אתה צריך לחלק את המטען.

סכמות ואבולוציה

שדות אופציונליים חדשים, איסור על שינוי סוגים/סמנטיקה ללא גרסה עיקרית.
תאימות: BACWARD/FORWARD במרשם הסכמות; בלוקים שינויים בלתי מתאימים.
שמות: "תחום. פעולה. וי מייג 'ור (' תשלום. מורשה. v1 '.
נדידה: לפרסם זוגות 'v1&fospos ו' v2&fshoft במקביל, לספק דו-כתיבה דרך outbox, לירות 'v1&fsofft לאחר המעבר.

Outbox SustCDC

Outbox (מומלץ לשירותים עסקיים)

1. בעסקת מסד נתונים אחת: שמירת שיא התחום והאירוע לתיבת היוצא.
2. מו "ל הרקע קורא את התיבה היוצאת, מפרסם לברוקר, מסמן" נשלח ".
3. ערבויות: לא ”אובדן” עובדה בנפילות, לא ייאוש.

CDC (לכידת נתונים שינוי)

מתאים למערכות קיימות/נדידה; יומן שכפול מקור DB.
דורש סינון/טרנספורמציה לאירועי תחום (לא לתרגם טבלאות גולמיות בחוץ).

CQRS ותחזיות

פקודות משנות מצב (לרוב באופן סינכרוני), אירועים יוצרים תחזיות (אסינכרוני).
התחזיות מיועדות לשאילתות (חיפוש, רשימות, דוחות), מעודכנות על ידי המנויים.
דסינכרוניזציה זמנית היא הנורמה: הצג UX יציב (”הנתונים יעודכנו תוך מספר שניות”).

סאגות: תיאום תהליכים

מתאם אחד שולח פקודות ומחכה לאירועים.
כוריאוגרפיה: המשתתפים מגיבים אחד לשני באירועים (פשוט יותר, אבל דורש משמעת בחוזים).
חוקים: פיצויים ברורים ופסקי זמן, צעדים ניתנים לחזרה, מפעילים מפוקפקים.

תצפית

Trace/Span: trace 'trace _ id '/' span _ id' דרך הכותרות בעת יצירת אירועים.
מדדים: פיגור צרכני, שיעור הוצאה לאור/צריכה, תעריף אותיות מתות, נתח שכפול.
DLQ/חניון: הודעות לא מוצלחות - לנושא נפרד עם התראה; לספק עיבוד מחדש.

ביטחון וציות

סיווג נתונים: הליבה מכילה רק את המינימום הנדרש של מידע פירמידה הפוך (PII/financial data), פרטים - בהעשרה.
חתימה/חשיש של תכונות קריטיות, שליטה בשלמות.
הצפנה במעוף ומנוחה, חלוקת זכויות על ידי נושא/צרכן (IAM/ACL).
מדיניות שמירה וזכויות שיש לשכוח: מוגדרת בבירור לכל נושא.

ביצועים ויציבות

Backpresser: לצרכנים יש תחרות מוגבלת, לברוקר יש מכסות/מגבלות.
רישומי קבוצה ודחיסה כדי להפחית את התקורה.
רטריי עם ג 'יטר ודי-אל-קיו במקום ניסיונות אינסופיים.
איזון-התנגדות: לאחסן קיזוזים באופן טרנספקטיבי/חיצוני, להאיץ התחלה קרה עם תמונות.

תבניות אירוע טיפוסיות

ליבת תשלום

"פאיימנט. יזמה. התשלום של v1. מורשה. התשלום של v1. שבויים. התשלום של v1. התיישבו. v1&fost

סירוב: 'תשלום. סירבה. v1 ',' תשלום. מוחזר בחזרה. v1&fost

החלוקה: "תשלום _ id&fost

SLA: Lig core 2c p95; חוסר אונים צרכני הוא חובה.

CCM/אימות

”קיק”. התחיל. v1 '0' kyc. מסמך. התקבלה. v1 '0' kyc. מאושר. v1 '/' קייק. נדחה. v1&fost

PII - מינימלי; פרטי מסמך - in 'kyc. מועשר. עם גישה מוגבלת.

audit/Security

ביקורת חשבונות. מוקלט. v1 'עם תכונות' שחקן ',' נושא ',' פעולה ',' התרחש _ at ',' trace _ id'.

שימור רציף/ארכיון; שלמות מוגברת (תולעת)

Antipatterns

אירוע שומן: עומס יתר על המטען ללא צורך, דליפות מח "ש.
RPC מוסתר דרך אירועים: מחכה לתגובות סינכרוניות ”כאן ועכשיו”.
סריקת CDCs גולמית כלפי חוץ: קישוריות קרובה לסכימת DB.
אין חוסר אונים בצרכנים: כפילים מובילים לתופעות לוואי כפולות.
נושא משותף אחד ”לכל דבר”: ניגוד אינטרסים, סדר בעייתי, אבולוציה מורכבת.

צעד אחר צעד EDC מימוש

1. מיפוי דומיין: הדגש על צבירים מרכזיים ועל גלגלי חיים.
2. קטלוג אירועים: שמות, משמעויות, אינווריאנטים, שדות נדרשים.
3. תרשימים ורשימות - בחר פורמט, אפשר כללי תאימות.
4. עבור כל מפיק, הגדר מנגנון לפרסום עובדות.
5. מחיצה: בחר מפתחות ועריך מפתחות חמים/תזכורת.
6. Idempotency: description description + transactionליות צרכנית.
7. תחזיות - הגדר מודלים ממשיים ועדכון SLAs.
8. תצפית: איתור, פיגור, DLQ, התראות.
9. אבטחה/PII: סיווג נתונים, הצפנה, ACL.
10. מדריך לאבולוציה: מדיניות גירסה, פחת, דו-כתיבה לנדידה.

רשימת בדיקות ייצור

[ ] לכל אירוע יש ”event _ id',” trace _ id', ”at”, ”partion _ key”.

[ מזימות ] ברישום, בדיקות תאימות אפשרו.

[ ] זהות הצרכן מיושמת ונבדקת.

[ ] DLQ/חניון והתראות מוגדרות לפרסום/לצרוך שגיאות.

[ ] התחזיות נוצרות מחדש מהרישום (שידור חוזר) בזמן מקובל.

[ ] גישה מוגבלת למח "ש; המטען המינימלי נמצא בגרעין.

[ ] SLAA על ידי lags/Liver נמדדים ונראים על לוחות מחוונים.

[ ] יש תוכנית לגרסאות אירוע נודד ופחת חלונות.

FAQ

איך EDC שונה מ ”רק אוטובוס”?
הליבה היא לא רק הברוקר, אלא גם חוזה האירועים, כללי סדר/אידמפוטנטיות, תהליכי אבולוציה ויכולת תצפית.

אפשר לבנות רק על המרכז לבקרת מחלות?
CDC מתאים לאינטגרציות/הגירות, אך אירועי דומיין מבטאים משמעות ברורה יותר ומסד נתונים חווייתי משתנה באופן יציב יותר.

מה לגבי עקביות?
אנו מקבלים בסופו של דבר את העקביות והעיצוב של UX/תהליכים (אינדיקטורים של עדכון, מגש מחדש, פיצוי).

מתי בדיוק צריך פעם אחת?
נדיר: כאשר הכפלות אינן מקובלות ובלתי ניתנות לפיצוי. לעתים קרובות יותר, לפחות פעם אחת + אידמפוטנטיות מספיקה.

סך הכל

הליבה מונעת אירועים הופכת את זרימת העובדות העסקיות ליסוד אמין למערכת. חוזי אירועים ברורים, משמעת מסירה ויכולת תצפית מניבים קשקשים, עמידות ושיעור האבולוציה - ללא הקשרים הסינכרוניים השבריריים ו ”סערה” של רגרסיה תחת שינוי.