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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • מקור האירוע: המקור שממנו מגיע האירוע המקורי. גם ל-"Last Mile Fleet הפתרון" וגם ל "הפתרון לנסיעות ולמשלוחים לפי דרישה" יש שילוב עם Cloud Logging, שעוזר להפוך את יומני הקריאות של Fleet Engine RPC אל מקורות האירועים הזמינים למפתחים. זה המקור העיקרי שצריך לצרוך.
  • עיבוד: יומני קריאות גולמיים של RPC מומרים לאירועי שינוי מצב בבלוק הזה, שמחשב על רצף של אירועים ביומן. כדי לזהות שינוי כזה, לרכיב הזה נדרשת מאגר מצב, כדי שאפשר יהיה להשוות אירועים נכנסים חדשים לאירועים קודמים ולזהות שינוי. אירועים לא תמיד כוללים את כל המידע הרצוי. במקרים כאלה, הבלוק הזה עשוי לבצע חיפוש של קריאות לקצוות עורפיים לפי הצורך.
    • המאגר של המדינה: מסגרות עיבוד מסוימות מספקות נתונים ברמת ביניים בעצמן. אבל אם לא, כדי לאחסן מצבים בעצמכם, מכיוון שהם צריכים להיות ייחודיים לרכב ולסוג אירוע, מומלץ להשתמש בשירות שמירת נתונים מסוג K-V.
  • Sink (Custom events): שינוי המצב שזוהה צריך להיות זמין לכל אפליקציה או שירות שזקוקים לכך. לכן, מומלץ לפרסם את האירוע המותאם אישית הזה במערכת להצגת אירועים לצורך צריכה בהמשך.
  • שירות downstream: קוד שצורך את האירועים שנוצרו ומקבל פעולות ייחודיות לתרחיש לדוגמה שלכם.

בחירת שירות

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

תרשים : בתרשים הבא מוצג שירות Google Cloud להטמעת פתרון ההפניה.

אבני בניין של פתרונות לעיון לאירועי Fleet

פריסת הפרויקט ב-Cloud

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

מקור האירוע

"הפתרון של Last Mile Fleet" ו "הפתרון לנסיעות ולמשלוחים לפי דרישה", כותבים מטענים ייעודיים של בקשות API ושל תגובות ל-Cloud Logging. Cloud Logging מספק יומנים לשירות אחד או יותר לפי בחירתכם. ניתוב ל-Cloud Pub/Sub הוא בחירה מושלמת כאן, ומאפשר להמיר יומנים לשידור של אירועים בלי תכנות.

כיור

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

מתבצע עיבוד

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

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

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

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

פריסה

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

מודולים של Terraform

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

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

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

אבטחה

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

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

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

נספח

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

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

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

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

עקרונות תכנון

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

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

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

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

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

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

תורמים

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

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