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

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

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

המסמך הזה ממחיש איך מפתחים יכולים להפוך אותות מ-"שירותי הניידות" של הפלטפורמה של מפות Google ("Last Mile Fleet Solution" (LMFS) או "On-demand Rides and Deliveries" (ODRD) לאירועים מותאמים אישית שמאפשרים פעולה. בנוסף, נסביר על מושגים מרכזיים ועל החלטות עיצוב של הפתרון לדוגמה לאירועים בצי שזמין ב-GitHub.

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

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

סקירה כללית של פתרון תיעוד לאירועי כלל המכשירים בארגון

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

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

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

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

אבני בניין לוגיות

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

סקירה כללית על אירועים ב-Fleet ואבני בניין לוגיות

פתרון העזרה כולל את הרכיבים הבאים:

  • מקור האירוע: המקור שממנו מגיע מקור האירועים המקורי. גם ב-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

הפריסה של Cloud Project

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

מקור האירוע

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

כיור

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

בעיבוד

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

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

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

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

פריסה

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

מודולים של Terraform

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

המודולים הכלולים בפתרון העזר:

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

אבטחה

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

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

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

נספח

עמידה בדרישות

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

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

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

עקרונות התכנון והעיצוב

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

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

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

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

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

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

תורמים

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

המחברים הראשיים:

  • מרי פישני | מנהלת מוצר, הפלטפורמה של מפות Google
  • את'ל באו| מהנדסי תוכנה, הפלטפורמה של מפות Google
  • Mohanad Almiski | מהנדס תוכנה, הפלטפורמה של מפות Google
  • Naoya Moritani | מהנדס פתרונות, הפלטפורמה של מפות Google