אפשר להשתמש ב-WebSockets כדי ליצור חיבור קבוע מלקוח (כמו מכשיר נייד או מחשב) למופע של App Engine. החיבור הפתוח מאפשר חילופי נתונים דו-כיווניים בין הלקוח לשרת בכל שלב, וכך מקטין את זמן האחזור ומשפר את השימוש במשאבים.
WebSockets
פרוטוקול WebSockets, שמוגדר ב-RFC 6455, מספק ערוץ תקשורת דו-כיווני בין לקוח לשרת. הערוץ מופעל מבקשת HTTP(S) עם כותרת 'שדרוג'.
תרחישי שימוש נפוצים ב-WebSockets:
- עדכונים בזמן אמת על אירועים, כמו פידים של רשתות חברתיות, תוצאות של משחקי ספורט, חדשות או מחירי מניות
- התראות למשתמשים, כמו עדכוני תוכנה או תוכן
- אפליקציות לצ'אט
- כלים לעריכה משותפת
- משחקים מרובי משתתפים
הפרוטוקול WebSockets תמיד זמין לאפליקציה שלכם ללא צורך בהגדרה נוספת. אחרי שנוצר חיבור WebSockets, הוא יפסיק לפעול אחרי שעה. החיוב על השימוש ב-WebSocket הוא לפי השימוש בחיבור עד לזמן קצוב לתפוגה או עד לסיום השימוש בשקע.
הפעלת אפליקציה לדוגמה עם WebSockets
בדוגמאות הקוד במסמך הזה מוסבר איך להריץ אפליקציה לדוגמה עם Websockets.
כדי להשתמש באפליקציה לדוגמה במדריך הזה לכל גרסה נתמכת של Python, צריך לציין את גרסת זמן הריצה ואת מערכת ההפעלה בקובץ app.yaml.
דרישות מוקדמות והגדרה
כדי להגדיר את הסביבה והפרויקט ולהבין את מבנה האפליקציות, פועלים לפי ההוראות שבמאמר הגדרת סביבת הפיתוח .
שכפול האפליקציה לדוגמה
מעתיקים את האפליקציות לדוגמה למחשב המקומי ועוברים אל הספרייה websockets:
git clone https://github.com/GoogleCloudPlatform/python-docs-samples
cd python-docs-samples/appengine/flexible/websockets/
הרצת הדוגמה באופן מקומי
כדי להריץ באופן מקומי, צריך להשתמש ב-Gunicorn עם העובד flask_socket:
$ gunicorn -b 127.0.0.1:8080 -k flask_sockets.worker main:app
פריסה והרצה של הדוגמה ב-App Engine
כדי לפרוס את האפליקציה בסביבה הגמישה של App Engine, מריצים את הפקודה הבאה מהספרייה שבה נמצא הקובץ app.yaml:
gcloud app deploy
אחר כך אפשר להפנות את הדפדפן אל
https://PROJECT_ID.REGION_ID.r.appspot.com
זיקה לסשן (session affinity)
לא כל הלקוחות תומכים ב-WebSockets. כדי לעקוף את הבעיה הזו, הרבה אפליקציות משתמשות בספריות כמו socket.io, שחוזרות לשימוש ב-HTTP long polling עם לקוחות שלא תומכים ב-WebSockets.
בדרך כלל, App Engine מחלק את הבקשות באופן שווה בין המופעים הזמינים. עם זאת, כשמשתמשים ב-HTTP long polling, כמה בקשות רצופות ממשתמש מסוים צריכות להגיע לאותו מופע.
כדי לאפשר ל-App Engine לשלוח בקשות מאותו משתמש לאותו מופע, אפשר להפעיל את התכונה 'זיקה לסשן (session affinity)'. לאחר מכן, App Engine מזהה אילו בקשות נשלחות מאותם משתמשים על ידי בדיקת קובץ Cookie, ומנתב את הבקשות האלה לאותו מופע.
הזיקה לסשן ב-App Engine מיושמת על בסיס המאמץ הטוב ביותר. כשמפתחים אפליקציה, תמיד צריך להניח שהזיקה לסשן לא מובטחת. לקוח יכול לאבד את הזיקה למופע היעד בתרחישים הבאים:
- התכונה לשינוי גודל אוטומטי ב-App Engine יכולה להוסיף או להסיר מופעים שמשרתים את האפליקציה שלכם. יכול להיות שהאפליקציה תקצה מחדש את העומס, והמופע של היעד יעבור. כדי לצמצם את הסיכון הזה, חשוב לוודא שהגדרתם את המספר המינימלי של מופעים לטיפול בעומס הצפוי.
- אם בדיקות התקינות של מכונת היעד נכשלות, App Engine מעביר את הסשן למכונה תקינה. למידע נוסף על בדיקות תקינות ועל אפשרויות ההתאמה האישית שלהן, אפשר לעיין במאמר בנושא פיצול בדיקות תקינות.
- זיקה לסשן (session affinity) אובדת כשמפעילים מחדש מכונה וירטואלית לצורך תחזוקה או עדכוני תוכנה. מכונות וירטואליות בסביבה גמישה של App Engine מופעלות מחדש מדי שבוע.
מכיוון שאין ערובה לזיקה לסשן, כדאי להשתמש בה רק כדי לנצל את היכולת של socket.io וספריות אחרות לחזור לשימוש ב-HTTP long polling במקרים שבהם החיבור נקטע. אסור להשתמש בזיקה לסשן כדי ליצור אפליקציות עם מצב.
הפעלה והשבתה של זיקה לסשן
כברירת מחדל, זיקה לסשן (session affinity) מושבתת בכל האפליקציות של App Engine. זיקה לסשן (session affinity) נקבעת ברמת הגרסה של האפליקציה, ואפשר להפעיל או להשבית אותה במהלך הפריסה.
כדי להפעיל את ההגדרה 'זיקה לסשן (session affinity)' בגרסת App Engine, מוסיפים את הרשומה הבאה לקובץ app.yaml:
network:
session_affinity: true
אחרי שהגרסה נפרסת עם הקובץ המעודכן app.yaml, בקשות חדשות יתחילו להגיע מאותו מופע כל עוד המופע הזה זמין.
כדי להשבית את הזיקה לסשן, מסירים את הרשומה מקובץ app.yaml או מגדירים את הערך כ-false:
network:
session_affinity: false