RPC, Messaging, Streaming - שלוש פילוסופיות תקשורת

אחרי שהבנו ש-Consistency ו-Availability הן בחירות יומיומיות, אפשר להרחיב את המבט החוצה:

איך בכלל בוחרים איך מערכות מדברות זו עם זו?

כאן מופיעות שלוש גישות נפוצות: RPC, Messaging, ו-Streaming.

לרוב מציגים אותן ככלים שונים. בפועל - אלו שלוש פילוסופיות שונות לגמרי של תקשורת.

RPC - לדבר כאילו הכול מקומי

RPC (Remote Procedure Call) בנוי על רעיון פשוט: אני קוראת לפונקציה - רק שהיא רצה במקום אחר.

מבחינת הקוד:

• יש קריאה
• יש תשובה
• ויש ציפייה לסנכרון

זו תקשורת שנראית נקייה, ישירה ונוחה.

אבל היא נשענת על הנחה כבדה: שהצד השני זמין עכשיו.

המחיר של RPC

RPC יוצר coupling חזק:

• השולח מחכה
• המקבל חייב להגיב
• וכל עיכוב הופך לבעיה מיידית

Latency הופך לחלק מה-control flow. Timeout הופך ללוגיקה. וכשל קטן בצד אחד - מורגש מיד בצד השני.

RPC מתאים כש:

• חשוב לקבל תשובה מיידית
• והקשר בין הצדדים הדוק

הוא מסוכן כש:

• יש עומס
• יש אי-יציבות
• או כשצריך סקייל רחב

Messaging - לשלוח ולשחרר

Messaging מבוסס על רעיון אחר: לא מדברים - שולחים הודעה.

השולח:

• שולח
• וממשיך הלאה

המקבל:

• מטפל כשיכול
• בקצב שלו

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

המחיר של Messaging

Messaging קונה:

• עמידות
• גמישות
• ויכולת ספיגה

אבל הוא דורש:

• תכנון ל-Latency לא ידוע
• התמודדות עם כפילויות
• וחשיבה על סדר ועקביות

אין “תשובה מיידית”. יש זרימה של אירועים.

Messaging מתאים כש:

• לא חייבים תגובה מיידית
• חשוב לנתק בין רכיבים
• ועומס הוא חלק מהשגרה

Streaming - לחשוב בזרימה, לא בפעולות

Streaming משנה את נקודת המבט לגמרי.

לא: “שלחתי בקשה” ולא: “שלחתי הודעה”

אלא: יש זרם מתמשך של אירועים.

המערכת אינה מגיבה לפעולה בודדת - היא מאזינה לזרימה.

המחיר והכוח של Streaming

Streaming מצטיין ב:

• כמויות גדולות של נתונים
• עיבוד רציף
• וניתוח לאורך זמן

אבל הוא דורש:

• חשיבה אחרת לגמרי
• ניהול State לאורך זרם
• והתמודדות עם עיבוד לא לפי סדר

זה לא “יותר Messaging”. זו פילוסופיה אחרת.

Synchronous מול Asynchronous - לא עניין טכני

RPC, Messaging ו-Streaming נבדלים קודם כול בשאלה אחת:

האם השולח מחכה - או משחרר?

הבחירה הזו משפיעה על:

• Latency
• עומס
• אמינות
• ואופן החשיבה של הצוות

זו לא החלטה של ספרייה. זו החלטה מערכתית.

Coupling לעומת Decoupling

RPC יוצר coupling חזק: שני הצדדים תלויים זה בזה בזמן אמת.

Messaging ו-Streaming מאפשרים decoupling: כל צד מתקדם בקצב שלו.

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

המשל

אפשר לחשוב על:

• RPC כטלפון - שני הצדדים חייבים להיות זמינים
• Messaging כדואר - שולחים וממשיכים
• Streaming כרדיו - מאזינים לזרם מתמשך

שלוש צורות תקשורת, שלוש ציפיות שונות.

השורה התחתונה

הבחירה בין RPC, Messaging ו-Streaming אינה טכנולוגית.

היא מהותית:

• איך המערכת חווה זמן
• איך היא מגיבה לכשל
• ואיך היא מתמודדת עם עומס

בחירה שגויה כאן לא תיפתר באופטימיזציה.

מבט קדימה

אחרי שבחרנו איך מערכות מדברות, נשארת שאלה עמוקה לא פחות:

איפה נמצא ה-State?

בפוסט הבא נבחן למה “Stateless” אינו אומר שאין State - אלא החלטה מודעת איפה הוא חי, ואיזה מחיר משלמים על כל בחירה.