אירועים בזמן אמת ב-Fleet Engine

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

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

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

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

  • אדריכלים שמכירים את שירותי הניידות של הפלטפורמה של מפות Google ואת אחד מרכיבי הליבה שלה, Fleet Engine. אם אתם חדשים ב-"Mobility services", אנחנו ממליצים לכם לקרוא על Last Mile Fleet Solution או על On-demand Rides and Deliveries Solution, בהתאם לצרכים שלכם.
  • אדריכלים שמכירים את Google Cloud. אם אתם חדשים ב-Google Cloud, מומלץ לקרוא את המאמר יצירת צינורות להזרמת נתונים ב-Google Cloud.
  • אם אתם מטרגטים סביבות או חבילות תוכנה אחרות, כדאי להתמקד בהבנת נקודות השילוב של Fleet Engine ושיקולים מרכזיים, שעדיין רלוונטיים.
  • אנשים שמתעניינים באופן כללי בדרכים ליצירה ולשימוש באירועים מצי רכב.

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

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

הפתרון לדוגמה Fleet Events Reference Solution הוא פתרון קוד פתוח שמאפשר ללקוחות ולשותפים של 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 של אירועים בצי: מכיל את פריסת קוד הפונקציה לדוגמה ומטפל גם באוטומציה של הגדרות ההרשאות שנדרשות לשילוב מאובטח בין פרויקטים.
  • פריסה של פתרון הפניה מלא: קוראת לשני המודולים הקודמים ועוטפת את הפתרון כולו.

אבטחה

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

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

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

נספח

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

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

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

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

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

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

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

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

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

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

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

תורמים

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

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