מערך שיעור: Dashboard Service

משך: 2 שעות אקדמיות (90 דקות), רובן עבודת צוותים.

מטרת השיעור: החברים האחראים על Dashboard בכל צוות יממשו Multi-Topic Consumer עם API חי.

בסוף השיעור: Dashboard Service עובד — מציג תמונת מצב מעודכנת מכל שאר השירותים.

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

מהלך השיעור#

דגשים להעברת השיעור#

• בדיקת האינטגרציה המלאה (כל 4 השירותים יחד) היא הרגע החשוב ביותר של השיעור — אל תחכו לשיעור הבא, ודאו שזה קורה כבר כאן, גם אם באופן חלקי.
• Thread+API הוא הנקודה הטכנית העדינה ביותר — ודאו שסטודנטים מבינים למה (לא רק איך) לפני שהם מעתיקים קוד.
• אם צוות מתקשה, בדקו קודם את ה-Contracts שלהם — לרוב הבעיה היא אי-התאמה בשם שדה, לא קוד ה-Dashboard עצמו.

מושגים#

Aggregated View — סיכום סטטיסטי לאורך זמן. Multi-Topic Consumer — האזנה לכמה Topics יחד. In-Memory Aggregation — צבירה חיה בזיכרון.

תרגיל חשיבה#

שאלת פתיחה: “עכשיו שכל 4 השירותים כמעט מוכנים — אם Collector היה נופל (קורס) לרגע, מה היה קורה לשאר המערכת? האם Analyzer/Alert/Dashboard גם היו נופלים?”

מהלך: הובילו לתובנה שחוזרת מיחידת המיקרוסרביסים: בזכות התקשורת האסינכרונית (Kafka) בין כל השירותים, נפילת Collector לא מפילה את האחרים — הם פשוט לא מקבלים אירועים חדשים עד שהוא חוזר, אבל ממשיכים לרוץ ולשרת בקשות קיימות. זו התוצאה המעשית של הבחירה ב-async שנעשתה בתכנון.

מה המרצה מראה בסוף: אם יש זמן, עצרו את קונטיינר ה-Collector בכוונה (docker stop) בזמן ששאר השירותים רצים — הראו ש-Dashboard/Alert ממשיכים לענות (עם הנתונים שכבר יש להם), ואז הפעילו את Collector מחדש והראו שהזרימה חוזרת לעבוד — הדגמה חיה של חוסן (Resilience) שהארכיטקטורה נותנת.