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