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

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

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

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

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

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

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

פתרון ההפניה Fleet Events הוא פתרון קוד פתוח שמאפשר ללקוחות ולשותפים של 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 כמאגר מצבים
    • מאגר Key-Value ללא שרת
  • ‫Cloud Pub/Sub כנקודת שילוב עם רכיבים במעלה הזרם ובמורד הזרם
    • שילוב בצימוד חלש כמעט בזמן אמת

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

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

פריסה

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

מודולים של Terraform

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

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

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

אבטחה

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

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

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

נספח

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

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

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

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

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

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

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

מושגים שקשורים לסטרימינג

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

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

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

תורמים

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

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