ארכיטקטורת אירועים

ארכיטקטורת אירועים (EDA)

1) מהו מאורע ומדוע EDA

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

EDA לא מבטל API סינכרוני - זה משלים אותם על ידי הבאת תלויות שירות צולבות בשכבה האסינכרונית.

2) סוגי אירועים

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

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

3) חוזי אירועים ותרשימים

Evro/Protobuf/JSON Schema + Schema Registry; אסטרטגיית תאימות: ”אחורה” לאבולוציה צרכנית, ”מלא” בנושאים קריטיים.
אירועים שונים (id, מקור, סוג, זמן, נושא, datacontentype) - כותרות אחידות.
metadata: "event _ id' (ULID/UUID)," התרחש _ at "," מפיק "," schema _ version "," correlation _ id'/" causation _ id', "idempotency _ key".
Versioning: להוסיף רק שדות, איסור על שינוי שם/הפסקות סמנטיות; סוגים חדשים - נושאים/סוגים חדשים.

json
{
"type":"record","name":"PaymentCaptured","namespace":"events.v1",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"payment_id","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":"string"},
{"name":"player_id","type":"string"}
]
}

4) משלוח, סדר ועקביות

לפחות פעם אחת כברירת מחדל.
סדר: מובטח בתוך מפלגה (קפקא) או תור (רביב-קיו), אך עלול להישבר על ידי נסיגות; מפתח האירוע חייב לשקף תחום של סדר (לדוגמה, "player _ id').
עקביות: עבור כסף/הלוואות - רק באמצעות כתבי עת/סאגות/פיצויים; הימנע LWW.

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

5) Outbox/Inbox SuperCDC

Outbox: השירות כותב עובדה למסד הנתונים שלו ולשולחן היוצא בעסקה אחת כפול העובד מפרסם לאוטובוס.
תיבת דואר אלקטרוני: המאורע _ id 'with procession court for deflication.
CDC (Change Data Capture): זרימה של שינויים מבסיס הנתונים (binlog/WAL) לאוטובוס כדי לבנות אינטגרציות ללא שינויי יישום.
idempotency: עיבוד על ידי "idempotency _ key "/" event _ id', לא משנה את העולם החיצון עד קבוע.

6) מיקור אירועים CQRS

CQRS: מודל כתיבה נפרד ותחזיות קריאה; התחזיות בנויות מאירועים ויכולות לפגר מאחור.
מקור אירועים: מצב צבירה = גלגול של האירועים שלה. יתרונות: ביקורת מלאה/שידור חוזר; חסרונות: מורכבות של נדידה/מזימות/תמונות.
מנהג: ES - לא בכל מקום, אלא במקום שבו ההיסטוריה והפיצוי חשובים; CQRS - כמעט תמיד ב EDA.

7) סאגות: תזמור וכוריאוגרפיה

תזמור: המתאם שולח פקודות ומחכה לאירועי תגובה; נוח לתהליכים מורכבים (KYC # Deposit # Bonus).
כוריאוגרפיה: שירותים מגיבים זה לזה; קל יותר אבל קשה יותר לאתר.
תמיד להגדיר פיצויים ומועדי שלב.

8) עיצוב טופולוגיה (קפקא/רביב-קיו)

קפקא

נושא לאירוע תחום: "תשלומים. שבויים. v1 ',' שחקנים. מאומת. v1 '.
מחלק מפתח: ”player _ id'/” arnet _ id' - היכן שהסדר חשוב.
'חישוב מחדש. פקטור = 3 ',' דקות. insync. העתקים = 2 ', מפיק' acks = all'.
שימור: בזמן (למשל. 7-90 ימים) ו/או דחיסה (המדינה האחרונה לפי מפתח).
נושאים לניסוי חוזר ודי-אל-קיו עם גיבוי.

RabbitMQ

החלפות: "נושא "/" ישיר", ניתוב מקש "תשלומים. שבויים. v1 '.
עבור מאוורר רחב - 'נושא' + כמה תורים; עבור RPC/פקודות - תורים נפרדים.
תורים של קוורום עבור HA; החלפת אותיות מתות ב-TTL.

9) יכולת תצפית ו ־ SLO eda

• latency (occurred_at acted): p50/p95/p99.
• Lag/age: עיכוב צרכני (Kafka processor lag, Rabbit backlog age).
• דרך הוצאה לאור/עיבוד.
• קצב DLQ ופרופורציה של חזרות.
• הצלחה של עסקאות (למשל: ”הפקדה אישרה רישום 5C”).

מנהגים: ‏

קורלציה של אירועים באמצעות 'trace _ id'/' correlation _ id' (Otel).
מקרים מאיזון = מדדים.
לוחות מחוונים ”Producer # Broker # Consumer” עם התראות שרפה.

10) שידור חוזר, שימור ומילוי גב

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

11) בטיחות וציות

TLS במעבר, MTLS ללקוחות פנימיים.
אישור: לכל נושא/לכל חילוף ACL; רב-גוניות באמצעות שם/ווסט.
PII: למזער שדות במקרה; מעטפת metadata בנפרד, תשלום מוצפן במידת הצורך.
ביקורת גישה לאירועים, לאסור מפתחות ”כל-יכול”.
מדיניות Reservation and Right to Delete (GDPR): אזכור נתונים או אירועים במצבה ומחיקה בתחזיות.

12) בדיקות באדה

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

13) הגירה של ”CRUD Integrations # EDA”

1. זהה את עובדות התחום.
2. מוטבע יוצא בשירותי המקור.
3. לפרסם אירועי דומיין מינימליים ולחבר 1-2 תחזיות.
4. נטרל בהדרגה אינטגרציות סינכרוניות של נקודה, והחלפתם במנויים.
5. תרשים סוג ומדיניות תאימות.
6. להאריך אירועי הוספה בלבד עם שדות; פורצת רק דרך סוגים חדשים.

14) אנטי דפוסים

אירועים = ”DTO API” (שמן מדי, תלוי במודל פנימי) - לשבור צרכנים.
חוסר רישום סכמות ותאימות - שילוב ”שברירי”.
פרסום מקוד וכתיבה לבסיס הנתונים אינם אטומיים (אין תיבת יוצא) - אתה מאבד אירועים.
”בדיוק פעם אחת בכל מקום” - מחיר גבוה ללא תועלת; טוב יותר לפחות פעם אחת עם אידמפוטנטיות.
אחד ”אוניברסלי” מפתח מחיצה = מחיצה חמה.
שידור חוזר היישר אל תוך הקרנת הייצור - שובר סל "ד מקוון.

15) רשימת יישומים (0-45 ימים)

0-10 ימים

זהה את אירועי התחום ואת המפתחות שלהם (גרנולות של סדר).
לפרוס את סכימה רישום ולאשר את אסטרטגיית התאימות.
הוסף תיבת היוצא/תיבת הדואר הנכנס לשירותי 1-2; מעטפת אירועי קלוד מינימלית.

11-25 ימים

הזן Retry/DLQ, גיבוי, אידמפוטנטיות של מפעילים.
לוחות מחוונים: lag/age/end-to-end; התראות על שרפה.
תיעוד אירועים (קטלוג), בעלים ותהליכי סקירה.

26-45 ימים

שידור חוזר/סידור מחדש של ההקרנה הראשונה; ריצה חוזרת ומילוי אחורי.
מדיניות אבטחה (TLS, ACL, PII), שימור, נהלי GDPR.
תוהו ובוהו רגיל וימי משחק לברוקר ולצרכנים.

16) מדדי בגרות

100% מאירועי התחום מתוארים על ידי מזימות ורשום.
תיבת הדואר היוצא מכסה Tier-0/1 כל היצרנים/הצרכנים.
p95 latency-to-end ו lag צרכני בתוך מטרות ו 99%.
הילוך חוזר/הילוך אחורי הם אפשריים ללא השבתה; יש ספרי הפעלה מאומתים 'ו.
ורסיונינג: שדות חדשים - ללא שבירה; צרכנים ישנים לא נופלים.
אבטחה: TLS + mTLS, ACL לכל נושא, יומני גישה, מדיניות PII/שימור.

17) קטעים קטנים

properties acks=all enable.idempotence=true max.in.flight.requests.per.connection=1 compression.type=zstd linger.ms=5

python if inbox.contains(event_id): return # дедуп process(event)            # побочные эффекты детерминированы inbox.commit(event_id)        # atomically with side-effect commit_offset()

• Queue: משימות "= על נאק = DLX 'משימות. לנסות מחדש. 1M (TTL = 60) # לחזור 'Tasks'; עוד 5 מטר/15 מטר.

18) מסקנה

EDA הופך אינטגרציה לזרם של עובדות עסקיות עם חוזים ברורים וניהול עקבי. לבנות את היסודות: תרשימים + רישום, תיבת יוצא/תיבת דואר אלקטרוני, מפתחות הזמנה, מפעילים אידמפוטנטים, SLO ויכולת תצפית, שמירה בטוחה ושידור חוזר. אזי, יהיו המאורעות ”מקור האמת” שלך להגדרה, אנליטיקה ותכונות חדשות - ללא קשרים שבריריים ונדידת לילה. ‏