פוסט 3 - תיאור התהליך המרכזי במערכת

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

ברגע שהחלטתי שהמערכת תהיה אנונימית לחלוטין הייתי צריך למצוא פתרון לשני קשיים אלה:

1. לדעת לסנן דיווחי סרק, הרי אין לי דרך לדעת מי המדווח.

2. לדעת מתי שני דיווחים או יותר מדברים על אותו אירוע ולא על אירועים שונים.

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

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

התרשים מטה מתאר את המתרחש כאשר נוצר אירוע אמת במערכת ועד ההופעה של האירוע בפאנל הניהול. (במקרה זה מס' המדווחים הוא 2):

מספר נקודות אודות התרשים:

א. תקשורת בין המיקרו סרביסס במערכת - התקשורת בין המיקרו סרביסס במערכת מבוססת על הודעות שמנוהלת על ידי שרת AMQP מסוג RabbitMQ.

ב. שני אופנים להפצת הודעות:

• כאשר התקשורת היא ישירה בין מיקרו סרביס שולח (Producer), למיקרו סרביס מקבל (Consumer), ההודעה נכנסת ל-Queue, 
• כאשר התקשורת היא בין מיקרו סרביס שולח (Producer), למספר מיקרו סרביסס מקבלים (Consumers), ההודעה נשלחת ל-Topic.

ג. התקשורת בין ה-Web Micro Service למיקרו סרביסס האחרים היא שונה והיא מתבצעת באמצעות פניות REST, כל מיקרו סרביס חושף REST API שנגיש ע״י ה-Web Micro Service בלבד.

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

ה-FLOW הסנדרטי הוא כדלהלן:

1. המיקרו סרביס שמקבל את ההודעות מהתושבים הוא Listener Micro Service.

2. Listener Micro Service אוגר הודעות ועדיין לא מדווח על ״אירוע אמת״ עד שלא מגיעים למספר הדיווחים המינימלי שהוגדר.

3. כאשר מתקיימים שלושת התנאים - מספיק דיווחים מאותו איזור ובטווח הזמן שהוגדר, ה-Listener Micro Service מיצר ״אירוע אמת״.

4. שתי פעולות מתבצעות כאשר זוהה ״אירוע אמת״:

• הכנסה לדטה בייס הראשי.
• שליחת הודעה ל-Topic שרשומים אליו שלושה מיקרו סרביסס, כפי שמתואר בתרשים:

5. ברגע שההודעה מגיעה ל-Topic, נכנסים לפעולה שלושת המיקרו סרביסס הבאים: 

• Geo Micro Service - פונה לשרתים של גוגל עם הקורדינטות של ה״אירוע אמת״, מקבל חזרה כתובת מלאה ומכניס אותה לדטה בייס.
• Notification Micro Service - שומר את המספר מזהה היחודי של התושבים שדיווחו על ה״אירוע אמת״. שימוש במידע זה יבוא לידי ביטוי במנגון לניהול האירועים ועדכון התושב, באמצעות הודעות פוש (Push Notifications), בהתקדמות הטיפול באירוע שהוא דיווח עליו.
• Score Micro Service - מוסיף נקודה לתושבים שהדיווח שלהם התגלה כדיווח אמת וזאת ע״ב המספר מזהה היחודי שלהם בלבד. 

6. Event Micro Service הוא מיקרו סרביס סינגלטוני (Singleton), הוא מחזיק כל העת רשימה עדכנית של אירועי האמת שנמצאים בדטה בייס. (מתבצע באמצעות תהליך שבכל כמה שניות ניגש לדטה בייס ובודק אם יש אירוע חדש).

7. גם ל-Web Micro Service יש תהליך פנימי שרץ כל כמה שניות (Schedule Task) ופונה באמצעות פניית REST ל-Event Micro Service ובודק האם נכנסו אירועים חדשים.

8. נחזור רגע לאפליקציה שהתושבים מדווחים באמצעותה - לאחר שמועבר הדיווח (וגם כל התהליכים שתוארו מעלה אך התושב לא חשוף אליהם) נפתח פופ-אפ (Pop-up Dialog), השואל את התושב האם הוא מעוניין לצרף תמונה ממקום האירוע.

9. במידה והתושב מצרף תמונה ממקום האירוע התמונה נשלחת למיקרו סרביס אחר והוא ,Photo Micro Service. המיקרו סרביס הזה שומר את התמונה ותפקידו הוא ניהול התמונות שהתקבלו מהתושבים.

10. לאחר המתואר ב-9 בין אם התושב שלח תמונה ובין אם לאו, נפתח פופ-אפ, (Pop-up Dialog), השואל את התושב האם מעוניין לצרף תיאור/הערה בנוגע למתרחש באירוע, גם מידע הזה מגיע ישירות למיקרוסרביס אחר מבין אלה שהוזכרו והוא, Comment Micro Service. תפקידו הוא לנהל את המלל המתקבל מהתושבים.

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

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

זהו לבינתיים, 

מייק.