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

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

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

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

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

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

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

פתרון העזר של Fleet Events הוא פתרון בקוד פתוח שמאפשר ללקוחות ולשותפים של 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 Events

הפריסה של Cloud Project

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

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

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

אבטחה

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

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

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

נספח

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

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

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

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

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

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

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

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

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

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

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

תורמים

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

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

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