המדריך הזה מיועד למשתמשים בתכונה Object change notifications (התראות על שינוי באובייקט) שהוצאה משימוש ב-Cloud Storage. התראות Pub/Sub ל-Cloud Storage הוא הכלי המומלץ ליצירת התראות שעוקבות אחרי שינויים באובייקטים בקטגוריות של Cloud Storage. התראות Pub/Sub מציעות מהירות, גמישות, הגדרה ועלות-תועלת משופרות. במדריך הזה מוסברים ההבדלים בין התראות על שינויים באובייקטים לבין התראות Pub/Sub ב-Cloud Storage, ומוצגים שלבי המעבר מהתראות על שינויים באובייקטים להתראות Pub/Sub.
סקירה כללית של התראות על שינוי אובייקטים
התראות על שינוי אובייקטים הן מנגנון מדור קודם ב-Cloud Storage להודעה לאפליקציה על שינויים באובייקטים בתוך קטגוריה. כשמגדירים התראות על שינוי אובייקטים, Cloud Storage שולח בקשות HTTP POST (ווּבְּהוּקים) לכתובת URL של אפליקציה שצוינה בכל פעם שאובייקט נוסף, מתעדכן או נמחק. כדי להגדיר התראות על שינויים באובייקטים, שולחים בקשת watchAll ל-Cloud Storage באמצעות API בפורמט JSON, ספריות לקוח או הפקודה watchbucket של gsutil notification. אין מנגנון pull, ולכן כדי לקבל את הודעות ה-webhook, צריך שיהיה לכם שם דומיין עם גישה ציבורית שמגובה על ידי שרת HTTP. מומלץ להשתמש בהתראות Pub/Sub של Cloud Storage בהטמעות חדשות, כי הן אמינות, ניתנות להרחבה וגמישות.
מידע מפורט יותר זמין במאמר בנושא הודעות על שינויים באובייקטים.
סקירה כללית של התראות Pub/Sub
התראות Pub/Sub ל-Cloud Storage מספקות דרך מודרנית, ניתנת להרחבה ואמינה להפעלת פעולות בתגובה לשינויים בקטגוריות של Cloud Storage. הפעולה מתבצעת על ידי שליחת פרטי האירוע לנושא Pub/Sub. ב-Pub/Sub אפשר לשלוח הודעות באמצעות push כבקשות HTTP POST ל-webhook. כשיוצרים, מעדכנים או מוחקים אובייקטים, Cloud Storage מפרסם הודעות שמכילות מטא-נתונים של אובייקטים בנושא Pub/Sub שצוין. לאחר מכן, מנויים שונים יכולים לצרוך את ההודעות, כמו פונקציות Cloud Run, צינורות נתונים או מיקרו-שירותים. כך מתאפשרות ארכיטקטורות גמישות שמבוססות על אירועים, עם תכונות של לפחות מסירה אחת וטיפול חזק בשגיאות.
מידע מפורט יותר זמין במאמר התראות Pub/Sub ל-Cloud Storage.
השוואה בין התראות על שינוי אובייקט לבין התראות Pub/Sub
בטבלה הבאה מוצגת השוואה בין התכונות של התראות על שינוי אובייקט לבין התכונות של התראות Pub/Sub:
| תכונה | התראות על שינוי אובייקטים | התראות Pub/Sub |
|---|---|---|
| מטרה | ההתראות נשלחות ישירות לאפליקציה באמצעות בקשות HTTP POST (webhooks) כשמתבצעים שינויים באובייקטים בקטגוריה. | שליחת מידע על שינויים באובייקטים בקטגוריות של Cloud Storage לנושא Pub/Sub. |
| מנגנון המסירה | שליחת HTTP POST (webhook) ישירות לכתובת URL ספציפית של אפליקציה. | אחרי שמפרסמים הודעות בנושא Pub/Sub, מנויים שונים יכולים לצרוך אותן, כמו פונקציות Cloud Run, אפליקציות אחרות וצינורות נתונים. |
| אמינות | אנחנו מנסים לספק את זה מהר במידת האפשר – ניתנת עדיפות להעברה בזמן אבל היא לא מובטחת. יכול להיות שההתראות יתעכבו ללא הגבלת זמן. | ההודעות נמסרות לפחות פעם אחת, כלומר יכול להיות שהן יימסרו כמה פעמים, אבל הן לא יאבדו. מערכת Pub/Sub מטפלת בשימור הודעות ובניסיונות חוזרים. |
| מדרגיות | פחות ניתן להרחבה, כי הוא מסתמך על ווּבּהוּקים ישירים שהאפליקציה צריכה לטפל בהם. | מערכת ניהול אירועים שניתן להרחיב אותה בקלות ומיועדת לעיבוד אירועים בקנה מידה גדול. |
| גמישות | מוגבל לשילוב ישיר של תגובה לפעולה מאתר אחר (webhook). | גמישות גבוהה. הודעות Pub/Sub יכולות להפעיל פונקציות של Cloud Run, להזין צינורות נתונים (Dataflow) ולהיקרא על ידי מיקרו-שירותים אחרים. |
| סינון | ללא | אפשרויות סינון חזקות זמינות ברמת המינוי ל-Pub/Sub, ומאפשרות למנויים לקבל רק הודעות שעומדות בקריטריונים ספציפיים. |
| אבטחה | נדרשת גישה ציבורית (HTTPS) לנקודת הקצה של האפליקציה. | ב-Pub/Sub יש IAM לניהול בקרת גישה פרטנית לנושאים ולמינויים. Pub/Sub עוזר למסור הודעות בצורה מאובטחת, בין אם אתם שולפים התראות ישירות או שולחים אותן לנקודת קצה ציבורית. |
| מורכבות | יכול להיות שיהיה פשוט יותר להגדיר אותו לתרחישי שימוש בסיסיים, אבל ניהול של מסירה מהימנה והתאמה של קנה המידה יכולים להיות מורכבים. | הפתרון הזה דורש הבנה של מושגי Pub/Sub (נושאים, מינויים), אבל הוא מציע פתרון חזק וקל יותר לניהול עבור ארכיטקטורות מבוססות-אירועים. |
| סטטוס ההוצאה משימוש | הוצאה משימוש, מומלץ להשתמש בהתראות Pub/Sub להטמעות חדשות. | פעיל/ה. זוהי השיטה העיקרית והיא נמצאת בפיתוח פעיל עבור התראות Cloud Storage. |
| שימוש מומלץ | לא מומלץ לפרויקטים חדשים. בעיקר לאינטגרציות מדור קודם פשוטות יותר שאי אפשר להעביר. | מומלץ מאוד ליצירת ארכיטקטורות חזקות, ניתנות להתאמה ומבוססות-אירועים שמגיבות לשינויים ב-Cloud Storage. |
למה כדאי לעבור להתראות Pub/Sub?
המעבר מהתראות על שינוי באובייקט מדור קודם להתראות Pub/Sub ל-Cloud Storage הוא שלב חשוב בניהול אירועים חזק. מומלץ להשתמש ב-Pub/Sub לארכיטקטורות מבוססות-אירועים בתוך Google Cloud, כי הוא מציע יתרונות טכניים ותפעוליים משמעותיים בהשוואה להתראות על שינוי אובייקט.
אלה היתרונות של מעבר להתראות Pub/Sub:
- מסירה מהימנה: Pub/Sub מספק כל הודעה שפורסמה לפחות פעם אחת לכל מינוי, ומוודא שהאירועים מגיעים לצרכנים. העברה אמינה מצמצמת את אובדן הנתונים ומשפרת את המהימנות של תהליכי העבודה בהשוואה למודל העברה פחות חזק של הודעות על שינוי אובייקט.
- יכולת הרחבה: הודעות Pub/Sub מיועדות לתפוקה גבוהה, ויכולות לטפל בכמויות גדולות של אירועים באופן אוטומטי. באמצעות התראות Pub/Sub, אתם יכולים למנוע צווארי בקבוק בביצועים שעלולים להתרחש כשאתם משתמשים בהתראות על שינוי אובייקטים, ככל שהנתונים או התדירות של האירועים גדלים.
- שילוב עם Google Cloud שירותים: Pub/Sub משתלב בצורה חלקה עם כמה Google Cloud שירותים, ומאפשר גמישות בבניית תהליכי עבודה אוטומטיים באמצעות פונקציות Cloud Run, Cloud Run, Dataflow ושיפור יכולת הצפייה באמצעות Cloud Logging ו-Cloud Monitoring.
- שליטה מדויקת: באמצעות Pub/Sub אפשר לסנן הודעות ברמת המינוי. כך הצרכנים מקבלים רק אירועים רלוונטיים, וזה מצמצם את העיבוד המיותר ואת נפח התנועה ברשת.
- תמיכה בפלטפורמה: התראות Pub/Sub הוא שירות העברת ההודעות הנתמך. המיגרציה מאפשרת לכם להשתמש בטכנולוגיה שמקבלת שיפורים שוטפים, עדכוני אבטחה ותיעוד מקיף, בניגוד להתראות על שינוי אובייקטים שהוצאו משימוש.
שלבים בהעברה
גם התראות על שינוי באובייקט וגם התראות Pub/Sub ל-Cloud Storage יכולות לשלוח מדי פעם הודעות כפולות. לכן, הקוד שמשתמש בנתונים צריך להיות מתוכנן כך שיטפל בכפילויות של הודעות בצורה בטוחה.
כדי להעביר את ההתראות מהתראות על שינוי אובייקטים להתראות Pub/Sub, פועלים לפי השלבים הבאים:
מתחילים להשתמש בהתראות Pub/Sub ל-Cloud Storage בנוסף להגדרות הקיימות של התראות על שינויים באובייקטים. מידע על הגדרת התראות Pub/Sub זמין במאמר הגדרת התראות Pub/Sub ל-Cloud Storage.
בודקים ומוודאים שתהליך העבודה של עיבוד ההתראות ב-Pub/Sub באפליקציה פועל בצורה תקינה. מידע על מעקב אחרי מינוי ל-Pub/Sub זמין במאמר מעקב אחרי מינויים ב-Pub/Sub.
הפסקת העיבוד של הודעות שהתקבלו מערוץ של התראות על שינוי אובייקט. כדי לעצור ערוץ התראות, שולחים בקשת stop.
שיקולים לגבי מינוי לדחיפה ב-Pub/Sub
מינויים מסוג pull ב-Pub/Sub מציעים גמישות ושליטה משופרות, אבל מינויים מסוג push ב-Pub/Sub דומים מאוד להודעות של התראה על שינוי אובייקט. כתוצאה מכך, המינויים לקבלת התראות בדחיפה הופכים לדרך מהירה יותר להעברה של משתמשים קיימים של התראות על שינוי אובייקטים. השוואה מפורטת בין מינויי Push ו-Pull זמינה במאמר בחירת סוג מינוי.
אם אתם מתכננים להשתמש במינוי לקבלת עדכונים בשיטת Push וגם מתכננים להשתמש מחדש בקוד קיים לטיפול בהתראות, תצטרכו להביא בחשבון את ההבדלים בין התראות על שינויים באובייקט לבין פורמטים של בקשות Push של התראות Pub/Sub ופרשנויות של קודי תגובה. ההבדלים מתוארים בסעיפים הבאים.
פורמט בקשת הדחיפה
בקטע הזה מתוארים ההבדלים בפורמט של בקשות Push בין התראות על שינוי אובייקט לבין התראות Pub/Sub.
התראות על שינוי אובייקטים: התראה על שינוי אובייקט מועברת כבקשת HTTP POST לכתובת ה-URL של האפליקציה, בפורמט הבא:
POST /ApplicationUrlPath Accept: * / * Content-Length: 1097 Content-Type: application/json; charset="utf-8" Host: ApplicationUrlHost X-Goog-Channel-Id: ChannelId X-Goog-Channel-Token: ClientToken X-Goog-Resource-Id: ResourceId X-Goog-Resource-State: ResourceState X-Goog-Resource-Uri: https://storage.googleapis.com/storage/v1/b/BucketName/o?alt=json { "kind": "storage#object", "id": "BucketName/ObjectName", "selfLink": "https://www.googleapis.com/storage/v1/b/BucketName/o/ObjectName", "name": "ObjectName", "bucket": "BucketName", "generation": "1367014943964000", "metageneration": "1", "contentType": "application/octet-stream", "updated": "2013-04-26T22:22:23.832Z", "size": "10", "md5Hash": "xHZY0QLVuYng2gnOQD90Yw==", "mediaLink": "https://content-storage.googleapis.com/storage/v1/b/BucketName/o/ObjectName?generation=1367014943964000&alt=media", "owner": { "entity": "user-jeffersonloveshiking@gmail.com" }, "crc32c": "C7+82w==", "etag": "COD2jMGv6bYCEAE=" }התראות Pub/Sub: התראת Pub/Sub, כשהיא מוגדרת למסירה בדחיפה, מועברת כבקשת HTTP POST. השדה
dataמכיל את המטען הייעודי (payload) של אירוע Cloud Storage בקידוד base64. כשמפענחים את שדה הנתונים, הוא זהה לגוף ההודעה של ההתראות על שינוי אובייקט.POST /YourSpecifiedURL Accept: * / * Content-Length: 1097 Content-Type: application/json; charset="utf-8" Host: ApplicationUrlHost { "deliveryAttempt": 5, "message": {"attributes": {"notificationConfig":"projects/_/buckets/foo/notificationConfigs/3", "eventType": "OBJECT_FINALIZE", "payloadFormat": "JSON_API_V1", "bucketId": "foo", "objectId": "bar", "objectGeneration": 123456, "eventTime": "2021-01-15T01:30:15.01Z" }, "data": "ewogImtpbm", "messageId": "2070443601311540", "message_id": "2070443601311540", "orderingKey": "key", "publishTime": "2021-02-26T19:13:55.749Z", "publish_time": "2021-02-26T19:13:55.749Z" }, "subscription": "projects/myproject/subscriptions/mysubscription" }
קוד תגובה
בטבלה הבאה מפורטים ההבדלים בפירוש קודי התגובה בין התראות על שינוי אובייקט לבין התראות Pub/Sub:
| תכונה | קוד תגובה | פירוש | פעולה |
|---|---|---|---|
| התראות על שינוי אובייקטים | |||
102, 200, 201, 202, 204
|
הפעולה הצליחה | ההודעה עובדה | |
500, 502, 503, 504
|
העיבוד נכשל | אפשר לנסות שוב מאוחר יותר | |
| פסק זמן, חיבורים שנכשלו, אין תגובה | העיבוד נכשל | אפשר לנסות שוב מאוחר יותר | |
כל קוד HTTP אחר. לדוגמה, 404
|
כשל קבוע | לא לנסות לשלוח שוב את ההודעה | |
| התראות Pub/Sub | |||
102, 200, 201, 202, 204
|
הפעולה הצליחה | ההודעה אושרה | |
| כל קודי התגובה האחרים, פסק הזמן וכשלי החיבור | כישלון | אפשר לנסות שוב מאוחר יותר |
המאמרים הבאים
- הגדרת התראות Pub/Sub ל-Cloud Storage
- מידע נוסף על Pub/Sub
- הרשמה למינוי של מאגר כדי לקבל התראות שנשלחות ל-Pub/Sub.