בניית אפליקציה ריאקטיבית המופעלת באירועים עם תור אירועים נפלאים

אדריכלות מונעת אירועים מקלה על מערכות להגיב לאירועים מהחיים האמיתיים, כמו כאשר פרופיל המשתמש מתעדכן. פוסט זה מציג בניית אפליקציות תגובתיות מונעות אירועים שמטפלות באובדן נתונים על ידי שילוב של Spring WebFlux, Apache Kafka ותור מכתבים מתים. כאשר משתמשים בהם יחד, הם מספקים את המסגרת ליצירת מערכות עמידות בפני תקלות, גמישות וביצוע גבוה, שמסוגלות להתמודד עם כמויות עצומות של נתונים ביעילות.

תכונות בשימוש במאמר זה

  • Spring Webflux: הוא מספק פרדיגמה תגובתית התלויה בלחץ אחורי שאינו חוסם לעיבוד סימולטני של אירועים.
  • Apache Kafka: מפיקים וצרכנים תגובתיים של Kafka מסייעים בבניית צינורות עיבוד ייחודיים וגמישים.
  • זרמים תגובתיים: הם אינם חוסמים את ביצוע הזרמים של מפיקים וצרכנים של Kafka.
  • תור מכתבים מתים (DLQ): DLQ מאחסן הודעות באופן זמני שלא ניתן היה לעבד מסיבות שונות. הודעות DLQ יכולות לשמש מאוחר יותר לעיבוד מחדש של הודעות כדי למנוע אובדן נתונים ולגרום לעיבוד אירועים להיות עמיד.

מפיק Kafka תגובתי

הייצור של Reactive Kafka משדר הודעות במקביל ואינו חוסם תהליכים אחרים בזמן פרסום. זה מועיל כאשר יש צורך בעיבוד נתונים גדולים. זה משלב טוב עם Spring WebFlux ומתמודד עם לחץ אחורי בארכיטקטורות מיקרושירות. האינטגרציה הזו עוזרת לעיבוד לא רק של הודעות גדולות אלא גם לניהול משאבי ענן בצורה יעילה.

המשדר של Reactive Kafka שנתקף למעלה ניתן למציאה על GitHub.

צרכן של Reactive Kafka

צרכן של Reactive Kafka מושך הודעות מ-Kafka מבלי לחסום ושומר על תפוקה גבוהה. הוא תומך גם בטיפול בלחץ אחורי ומשתלב בצורה מושלמת עם WebFlux לעיבוד נתונים בזמן אמת. צינור הצרכן הריאקטיבי ניהל משאבים בצורה יעילה ומתאים ביותר ליישומים שמוצבים בענן.

הצרכן של Reactive Kafka שנתקף למעלה ניתן למציאה על GitHub.

תור ההודעות המתים (DLQ)

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

יתרונות של אינטגרציה עם התור להודעות שנכשלו

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

הודעות שנכשלו יכולות להיות מועברות לתוך התור המתאים מקוד היוצר כפי שמוצג להלן:
קוד יוצר

נדרשת טפל בתור ההודעות שנכשלו להיות נוצר בצרכן הרקטיבי כפי שמוצג להלן:

מסקנה

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

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

הקוד המפנה למעלה ניתן למצוא ב-GitHub producer וב-GitHub consumer.

פרטים נוספים לגבי המפיק והצרכן הריאקטיביים ניתן למצוא ב-ReactiveEventDriven. Spring Apache Kafka מסמכים מידע נוסף לגבי DLQ.

Source:
https://dzone.com/articles/reactive-event-driven-app-with-dead-letter-queue