מערך שיעור: תקשורת בין שירותים

משך: 2.5 שעות אקדמיות (113 דקות).

מטרת השיעור: הסטודנטים יידעו לבחור sync/async נכון בין שירותים, ויכירו API Gateway ו-Service Discovery.

בסוף השיעור הסטודנטים צריכים: לסווג תרחיש תקשורת כ-sync/async, להסביר תפקיד API Gateway, ולתאר מתי Service Discovery נחוץ.

דגש קריטי: זהו שיעור-סיכום ליחידת המיקרוסרביסים כולה — קשרו במפורש לשני השיעורים הקודמים (מונוליט/Strangler Fig, Bounded Context) ולהכנה לפרויקט הצוותי.

מהלך השיעור#

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

• זהו שיעור-חיבור לכל היחידה — התחילו בסקירה קצרה: מונוליט (שיעור 1) → Bounded Context (שיעור 2) → תקשורת (שיעור 3, כאן). סטודנטים צריכים לצאת עם תמונה שלמה.
• gRPC מספיק כאזכור — לא נדרש מימוש מלא בקורס הזה, רק הבנה שהוא קיים ומתי הוא רלוונטי.
• השיעור הבא (RabbitMQ) מעמיק את ה-async שהתחיל כאן — לא נושא חדש לגמרי. השיעור שאחריו הוא הפרויקט הצוותי (Intelligence System) — הקדישו זמן לחבר בין העקרונות כאן לבין המבנה שלו (Collector/Analyzer/Alert/Dashboard מתקשרים דרך Kafka+HTTP).

מושגים#

Synchronous/Asynchronous Communication — ממתין לתשובה מול לא. gRPC — פרוטוקול sync מהיר, בינארי. API Gateway — כתובת כניסה יחידה ללקוחות. Service Discovery — איתור שירותים דינמי.

תרגיל חשיבה#

שאלת פתיחה: “בפרויקט הצוותי שמגיע, Collector (C#) אוסף נתונים ושולח ל-Analyzer (Python) לניתוח. Alert (C#) צריך להתריע מיד אם משהו חריג מתגלה. איזה חלק sync ואיזה async?”

מהלך: הובילו לתובנה שתשמש בפועל בפרויקט הקרוב: Collector→Analyzer דרך Kafka (async — הCollector לא ממתין לניתוח); אבל אם Alert צריך “לשאול” את Analyzer שאלה ספציפית ולקבל תשובה מיידית (למשל “האם הערך הזה חריג?”), זה עשוי להיות sync HTTP. אין תשובה אחת מושלמת — הדיון עצמו הוא הלמידה.

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