ארכיטקטורה מבוססת-אירועים היא תבנית עיצוב תוכנה שבה מיקרו-שירותים מגיבים לשינויים במצב, שנקראים אירועים. אירועים יכולים לשאת מצב (כמו מחיר של פריט או כתובת למשלוח) או להיות מזהים (התראה על קבלת הזמנה או על משלוח, לדוגמה). האירועים מפעילים מיקרו-שירותים שפועלים יחד כדי להשיג יעד משותף, אבל לא צריכים לדעת שום דבר אחד על השני מלבד פורמט האירוע. למרות שהם פועלים יחד, כל מיקרו-שירות יכול להחיל לוגיקה עסקית שונה ולפלוט אירועי פלט משלו.
אירוע כולל את המאפיינים הבאים:
- זהו תיעוד של משהו שקרה.
- היא מתעדת עובדה שלא ניתן לשנות או למחוק.
- היא מתרחשת בין אם שירות כלשהו מחיל לוגיקה כלשהי בעת השימוש בה ובין אם לא.
- אפשר לשמור אותו ללא הגבלת זמן, בהיקף גדול, ולצרוך אותו כמה פעמים שצריך.
במערכת מבוססת-אירועים, אירועים נוצרים על ידי מפיקי אירועים, נקלטים ומסוננים על ידי נתב אירועים (או ברוקר), ואז מועברים לצרכני האירועים (או למאגרי המידע) המתאימים. האירועים מועברים לצרכנים על סמך מינויים שמוגדרים על ידי הרשמות תואמות אחת או יותר (כשמשתמשים ב-Eventarc Advanced) או על ידי טריגרים תואמים אחד או יותר (כשמשתמשים ב-Eventarc Standard). שלושת הרכיבים האלה – מקורות אירועים, נתב אירועים וצרכני אירועים – מופרדים זה מזה ואפשר לפרוס, לעדכן ולשנות את קנה המידה שלהם באופן עצמאי:
נתב האירועים מקשר בין השירותים השונים, והוא האמצעי שדרכו נשלחות ומתקבלות הודעות. הוא מבצע תגובה לאירוע המקורי שנוצר על ידי יוצר האירוע, ושולח את התגובה הזו במורד הזרם לצרכנים המתאימים. הטיפול באירועים מתבצע באופן אסינכרוני, והתוצאות שלהם נקבעות כששירות מגיב לאירוע או מושפע ממנו, כמו בתרשים הבא של זרימת אירועים פשוטה מאוד:
מתי כדאי להשתמש בארכיטקטורות מבוססות-אירועים
כשמתכננים את המערכת, כדאי לקחת בחשבון את תרחישי השימוש הבאים.
- כדי לעקוב אחרי חריגות או שינויים בדלי אחסון, בטבלאות של מסדי נתונים, במכונות וירטואליות או במשאבים אחרים ולקבל התראות עליהם.
- כדי להפיץ אירוע יחיד לכמה צרכנים. נתב האירועים ידחוף את האירוע לכל הצרכנים המתאימים, בלי שתצטרכו לכתוב קוד בהתאמה אישית. כל שירות יכול לעבד את האירוע במקביל, אבל בצורה שונה.
- כדי לספק יכולת פעולה הדדית בין מחסניות טכנולוגיות שונות תוך שמירה על העצמאות של כל מחסנית.
- כדי לתאם בין מערכות וצוותים שפועלים ומבצעים פריסה באזורים ובחשבונות שונים. אפשר לארגן מחדש את הבעלות על מיקרו-שירותים. יש פחות תלות בין הצוותים, ואפשר להגיב מהר יותר לשינויים שעלולים להיעכב בגלל חסמים לגישה לנתונים.
היתרונות של ארכיטקטורות מבוססות-אירועים
אלה חלק מהיתרונות של בניית ארכיטקטורה מבוססת-אירועים.
צימוד חלש ושיפור הגמישות של המפתחים
מפיקי האירועים מופרדים באופן לוגי מצרכני האירועים. הניתוק הזה בין יצירת האירועים לבין השימוש בהם מאפשר לשירותים לפעול יחד, אבל גם להרחיב, לעדכן ולפרוס אותם בנפרד.
צימוד רופף מפחית את התלות ומאפשר לכם להטמיע שירותים בשפות ובמסגרות שונות. אתם יכולים להוסיף או להסיר יצרני אירועים ומקבלי אירועים בלי לשנות את הלוגיקה באף אחד מהשירותים. אין צורך לכתוב קוד בהתאמה אישית כדי לבצע סקר, לסנן ולנתב אירועים.
אירועים אסינכרוניים ועמידות
במערכת מבוססת-אירועים, האירועים נוצרים באופן אסינכרוני, ויכולים להישלח כשהם קורים בלי לחכות לתגובה. רכיבים עם צימוד רופף פירושו שאם שירות אחד נכשל, השירותים האחרים לא מושפעים. במקרה הצורך, אפשר לרשום אירועים ביומן כך שהשירות המקבל יוכל להמשיך מהנקודה שבה התרחשה השגיאה, או להפעיל מחדש אירועים קודמים.
הודעות מבוססות-דחיפה, סטרימינג של אירועים בזמן אמת ועלויות נמוכות יותר
מערכות מבוססות-אירועים מאפשרות שליחת הודעות מבוססות-דחיפה, והלקוחות יכולים לקבל עדכונים בלי לבצע כל הזמן בדיקות של שירותים מרוחקים כדי לראות אם חלו שינויים במצב. אפשר להשתמש בהודעות האלה כדי לעבד ולשנות נתונים תוך כדי תנועה, ולנתח אותם בזמן אמת. בנוסף, עם פחות סקרים, יש ירידה ב-I/O של הרשת, וירידה בעלויות.
ביקורת פשוטה ומקורות אירועים
המיקום המרכזי של נתב האירועים מפשט את תהליך הבקרה, ומאפשר לכם לקבוע מי יכול לקיים אינטראקציה עם הנתב, ולאילו משתמשים ולמשאבים יש גישה לנתונים שלכם. אתם יכולים גם להצפין את הנתונים בזמן ההעברה וגם כשהם מאוחסנים.
בנוסף, אפשר להשתמש ב-event sourcing, תבנית ארכיטקטונית שמתעדת את כל השינויים שבוצעו במצב של אפליקציה, באותו רצף שבו הם הוחלו במקור. מקורות אירועים מספקים יומן של אירועים שלא ניתן לשנות, שאפשר לשמור למטרות ביקורת, כדי ליצור מחדש מצבים היסטוריים או כתיאור קנוני להסבר של החלטה עסקית.
שיקולים אדריכליים
יכול להיות שתצטרכו לגשת לעיצוב האפליקציה שלכם בדרך חדשה אם אתם משתמשים בארכיטקטורה מבוססת-אירועים. הפתרון הזה מתאים מאוד לאפליקציות שמשתמשות במיקרו-שירותים או ברכיבים מנותקים, אבל כדאי גם לקחת בחשבון את הנקודות הבאות:
האם מקור האירועים יכול להבטיח מסירה אם צריך לעבד כל אירוע?
הוא צריך להיות מקור אירועים עמיד ומהימן.
האם האפליקציה שלך יכולה לטפל בכמה בקשות לא סנכרוניות?
ביצועי המערכת לא צריכים להסתמך על היקף גלובלי או על מסדי נתונים לא גמישים.
איך רוצים לעקוב אחרי זרימת האירועים?
ארכיטקטורה מבוססת-אירועים תומכת במעקב דינמי באמצעות שירותי ניטור, אבל לא במעקב סטטי באמצעות ניתוח קוד.
האם רוצים להשתמש בנתונים במקור האירועים כדי לבנות מחדש את המצב?
כדאי לחשוב איך לוודא שהנתונים שלכם לא משוכפלים ושהם מסודרים.
המאמרים הבאים
- כדי להבין איך אירועים מטופלים ב-Eventarc Advanced, אפשר לעיין במאמר סקירה כללית על Eventarc Advanced.
- כדי להבין איך אירועים מטופלים ב-Eventarc Standard, אפשר לעיין במאמר סקירה כללית של Eventarc Standard.