יצירת אירועים כמעט בזמן אמת באמצעות Fleet Engine ופתרון ההפניה לאירועים של Fleet

אותות כמעט בזמן אמת מה-Fleet שפועל בשטח יכולים לעזור לעסקים בכמה דרכים. לדוגמה, עסקים יכולים להשתמש בהם כדי:

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

במסמך הזה מוסבר איך מפתחים יכולים להפוך אותות מ'שירותי ניידות' בפלטפורמה של מפות Google (פתרון לניהול צי רכבים למשלוחים (LMFS) או פתרון להזמנת נסיעות ומשלוחים לפי דרישה (ODRD)) לאירועים מותאמים אישית שאפשר לבצע לגביהם פעולות. בנוסף, מוסברים מושגים מרכזיים והחלטות עיצוביות של פתרון Fleet Events Reference שזמין ב-GitHub.

המסמך הזה רלוונטי ל:

בסוף המאמר הזה תהיה לכם הבנה בסיסית של הרכיבים העיקריים של מערכת סטרימינג ושיקולים חשובים לגביה, וגם של אבני הבניין מ-Google Maps Platform ומ-Google Cloud שמרכיבות את פתרון ההפניה לאירועים של צי הרכב.

סקירה כללית של פתרון Fleet Events Reference

פתרון ההפניה לאירועים של צי הרכב הוא פתרון קוד פתוח שמאפשר ללקוחות ולשותפים של Mobility ליצור אירועים מרכזיים על בסיס Fleet Engine ורכיבי Google Cloud. היום, פתרון ההפניה תומך בלקוחות שמשתמשים בפתרון לניהול צי רכב למשלוחים, ובהמשך יתווסף תמיכה בנסיעות לפי דרישה.

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

  • שינוי בזמן ההגעה המשוער למשימה
  • שינוי יחסי בזמן ההגעה המשוער של המשימה
  • הזמן שנותר עד להגעת המשימה
  • המרחק שנותר עד ההגעה למשימה
  • שינוי בסטטוס TaskOutcome

אפשר להתאים אישית כל רכיב של פתרון ההפניה בהתאם לצרכים העסקיים שלכם.

רכיבים לוגיים

דיאגרמה : הדיאגרמה הבאה מציגה אבני בניין ברמה גבוהה שמרכיבות את פתרון ההפניה Fleet Events

סקירה כללית של אירועים בצי רכב ובלוקים לוגיים

פתרון ההפניה מכיל את הרכיבים הבאים:

  • מקור האירוע: המקום שממנו מגיע הזרם המקורי של האירועים. גם Last Mile Fleet Solution וגם On-demand Rides and Deliveries Solution משולבים עם Cloud Logging, וכך עוזרים להפוך יומני רישום של קריאות ל-RPC ב-Fleet Engine לזרמי אירועים שזמינים למפתחים. זהו המקור העיקרי לשימוש.
  • עיבוד: יומני שיחות RPC גולמיים מומרים לאירועים של שינוי מצב בתוך הבלוק הזה, שמבצע חישובים על זרם של אירועים ביומן. כדי לזהות שינוי כזה, הרכיב הזה דורש מאגר מצב כדי שאפשר יהיה להשוות בין אירועים חדשים שמגיעים לבין אירועים קודמים ולזהות שינוי. יכול להיות שהאירועים לא תמיד יכללו את כל המידע הרלוונטי. במקרים כאלה, יכול להיות שהחסימה תגרום לחיפושים בשרתי קצה לפי הצורך.
    • מאגר מצב: חלק ממסגרות העיבוד מספקות נתונים ביניים שמתמידים בעצמם. אבל אם לא, כדי לאחסן את המצב בעצמכם, כדאי להשתמש בשירות התמדה של נתונים מסוג K-V, כי הנתונים האלה צריכים להיות ייחודיים לרכב ולסוג האירוע.
  • Sink (אירועים בהתאמה אישית): שינוי הסטטוס שזוהה צריך להיות זמין לכל אפליקציה או שירות שיכולים להפיק ממנו תועלת. לכן, כדאי לפרסם את האירוע המותאם אישית הזה במערכת להעברת אירועים לצורך צריכה בהמשך.
  • שירות במורד הזרם: קוד שצורכת את האירועים שנוצרו ומבצע פעולות שייחודיות לתרחיש השימוש שלכם.

בחירת שירות

כשמטמיעים את פתרון ההפניה Last Mile Fleet Solution או On-demand Rides and Deliveries Solution (שיושק בסוף הרבעון השלישי של 2023), בחירת הטכנולוגיה ל-Source ול-Sink היא פשוטה. לעומת זאת, בקטע 'עיבוד' יש מגוון רחב של אפשרויות. בפתרון ההפניה נבחרו שירותי Google הבאים.

דיאגרמה : הדיאגרמה הבאה מציגה שירות Google Cloud להטמעה של פתרון ההפניה

אבני בניין של פתרונות לדוגמה ל-Fleet Events

פריסת פרויקט ב-Cloud

מומלץ להגדיר פריסה בכמה פרויקטים כברירת מחדל. כך אפשר להפריד בצורה ברורה בין השימוש ב-Google Maps Platform לבין השימוש ב-Google Cloud, ולקשר את השימוש להסדר החיוב שבחרתם.

המקור המשויך לאירוע

‫Last Mile Fleet Solution ו-On-demand Rides and Deliveries Solution כותבים מטען ייעודי (payload) של בקשות ותגובות ל-API אל Cloud Logging. Cloud Logging מעביר יומנים לשירות אחד או יותר לפי בחירה. ניתוב ל-Cloud Pub/Sub הוא בחירה מצוינת במקרה הזה, והוא מאפשר להמיר יומנים לזרם אירועים בלי לכתוב קוד.

כיור

ב-Google Cloud, המערכת המומלצת להעברת הודעות כמעט בזמן אמת היא Cloud Pub/Sub. בדיוק כמו שהאירועים מהמקור נמסרו ל-Pub/Sub, גם אירועים בהתאמה אישית מתפרסמים ב-Pub/Sub לצריכה במורד הזרם.

בעיבוד

הרכיבים הבאים ממלאים תפקיד בעיבוד האירועים. בדומה לרכיבים האחרים, רכיבי העיבוד הם serverless לחלוטין, ויש להם יכולת טובה להתרחב ולהצטמצם.

  • ‫Cloud Functions כפלטפורמת מחשוב לגרסה הראשונית (*)
    • טכנולוגיה ללא שרת, עם אפשרות להגדלה ולהקטנה של הקיבולת באמצעות אמצעי בקרה של שינוי הגודל, כדי לנהל את העלויות
    • ‫Java כשפת התכנות, בהתחשב בזמינות של ספריות לקוח לממשקי API שקשורים ל-Fleet Engine, שמקלים על ההטמעה
  • ‫Cloud Firestore כמאגר מצבים
    • מאגר מפתח/ערך בלי שרת (serverless)
  • ‫Cloud Pub/Sub כנקודת שילוב עם רכיבים במעלה הזרם ובמורד הזרם
    • שילוב בצימוד חלש כמעט בזמן אמת

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

*הערה: אנחנו מתכננים לפרסם פתרונות חלופיים לפתרון ההפניה הזה, שיעזרו לעמוד בדרישות שונות.

פריסה

כדי שהפריסה של פתרון ההפניה תהיה ניתנת לחזרה, להתאמה אישית, לשליטה בקוד המקור ומאובטחת, נבחר Terraform ככלי האוטומציה. ‫Terraform הוא כלי IaC (תשתית כקוד) פופולרי עם תמיכה עשירה ב-Google Cloud.

מודולים של Terraform

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

מודולים שנכללים בפתרון ההפניה:

  • הגדרת רישום ביומן של Fleet Engine: אוטומציה של ההגדרות שקשורות ל-Cloud Logging לשימוש עם Fleet Engine. בפתרון לדוגמה, הוא משמש להפניית יומנים שקשורים ל-Fleet Engine לנושא Pub/Sub שצוין.
  • פריסת פונקציית Cloud של אירועים בצי: מכיל את פריסת קוד הפונקציה לדוגמה ומטפל גם באוטומציה של הגדרות ההרשאות שנדרשות לשילוב מאובטח בין פרויקטים.
  • פריסה של פתרון הפניה מלא: קוראת לשני המודולים הקודמים ועוטפת את הפתרון כולו.

אבטחה

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

הפעולות הבאות

עכשיו אתם יכולים לגשת לפתרון Fleet Events Reference ולבדוק אותו לעומק. כדי להתחיל, עוברים אל GitHub.

נספח

איסוף הדרישות

מומלץ לאסוף את הדרישות בשלב מוקדם יותר בתהליך.

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

  • איזה מידע נדרש כדי שמקור נתונים של אירועים יהיה שימושי?
    • האם אפשר להסיק את התוצאה רק מנתונים שנאספו או נוצרו בשירותי Google? או, האם נדרש העשרה של נתונים באמצעות מערכות חיצוניות משולבות? אם כן, מהן המערכות האלה ואילו ממשקי שילוב הן מציעות?
    • אילו מדדים היית רוצה למדוד בעסק שלך? איך הם מוגדרים?
    • אם צריך לחשב מדדים על סמך אירועים, איזה סוג צבירה נדרש? נסו לתאר את השלבים ההגיוניים. למשל: השוואה בין זמן ההגעה המשוער (ETA) וזמן ההגעה בפועל (ATA) לבין יעדי רמת השירות (SLO) עבור קבוצת משנה של צי כלי הרכב בשעות השיא, כדי לחשב את הביצועים במגבלות משאבים).
  • למה מעניין אותך מודל מבוסס-אירועים ולא מודל מבוסס-אצווה? האם זה לצורך השהיה נמוכה יותר (זמן עד לפעולה) או לצורך שילוב עם צימוד רופף (גמישות)?
    • אם רוצים להגדיר זמן אחזור נמוך, מגדירים את הערך low. דקות? שניות? פחות משנייה? ומה זמן האחזור?
  • האם כבר השקעתם בסטאק תוכנות ובכישורים קשורים כצוות? אם כן, מהו ומהן נקודות השילוב שהוא מספק?
    • האם יש דרישות שהמערכות הנוכחיות שלכם לא יכולות לעמוד בהן או שעלולות להתקשות בעיבוד אירועים שמגיעים מהצי שלכם?

עקרונות עיצוב

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

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

מושגים בנושא סטרימינג

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

  • התאמה לגודל : בניגוד לעיבוד באצווה, שבו בדרך כלל יש מושג טוב לגבי כמות הנתונים לעיבוד, בסטרימינג אין מושג כזה. פקק תנועה בעיר יכול ליצור הרבה אירועים בבת אחת מאזור מסוים, ועדיין צריך להיות אפשר לעבד אותם.
  • חלונות : במקום לעבד אירועים בזה אחר זה, לעיתים קרובות רוצים לקבץ אירועים על ציר זמן לחלונות קטנים יותר כיחידה לחישוב. יש מגוון אסטרטגיות של חלונות זמן, כמו 'חלונות קבועים (למשל, כל יום ביומן)', 'חלונות נעים (5 הדקות האחרונות)', 'חלונות של סשן (במהלך הנסיעה הזו)'. צריך לבחור מתוך האפשרויות האלה. ככל שחלון הזמן ארוך יותר, כך העיכובים בהפקת התוצאות ארוכים יותר. בוחרים את המודל וההגדרה שמתאימים לדרישות שלכם.
  • הפעלה : יש מקרים שבהם אין ברירה אלא להשתמש בחלונות ארוכים יחסית. עם זאת, לא כדאי לחכות לסוף חלון הזמן כדי ליצור אירועים, אלא להפיק תוצאות ביניים. אפשר להשתמש בגישה הזו בתרחישי שימוש שבהם יש ערך בהצגת תוצאות מהירות קודם, ואז תיקון שלהן בהמשך. נניח שאתם שולחים סטטוס ביניים אחרי 25%, 50% ו-75% השלמה של מסירה.
  • סדר : האירועים לא בהכרח מגיעים למערכת בסדר שבו הם נוצרו. במיוחד בתרחישי שימוש שכוללים תקשורת ברשתות סלולריות שמוסיפה עיכובים ונתיבי ניתוב מורכבים. חשוב להבין את ההבדל בין 'זמן האירוע' (הזמן שבו האירוע התרחש בפועל) לבין 'זמן העיבוד' (הזמן שבו האירוע הגיע למערכת), ולטפל באירועים בהתאם. בדרך כלל, כדאי לעבד אירועים על סמך 'שעת האירוע'.
  • שליחת הודעות – לפחות פעם אחת לעומת בדיוק פעם אחת: פלטפורמות שונות של אירועים תומכות באפשרויות האלה באופן שונה. בהתאם לתרחיש לדוגמה, צריך לשקול אסטרטגיות לניסיונות חוזרים או לביטול כפילויות.
  • שלמות : כמו בשינוי סדר ההודעות, יש סיכוי שהודעות יאבדו. זה יכול לקרות בגלל כיבוי של האפליקציה והמכשיר בגלל חיי הסוללה של המכשיר, נזק לא מכוון לטלפון, אובדן קישוריות בזמן שהייה במנהרה או הודעה שהתקבלה אבל רק מחוץ לחלון זמן מקובל. איך חוסר שלמות ישפיע על התוצאות?

זוהי רשימה חלקית בלבד. ריכזנו כאן כמה מקורות מידע מומלצים שיעזרו לכם להבין טוב יותר כל אחד מהנושאים.

תורמים

‫Google היא זו שמעדכנת את המסמך הזה. הוא נכתב במקור על ידי התורמים הבאים.

המחברים העיקריים: