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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פריסה

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

מודולים של Terraform

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

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

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

אבטחה

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

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

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

נספח

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

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

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

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

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

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

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

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

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

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

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

תורמים

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

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