Event-Driven Architecture
מדובר בארכיטקטורה אסינכרונית מבוזרת דיי נפוצה בתעשייה לבניית אפליקציות סקיילביליות (ניתנות להרחבה). ליבת השיטה היא דרך התקשורת בין הרכיבים השונים במערכת ששולחים האחד לשני “אירועים” (Events).
כאשר שירות מסויים מבצע פעולה כלשהי ששירותים אחרים עשויים להתעניין בה, אנו נדאג שהשירות ישלח בעת הסיום את העדכון/האירוע אל מנגנון ההודעות. לאחר השליחה – כל השירותים שנרשמו כצרכנים יעודכנו על הפעולה שהסתיימה וכך יוכלו לבצע המשך פעולות בלתי תלויות משלהם הנדרשות כתוצאה מהאירוע.
בניגוד לשיטת התקשורת המסורתית (לדוגמא TCP או Rest API או תקשורת HTTP בכלל) בגישה הזו השירותים שיוצרים אירועים אינם צריכים להכיר את פרטי היעד או בכלל מי הם השירותים שיקבלו את עדכוני האירוע.
ניתן לפרסם אירועים במגוון דרכים, למשל – ניתן לפרסם אותם לתור הודעות המבטיח מסירת האירוע לצרכנים המתאימים, או לפרסם אותם בזרם דגמי “Pub/Sub” המפרסם את האירוע ומאפשר גישה לכל הצרכנים. בכל מקרה, השירות מפרסם את האירוע, והצרכן או הצרכנים מקבלים את האירוע, ומגיבים בהתאם.
נהוג לכנות את שני השחקנים הללו מפיק (Producer) וצרכן (Consumer).
דוגמא
אקח דוגמא פשוטה יחסית שתעזור לכם להבין טוב יותר את הדברים שכתובים למעלה.
לקוח מבצע הזמנה באתר מסחר אלקטרוני, לאחר שסיים את תהליך ההזמנה (מילוי פרטים, אשראי, כתובת וכו’) יישלח event עם הכותרת “הזמנה חדשה נוצרה”, כל שאר השירותים שמאזינים לאירוע “הזמנה חדשה נוצרה” יקבלו התראה וימשיכו את החלק שלהם:
- שירות שדואג לעדכן את ההזמנות במסד הנתונים
- שירות הלקוחות שיכול ליצור את רשומת הלקוח
- שירות התשלומים שיכול לעבד את התשלום / לסלוק בפועל
- שירות שליחת מיילים שמאשר ללקוח שבוצעה הזמנה חדשה
יתרונות
בין היתר, השיטה מציעה יתרונות רבים לארגונים שמעוניינים לשפר את הגמישות של הStack הטכנולוגי שלהם.
-
Decoupling – ניתוק תלויות
שירותים כבר לא צריכים לדעת ששירותים אחרים קיימים כדי לעבוד יחד. הם צריכים להכיר רק אירועים, ואת מנהל האירועים שדואג להעביר מצד לצד את האירועים הנכונים למערכות המתאימות. ניתוק התלויות הופך את השיטה לטבעית לתקשורת של מיקרו-סרביסים. -
Immutability – לא ניתן לשינוי
לא ניתן לשנות אירועים לאחר שנוצרו, כך שניתן לשתף אותם עם שירותים מרובים ללא הסיכון ששירות אחד ישנה או יסיר מידע ששירותים אחרים צורכים. -
Persistability – התמדה
במודל המסורתי, במידה ושירות 2 מושבת, אזי הבקשה של שירות 1 לשירות 2 תזרוק שגיאה על קריאת http (למשל) שלא הייתה זמינה. עם אירועים, המתווך יכול להתמיד באירוע עד ששירות 2 יחזור לאינטרנט כדי לקבל את האירוע. זה מונע נקודת כשל בודדת ומשפר את העמידות. -
Scalability (ניתן להרחבה)
אירוע אחד מפעיל מספר פעולות אצל צרכנים שונים, ומשפר את הביצועים. ניתוק התלויות מפשט את תהליך הוספה, עדכון או הסרה של מפיקים וצרכנים של אירועים, ומאפשר התאמות מהירות כדי לעמוד בדרישות או ביקושים חדשים.
האתגרים
מטבע הדברים, כאשר יש יתרונות למשהו, ברוב המקרים יש גם חסרונות. אני בוחר לקרוא להם “אתגרים”.
-
ביצועים
על הנייר, התוספת של המתווך בין מפיקים לצרכנים עלול לגרום לירידה בביצועים, וכתוצאה מכך זמני ביצוע ארוכים יותר עבור הצרכנים.
-
עקביות
שני שירותים עשויים לעבד ולהגיב לאירוע בזמנים שונים בהתבסס על משך הזמן שלוקח לבצע את המשימות שלהם וגורמים אחרים. המשמעות היא שלא כל התגובות לאירוע יתרחשו בו זמנית, אבל בסופו של דבר כל השירותים יסיימו לעבד את האירוע. צריך לקחת את זה בחשבון בתכנון הסרביס שלכם כדי למנוע איבוד של מידע.
-
מורכבות
ניתוק התלויות מבטל את הצורך במעקב תלות ומכשולים אחרים המעכבים את ארכיטקטורת מיקרוסרביסים. עם זאת, הפשרה היא שזה הופך מאתגר יותר לעקוב אחר סטטוסי אירועים בין יישומים מרובים בהשוואה לתלות ישירה עם קשרים מוגדרים בבירור (יש לזה פתרונות – אחד מהם הוא open telemetry ).
-
איתור באגים ופתרון בעיות
זיהוי ואבחון בעיות יכולים להיות מורכבים יותר בהשוואה למערכות מסורתיות של פידבק לכל בקשה. אירועים יכולים לעורר סדרה של תגובות על פני מרכיבים שונים, מה שהופך את זה למאתגר לדבג, לעקוב אחר הflow ולזהות את שורש הבעיות.
כלים לניהול אירועים
כפי שבטח כבר הבנתם, כל הרעיון של ארכיטקטורת מונחת אירועים חייבת ברוקר / מתווך הודעות.
דוגמאות לברוקרים מוכרים ונפוצים בשוק:
- Apache Kafka
- Pulsar
- RabbitMQ
לסיכום
מקווה שנהניתם והצלחתם לקבל הבנה בסיסית על הנושא.
אם יש משהו שאתם חושבים ששווה לציין, להוסיף או סתם פידבק אתם מוזמנים להוסיף תגובה.
תודה שקראתם, ניפגש בפוסט הבא!