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

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

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

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

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

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

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

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

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

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