שימוש ב-WebSockets

בדף הזה מפורטות הנחיות ושיטות מומלצות להפעלת WebSockets או שירותי סטרימינג אחרים ב-Cloud Run, ולכתיבת לקוחות לשירותים כאלה.

יש תמיכה באפליקציות WebSockets ב-Cloud Run, ולא נדרשת הגדרה נוספת. עם זאת, סטרימינג של WebSockets הוא בקשות HTTP, שעדיין כפופות לפסק הזמן של הבקשה שהוגדר לשירות Cloud Run, ולכן צריך לבצע את הפעולות הבאות:

  • הגדל את פרק הזמן הקצוב לתפוגה של הבקשה למשך הזמן המרבי שברצונך לשמור על זרם WebSockets פתוח, לדוגמה 60 דקות.
  • חשוב לוודא שהלקוחות יוכלו להתחבר מחדש.
  • שקול להשתמש בזיקה לסשן כדי שלקוחות יתחברו מחדש כמה שיותר לאותו מופע.
  • לא מפעילים את האפשרות HTTP/2 end-to-end.

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

שימו לב: יש גם תמיכה ב-WebSockets ב-Cloud Run אם אתם משתמשים ב-Cloud Load Balancing.

פריסת שירות לדוגמה של WebSockets

השתמש ב-Cloud Shell כדי לפרוס במהירות שירות לוח לבן לדוגמה המשתמש ב-WebSockets עם Cloud Run: פריסת דוגמה

לחלופין, אם רוצים לפרוס את שירות הלוח הווירטואלי לדוגמה באופן ידני:

  1. משכפלים את מאגר Socket.IO באופן מקומי באמצעות כלי שורת הפקודה git:

    git clone https://github.com/socketio/socket.io.git

  2. נווט לתוך ספריית הדוגמה:

    cd socket.io/examples/whiteboard/

  3. פורסים שירות חדש ב-Cloud Run על ידי בניית השירות מקוד המקור באמצעות Google Cloud CLI:

    gcloud run deploy whiteboard --allow-unauthenticated --source=.

  4. אחרי פריסת השירות, פותחים שתי כרטיסיות נפרדות בדפדפן ועוברים לכתובת ה-URL של השירות. כל מה שמציירים בכרטיסייה אחת מועבר לכרטיסייה השנייה (ולהפך), כי הלקוחות מחוברים לאותו מופע באמצעות WebSockets.

מדריך מלא לדוגמה של צ'אט ב-WebSockets

אם אתם רוצים לקבל הסבר מפורט על הקוד, תוכלו לעיין בדוגמאות קוד נוספות בנושא יצירת שירות צ'אט ב-WebSocket עבור Cloud Run.

שיטות מומלצות

החלק הכי מסובך ביצירת שירותי WebSockets ב-Cloud Run הוא סנכרון הנתונים בין כמה מכונות של Cloud Run. הדבר הזה מסובך בגלל ההתאמה האוטומטית לעומס (auto-scaling) והאופי בלי שמירת מצב של המכונות, ובגלל המגבלות על בו-זמניות (concurrency) ועל זמן קצוב לתפוגה של בקשות.

טיפול בפסק זמן של בקשות ובחיבורים מחדש של לקוחות

בקשות WebSockets נחשבות ב-Cloud Run לבקשות HTTP ארוכות טווח. הם כפופים לפסק זמן של בקשות (נכון לעכשיו, עד 60 דקות וברירת המחדל היא 5 דקות) גם אם שרת האפליקציות שלכם לא אוכף פסק זמן.

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

לכן, לקוחות WebSockets שמתחברים ל-Cloud Run צריכים לטפל בחיבור מחדש לשרת אם פג הזמן הקצוב לתגובה לבקשה או אם השרת מתנתק. אפשר לעשות את זה בלקוחות מבוססי-דפדפן באמצעות ספריות כמו reconnecting-websocket או באמצעות טיפול באירועי 'ניתוק' אם משתמשים בספריית SocketIO.

חיוב על שימוש ב-WebSockets

מופע של Cloud Run שיש לוכֹּל חיבור WebSocket פתוח נחשב פעיל, לכן המעבד מוקצה והשירות מופעל.מחויב כחיוב מבוסס מופע.

הגדלת מספר הפעולות שמתבצעות בו-זמנית

שירותי WebSockets מתוכננים בדרך כלל לטפל בהרבה חיבורים בו-זמנית. מכיוון ש-Cloud Run תומך בחיבורים בו-זמניים (עד 1,000 לכל מכולה), גוגל ממליצה להגדיל את הגדרת המקבילות המקסימלית עבור המכולה שלך לערך גבוה יותר מברירת המחדל אם השירות שלך מסוגל להתמודד עם העומס עם המשאבים הנתונים.

מידע על סשנים קבועים (זיקה לסשן)

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

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

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

סנכרון נתונים בין מופעים

כדי לוודא שהלקוחות שמתחברים לשירות Cloud Run מקבלים את אותם נתונים מהחיבור ל-WebSockets, צריך לסנכרן את הנתונים.

לדוגמה, נניח שאתם בונים שירות של חדר צ'אט באמצעות WebSockets והגדרתם את המקבילות המקסימלית ל-1,000. אם יותר מ-1,000 משתמשים מתחברים לשירות זה בו זמנית, הם יקבלו שירות ממופעים שונים, ולכן הם לא יוכלו לראות את אותן הודעות בחדר הצ'אט.

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

אם משתמשים במסד נתונים חיצוני כמו Cloud SQL, אפשר לשלוח הודעות למסד הנתונים ולבצע שאילתות ממסד הנתונים באופן תקופתי. עם זאת, שימו לב שלמופעי Cloud Run אין CPU כאשר המכולה אינה מטפלת בבקשות כלשהן. אם השירות שלכם מטפל בעיקר בבקשות WebSockets, המערכת תקצה לכם ליבות CPU כל עוד יש לפחות לקוח אחד שמחובר אליו.

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

‫Google ממליצה להשתמש במערכות חיצוניות של תורים להודעות, כמו Redis Pub/Sub‏ (Memorystore) או עדכונים בזמן אמת ב-Firestore, שיכולות לספק עדכונים לכל המופעים דרך חיבורים שהופעלו על ידי מופע המאגר.

שימוש ב-Redis Pub/Sub

ארכיטקטורה של שירות חדר צ'אט ב-WebSockets

אפשר להשתמש במנגנון Redis Pub/Sub על ידי יצירת מכונת Redis מ-Memorystore. אם אתם משתמשים בספריית Socket.IO ל-WebSockets, אתם יכולים להשתמש במתאם redis שלה.

באדריכלות שמבוססת על Redis, כל מופע של Cloud Run יוצר חיבור לטווח ארוך לערוץ Redis שמכיל את ההודעות שהתקבלו (באמצעות הפקודה SUBSCRIBE). אחרי שמופעים של מאגרי תגים מקבלים הודעה חדשה בערוץ, הם יכולים לשלוח אותה ללקוחות שלהם באמצעות WebSockets בזמן אמת.

באופן דומה, כשלקוח שולח הודעה באמצעות WebSockets, המופע שמקבל את ההודעה מפרסם את ההודעה בערוץ Redis (באמצעות הפקודה PUBLISH), ומופעים אחרים שמנויים לערוץ הזה יקבלו את ההודעה.

אם אתם רוצים לקבל הסבר מפורט על הקוד, תוכלו לעיין בדוגמאות קוד נוספות בנושא יצירת שירות צ'אט ב-WebSocket עבור Cloud Run.