אפשר להשתמש ב-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 מיושמת על בסיס האפשרות הטובה ביותר. כשמפתחים את האפליקציה שלכם, תמיד צריך להניח שאין ערובה לזיקה לסשן (session affinity). לקוח יכול לאבד את הקשר עם מופע היעד בתרחישים הבאים:
- המידרוג האוטומטי ב-App Engine יכול להוסיף או להסיר מופעים שמשרתים את האפליקציה שלכם. יכול להיות שהאפליקציה תקצה מחדש את העומס, והמופע של היעד יעבור. כדי למזער את הסיכון הזה, חשוב לוודא שהגדרתם את המספר המינימלי של מופעים לטיפול בעומס הצפוי.
- אם בדיקות התקינות של מופע היעד נכשלות, App Engine מעביר את הסשן למופע תקין. למידע נוסף על בדיקות תקינות ועל אפשרויות ההתאמה האישית שלהן, אפשר לעיין במאמר בנושא פיצול בדיקות תקינות.
- הזיקה לסשן אובדת כשמפעילים מחדש מכונה לצורך תחזוקה או עדכוני תוכנה. מכונות ה-VM בסביבה הגמישה של App Engine מופעלות מחדש מדי שבוע.
הזיקה לסשן לא מובטחת, ולכן כדאי להשתמש בה רק כדי לנצל את היכולת של socket.io וספריות אחרות לחזור ל-HTTP long polling במקרים שבהם החיבור נשבר. אסור להשתמש בזיקה לסשן (session affinity) כדי ליצור אפליקציות עם שמירת מצב.
הפעלה והשבתה של זיקה לסשן
כברירת מחדל, זיקה לסשן (session affinity) מושבתת בכל האפליקציות של App Engine. ההגדרה 'זיקה לסשן (session affinity)' מוגדרת ברמת הגרסה של האפליקציה, ואפשר להפעיל או להשבית אותה במהלך ה-Deployment (פריסה).
כדי להפעיל את ההגדרה 'זיקה לסשן (session affinity)' בגרסת App Engine, מוסיפים את הרשומה הבאה לקובץ app.yaml:
network:
session_affinity: true
אחרי שהגרסה נפרסת עם הקובץ המעודכן app.yaml, בקשות חדשות יתחילו להציג מודעות מאותו מופע כל עוד המופע הזה זמין.
כדי להשבית את הזיקה לסשן (session affinity), מסירים את הרשומה מקובץ app.yaml או מגדירים את הערך כ-false:
network:
session_affinity: false