סקירה כללית של שירות Pub/Sub

‫Pub/Sub הוא שירות פרסום/הרשמה (Pub/Sub), שבו יש הפרדה בין מי ששולח הודעות לבין מי שמקבל הודעות. יש כמה מושגי מפתח בשירות Pub/Sub, והם מוסברים באיור הבא.

איור שמציג רכיבים שונים של שירות Pub/Sub ואת אופן החיבור ביניהם.
איור 1: שני לקוחות של פרסום הודעות שולחים שתי הודעות שונות לנושא Pub/Sub משותף.

הרכיבים של שירות Pub/Sub:

  • בעל אפליקציה (נקרא גם יצרן): יוצר הודעות ושולח (מפרסם) אותן לשירות העברת ההודעות בנושא מסוים.

  • הודעה: הנתונים שמועברים דרך השירות.

  • נושא: ישות בעלת שם שמייצגת פיד של הודעות.

  • סכימה: ישות בעלת שם שקובעת את פורמט הנתונים של הודעת Pub/Sub.

  • מינוי: ישות בעלת שם שמייצגת עניין בקבלת הודעות בנושא מסוים.

  • מנוי (נקרא גם צרכן): מקבל הודעות במינוי שצוין.

בתהליך הבא מתואר תהליך העבודה של שירות Pub/Sub:

  1. שתי אפליקציות לשליחת הודעות, Publisher 1 ו-Publisher 2, שולחות הודעות לנושא אחד ב-Pub/Sub. בעל תוכן דיגיטלי 1 שולח את הודעה א' ובעל תוכן דיגיטלי 2 שולח את הודעה ב'.

  2. הנושא עצמו משויך לשני מינויים. אלה הם מינוי 1 ומינוי 2.

  3. הנושא גם מצורף לסכימה.

  4. כל מינוי מקבל עותק של הודעות A ו-B מהנושא.

  5. מינוי 1 מקושר לשתי אפליקציות של מנויים, מנוי 1 ומנוי 2. שני יישומי המנויים מקבלים קבוצת משנה של ההודעות מהנושא. בדוגמה הזו, Subscriber 1 מקבל את message B, ואילו Subscriber 2 מקבל את message A מהנושא.

  6. מינוי 2 מקושר רק לאפליקציית מנוי אחת שנקראת מנוי 3. לכן, Subscriber 3 מקבל את כל ההודעות מהנושא.

מחזור החיים של הודעה

נניח שלקוח יחיד של מו"ל מחובר לנושא. לנושא יש מינוי אחד שמצורף אליו. מנוי יחיד מחובר למינוי.

איור שמראה איך הודעה עוברת ב-Pub/Sub.
איור 2: הודעה זורמת מלקוח של מפרסם ללקוח של מנוי דרך Pub/Sub.

בשלבים הבאים מוסבר איך הודעה עוברת ב-Pub/Sub:

  1. אפליקציה של בעל תוכן דיגיטלי שולחת הודעה לנושא ב-Pub/Sub.

  2. ההודעה נכתבת לאחסון.

  3. בנוסף לכתיבת ההודעה לאחסון, Pub/Sub מעביר את ההודעה לכל המינויים שמצורפים לנושא.

    בדוגמה הזו, מדובר במינוי יחיד.

  4. המינוי שולח את ההודעה לאפליקציית מנויים מצורפת.

  5. האפליקציה הרשומה שולחת אישור ל-Pub/Sub שהיא עיבדה את ההודעה.

    אחרי שלפחות נמען אחד לכל מינוי מאשר את קבלת ההודעה, Pub/Sub מוחק את ההודעה מהאחסון.

הסטטוס של הודעה ב-Pub/Sub

בזמן שהודעה ממתינה למנוי, מערכת Pub/Sub לא מנסה להעביר אותה למנוי אחר באותו מינוי. למנוי יש כמות מוגבלת של זמן שאפשר להגדיר, שנקראת ackDeadline, כדי לאשר את קבלת ההודעה. אחרי שהמועד האחרון חולף, ההודעה כבר לא נחשבת כהודעה שלא נמסרה, והיא זמינה למסירה שוב.

יכולים להיות שלושה מצבים להודעה בשירות Pub/Sub:

  • הודעות שאושרה קבלתן (acked). אחרי שאפליקציה רשומה מעבדת הודעה שנשלחה מנושא למינוי, היא שולחת אישור בחזרה ל-Pub/Sub. אם כל המנויים בנושא מסוים אישרו את ההודעה, ההודעה נמחקת באופן אסינכרוני ממקור ההודעה לפרסום ומאחסון.

  • הודעות שלא אושרו (unacked). אם Pub/Sub לא מקבל אישור לפני תום המועד לאישור, יכול להיות שהודעה תימסר יותר מפעם אחת. לדוגמה, יכול להיות שהמנוי ישלח אישור אחרי שהמועד האחרון יחלוף, או שהאישור יאבד בגלל בעיות זמניות ברשת. הודעה שלא אושרה תמשיך להימסר עד שתוקף משך השמירה של ההודעה יפוג מאז שההודעה פורסמה. בשלב הזה, תוקף ההודעה יפוג.

  • הודעות שקיבלו אישור שלילי (nacked). אם אפליקציה רשומה שולחת NACK להודעה, מערכת Pub/Sub שולחת אותה מחדש באופן מיידי על סמך הגדרות ברירת המחדל של הניסיון החוזר, שאפשר לשנות אותן. כשמנוי שולח הודעות NACK שהן לא תקינות או שהוא לא מצליח לעבד את ההודעות, הוא עוזר לוודא שההודעות האלה לא יאבדו ושהן יעובדו בהצלחה. אפשר להשתמש ב-modifyAckDeadline עם ערך של 0 כדי לשלוח NACK להודעה.

בחירת תבנית של פרסום ומינוי ב-Pub/Sub

אם יש כמה לקוחות של Pub/Sub לפרסום ולמינוי, צריך גם לבחור את סוג הארכיטקטורה של הפרסום והמינוי שרוצים להגדיר.

איור שמציג דפוסי פרסום והרשמה שונים.
איור 3 הקשרים בין בעלי תוכן דיגיטלי לבין מנויים יכולים להיות מסוג רבים לאחד (fan-in), רבים לרבים (load-balanced) ואחד לרבים (fan-out).

אלה כמה מהדפוסים הנתמכים של פרסום והרשמה ב-Pub/Sub:

  • Fan in (many-to-one). בדוגמה הזו, כמה אפליקציות של בעלי תוכן דיגיטלי מפרסמות הודעות בנושא יחיד. הנושא היחיד הזה משויך למינוי יחיד. המינוי, בתורו, מקושר לאפליקציית מנוי יחידה שמקבלת את כל ההודעות שפורסמו בנושא.

  • איזון עומסים (רבים לרבים). בדוגמה הזו, אפליקציות של מוציאים לאור (יחידה או כמה) מפרסמות הודעות בנושא יחיד. הנושא היחיד הזה מצורף למינוי יחיד שמחובר לכמה אפליקציות של מנויים. כל אחת מאפליקציות המנויים מקבלת קבוצת משנה של ההודעות שפורסמו, ואין שתי אפליקציות מנויים שמקבלות את אותה קבוצת משנה של הודעות. במקרה הזה של איזון עומסים, משתמשים בכמה מנויים כדי לעבד הודעות בהיקף גדול. אם צריך לתמוך ביותר הודעות, אפשר להוסיף עוד מנויים לקבלת הודעות מאותו מינוי.

  • הפצה (אחד לרבים). בדוגמה הזו, אפליקציה אחת או כמה אפליקציות של בעלי תוכן דיגיטלי מפרסמות הודעות בנושא אחד. הנושא הזה מצורף לכמה מינויים. כל מינוי מקושר לאפליקציית מינוי אחת. כל אחת מהאפליקציות של המנויים מקבלת את אותה קבוצה של הודעות שפורסמו בנושא. אם לנושא יש כמה מינויים, כל הודעה צריכה להישלח למנוי שמקבל הודעות בשם כל מינוי. אם אתם צריכים לבצע פעולות שונות על אותו מערך של הודעות, האפשרות fan out היא בחירה טובה. אפשר גם לצרף כמה מנויים לכל מינוי ולקבל קבוצת משנה של הודעות עם איזון עומסים לכל מנוי.

בחירת אפשרות הגדרה של Pub/Sub

אפשר להגדיר סביבת Pub/Sub באמצעות אחת מהאפשרויות הבאות:

  • מסוףGoogle Cloud
  • Google Cloud CLI
  • ספריות לקוח ב-Cloud (ספריית לקוח ברמה גבוהה)
  • ממשקי API ל-REST ול-RPC (ספריית לקוח ברמה נמוכה)

הבחירה שלכם באפשרות הגדרה של Pub/Sub תלויה בתרחיש השימוש.

אם אתם חדשים ב- Google Cloud console ורוצים לבדוק את Pub/Sub, אתם יכולים להשתמש ב-console או ב-gcloud CLI.

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

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

ריכזנו כאן כמה שיטות מומלצות לשימוש בספריות הלקוח:

  • בוחרים את השפה הנכונה של ספריית הלקוח. הביצועים של ספריות הלקוח של Pub/Sub משתנים בהתאם לשפה. לדוגמה, ספריית הלקוח של Java יעילה יותר בהרחבה אנכית מאשר ספריית הלקוח של Python, ויכולה להתמודד עם נפח נתונים גדול יותר. השפות Java,‏ C++‎ ו-Go יעילות יותר מבחינת משאבי המחשוב שנדרשים לטיפול בעומסי העבודה של פרסום או הרשמה.

  • משתמשים בגרסה העדכנית ביותר של ספריית הלקוח. ספריות הלקוח של Pub/Sub מתעדכנות כל הזמן עם תכונות חדשות ותיקוני באגים. חשוב לוודא שאתם משתמשים בגרסה העדכנית של ספריית הלקוח בשפה שלכם.

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

איך מגדירים Pub/Sub

אלה השלבים העיקריים להגדרת Pub/Sub:

  1. יוצרים או בוחרים פרויקט שבו אפשר להגדיר Pub/Sub. Google Cloud

  2. מפעילים את Pub/Sub API.

  3. קבלת התפקידים וההרשאות שנדרשים להפעלת Pub/Sub.

  4. יוצרים נושא.

  5. אם מבנה ההודעה הוא קריטי, צריך להגדיר סכימה להודעות.

  6. מצרפים את הסכימה לנושא.

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

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

  9. בוחרים את סוג המינוי בהתאם לאופן שבו רוצים לקבל הודעות.

  10. יוצרים מינוי לנושא שבחרתם.

  11. הגדרת לקוח של מנוי שיכול לקבל הודעות מהמינוי.

  12. אם נדרש, מגדירים אפשרויות מתקדמות למסירת הודעות, כמו מסירה של כל הודעה בדיוק פעם אחת, ניהול פרק זמן לעיבוד (lease), מסירה לפי סדר ובקרה על זרימת נתונים.

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

  14. במקביל, מגדירים את לקוח המינוי לקבל ולעבד את ההודעות האלה.

הנחיות למתן שם לנושא, למינוי, לסכימה או לתמונת מצב

שם משאב ב-Pub/Sub מזהה באופן ייחודי משאב ב-Pub/Sub, כמו נושא, מינוי, סכימה או תמונת מצב. שם המשאב צריך להיות בפורמט הבא:

projects/project-identifier/collection/ID

  • ‫project-identifier: צריך להיות מזהה הפרויקט או מספר הפרויקט, שזמינים במסוף Google Cloud . לדוגמה, my-cool-project הוא מזהה פרויקט. ‫123456789123 הוא מספר הפרויקט.

  • ‫collection: הערך חייב להיות אחד מהערכים הבאים: topics, ‏subscriptions, ‏schemas או snapshots.

  • ID: צריך להיכתב לפי ההנחיות האלה:

    • לא מתחיל במחרוזת goog
    • התחלה באות
    • הוא צריך לכלול בין 3 ל-255 תווים
    • הוא יכול לכלול רק את התווים הבאים: אותיות [A-Za-z], מספרים [0-9], מקפים -, קווים תחתונים _, נקודות ., טילדות ~, סימני פלוס + וסימני אחוז %

    אפשר להשתמש בתווים המיוחדים שמופיעים ברשימה שלמעלה בשמות של משאבים בלי לקודד אותם בפורמט URL. עם זאת, כשמשתמשים בתווים מיוחדים אחרים בכתובות URL, צריך לוודא שהם מקודדים או מפוענחים בצורה תקינה. לדוגמה, mi-tópico הוא מזהה לא תקין. לעומת זאת, mi-t%C3%B3pico הוא ערך תקין. הפורמט הזה חשוב כשמבצעים קריאות REST.

המאמרים הבאים