ההיסטוריה של ארכיטקטורת Dodo IS: The Back Office Path

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

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

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

סדרת מאמרים "מה זה Dodo IS?" מספר על:

1. מונוליט מוקדם ב-Dodo IS (2011-2015). (בתהליך...)
2. מסלול המשרד האחורי: בסיסים נפרדים ואוטובוס. (אתה כאן)
3. שביל צד הלקוח: חזית מעל הבסיס (2016-2017). (בתהליך...)
4. ההיסטוריה של שירותי מיקרו אמיתיים. (2018-2019). (בתהליך...)
5. סיים ניסור של המונוליט וייצוב הארכיטקטורה. (בתהליך...)

אם אתם מעוניינים לדעת עוד משהו - כתבו בתגובות.

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

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

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

בשנת 2011, ארכיטקטורת Dodo IS נראתה כך:

עד 2020, זה הפך קצת יותר מסובך והפך ככה:

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

הבעיות הראשונות של 2016: מדוע שירותים צריכים לעזוב את המונוליט

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

מסד נתונים MySql יחיד, שבו כל האפליקציות שהיו קיימות באותה תקופה ב-Dodo IS כתבו את הרשומות שלהם. ההשלכות היו:

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

הבעיה הייתה נוכחותו של המונוליט עצמו. ההשלכות היו:

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

בעיות בבסיס ובמונוליט תוארו פעמים רבות, למשל, בהקשר של קריסות בתחילת 2018 (תהיה כמו מאנץ', או כמה מילים על חוב טכני, היום שבו דודו IS נעצר. סקריפט אסינכרוני и סיפורה של ציפור הדודו ממשפחת הפניקס. הנפילה הגדולה של דודו IS), אז אני לא אתעכב יותר מדי. הרשו לי רק לומר שרצינו לתת יותר גמישות בפיתוח שירותים. קודם כל, זה נגע לאלה שהיו הכי טעונים ושורשיים בכל המערכת - Auth ו-Tracker.

נתיב המשרד האחורי: בסיסים ואוטובוס נפרדים

פרק ניווט

1. תכנית מונולית 2016
2. מתחילים לפרוק את המונולית: הפרדת אימות ומעקב
   
3. מה Auth עושה?
4. מאיפה העומסים?
5. פריקת אישור
6. מה עושה Tracker?
7. מאיפה העומסים?
8. Tracker פריקה

תכנית מונולית 2016

להלן הבלוקים העיקריים של המונוליט Dodo IS 2016, ומיד למטה יש תמליל של המשימות העיקריות שלהם.

משלוח קופאית. הנהלת חשבונות לשליחים, הוצאת הזמנות לשליחים.
מרכז קשר. קבלת הזמנות דרך המפעיל.
אֲתַר. אתרי האינטרנט שלנו (dodopizza.ru, dodopizza.co.uk, dodopizza.by וכו').
תודה. שירות הרשאות ואימות ל-Back Office.
Трекер. הזמנת גשש במטבח. שירות לסימון סטטוסי מוכנות בעת הכנת הזמנה.
קופה של המסעדה. קבלת הזמנות במסעדה, ממשקי קופאיות.
יצוא. העלאת דוחות ב-1C להנהלת חשבונות.
הודעות וחשבוניות. פקודות קוליות במטבח (למשל "הגיעה פיצה חדשה") + הדפסת חשבוניות לשליחים.
מנהל משמרת. ממשקים לעבודת מנהל המשמרת: רשימת הזמנות, גרפי ביצוע, העברת עובדים למשמרת.
מנהל משרד. ממשקים לעבודת הזכיין והמנהל: קבלת עובדים, דוחות על עבודת הפיצרייה.
לוח תוצאות למסעדה. תצוגת תפריט בטלוויזיות בפיצריות.
אדמין. הגדרות בפיצריה ספציפית: תפריט, מחירים, הנהלת חשבונות, קודי פרומו, מבצעים, באנרים לאתר וכו'.
חשבון אישי של העובד. לוחות זמנים של עובדים, מידע על עובדים.
לוח מוטיבציה למטבח. מסך נפרד התלוי במטבח ומציג את המהירות של מכיני הפיצה.
תקשורת. שליחת sms ומייל.
אחסון קובץ. שירות משלו לקבלה והנפקה של קבצים סטטיים.

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

מתחילים לפרוק את המונולית: הפרדת אימות ומעקב

השירותים העיקריים שהקליטו וקראו ממסד הנתונים יותר מאחרים:

1. Auth. שירות הרשאות ואימות ל-Back Office.
2. גַשָׁשׁ. הזמנת גשש במטבח. שירות לסימון סטטוסי מוכנות בעת הכנת הזמנה.

מה Auth עושה?

Auth הוא שירות שבאמצעותו משתמשים נכנסים ל-Back Office (יש כניסה עצמאית נפרדת בצד הלקוח). כמו כן, נדרש בבקשה לוודא כי קיימות זכויות הגישה הנדרשות וכי זכויות אלו לא השתנו מאז הכניסה האחרונה. דרכו נכנסים מכשירים לפיצרייה.

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

מאיפה העומסים?

כל משתמש מחובר ב-Back Office עובר לבסיס הנתונים, לטבלת המשתמשים עבור כל בקשה, שולף את המשתמש דרך שאילתת sql ובודק אם יש לו את הגישה והזכויות הנדרשות לעמוד זה.

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

פריקת אישור

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

היה. תכנית העבודה המקורית הייתה כדלקמן:

אני רוצה להסביר קצת איך זה עבד:

1. בקשה מבחוץ מגיעה ל-backend (יש את Asp.Net MVC), מביאה איתה עוגיית הפעלה, המשמשת לקבלת נתוני הפעלה מ-Redis(1). או שהוא מכיל מידע על גישה, ואז הגישה לבקר פתוחה (3,4), או לא.
2. אם אין גישה, עליך לעבור את הליך ההרשאה. כאן, לשם הפשטות, הוא מוצג כחלק מהנתיב באותה תכונה, למרות שזהו מעבר לדף הכניסה. במקרה של תרחיש חיובי, נקבל סשן שהושלם כהלכה ונעבור ל-Backoffice Controller.
3. אם יש נתונים, אז אתה צריך לבדוק את הרלוונטיות שלהם במסד הנתונים של המשתמש. האם התפקיד שלו השתנה, האם אסור לאפשר לו להיכנס לדף עכשיו? במקרה זה, לאחר קבלת הפגישה (1), עליך לעבור ישירות למסד הנתונים ולבדוק את גישת המשתמש באמצעות שכבת הלוגיקה של האימות (2). לאחר מכן, אל דף הכניסה, או עבור אל הבקר. מערכת כל כך פשוטה, אבל לא ממש סטנדרטית.
4. אם כל ההליכים עוברים, אז אנחנו מדלגים הלאה בלוגיקה בבקרים ובשיטות.

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

הפכו. אז הם עשו:

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

שירות האימות ואיתו שירות המכשירים משמשים ל-Back Office, כלומר לשירותים וממשקים המשמשים בייצור. אימות עבור שירותי לקוח (כמו אתר אינטרנט או אפליקציה לנייד) מתבצע בנפרד ללא שימוש ב-Auth. ההפרדה ארכה כשנה, וכעת אנו שוב עוסקים בנושא זה, מעבירים את המערכת לשירותי אימות חדשים (עם פרוטוקולים סטנדרטיים).

למה הפרידה ארכה כל כך הרבה זמן?
היו הרבה בעיות בדרך שהאטו אותנו:

1. רצינו להעביר נתוני משתמשים, מכשיר ואימות ממסד נתונים ספציפיים למדינה לאחד. לשם כך, היינו צריכים לתרגם את כל הטבלאות והשימוש ממזהה int למזהה UUId הגלובלי (עיבד לאחרונה את הקוד הזה רומן בוקין "Uuid - סיפור גדול של מבנה קטן" ופרויקט קוד פתוח פרימיטיבים). לאחסון נתוני משתמש (מכיוון שמדובר במידע אישי) יש מגבלות ולגבי מדינות מסוימות יש צורך לאחסן אותם בנפרד. אבל המזהה הגלובלי של המשתמש חייב להיות.
2. בטבלאות רבות במסד הנתונים יש מידע ביקורת על המשתמש שביצע את הפעולה. זה הצריך מנגנון נוסף לעקביות.
3. לאחר יצירת שירותי ה-API חלה תקופה ארוכה והדרגתית של מעבר למערכת אחרת. המעבר היה צריך להיות חלק עבור המשתמשים והצריך עבודה ידנית.

ערכת רישום מכשיר בפיצריה:

ארכיטקטורה כללית לאחר חילוץ שירות אימות והתקנים:

שים לב. לקראת 2020, אנו עובדים על גרסה חדשה של Auth, המבוססת על תקן ההרשאה OAuth 2.0. תקן זה מורכב למדי, אך הוא שימושי לפיתוח שירות אימות מעבר. במאמר "דקויות ההרשאה: סקירה כללית של טכנולוגיית OAuth 2.0» אנחנו אלכסיי צ'רניייב ניסינו לספר על התקן בצורה פשוטה וברורה ככל האפשר כדי שתחסוך זמן בלימודו.

מה עושה Tracker?

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

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

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

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

כך נראה מסך הטאבלט בתחנת הגשש "רסקטקה"

מאיפה העומסים?

בכל אחת מהפיצריות יש כחמישה טבליות עם גשש. ב-2016 היו לנו יותר מ-100 פיצריות (ועכשיו יותר מ-600). כל אחד מהטאבלטים מגיש בקשה ל-backend אחת ל-10 שניות ומגרד נתונים מטבלת ההזמנות (חיבור עם הלקוח והכתובת), הרכב ההזמנה (חיבור למוצר וציון הכמות), טבלת חשבונאות המוטיבציה (ה זמן הלחיצה עוקב בו). כאשר יצרן פיצה לוחץ על מוצר במעקב, הערכים בכל הטבלאות הללו מתעדכנות. טבלת ההזמנות היא כללית, היא מכילה גם תוספות בעת קבלת הזמנה, עדכונים מחלקים אחרים במערכת וקריאות רבות, למשל, בטלוויזיה התלויה בפיצריה ומציגה הזמנות גמורות ללקוחות.

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

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

היה. הארכיטקטורה המקורית הייתה:

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

Tracker פריקה

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

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

הסכימה לשינוי סטטוסי הזמנה נראית כך:

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

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

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

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

סדר נתיב צעד אחר צעד
נתיב ההזמנה מתחיל באחד משירותי מקור ההזמנה. הנה הקופאית של המסעדה:

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

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

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

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

ארכיטקטורה סופית לאחר שינויים ב-Auth ו- Tracker

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

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

אני מקווה שהיה שימושי ומעניין עבורך ללמוד על הדרך שלנו. כעת אני עומד בפני בחירה איזה חלק ממערכת Dodo IS לתאר במאמר הבא: לכתוב בתגובות או להצביע.

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

על איזה חלק ב-Dodo IS תרצה לדעת במאמר הבא?

• 24,1%מונוליט מוקדם ב-Dodo IS (2011-2015)14

• 24,1%בעיות ראשונות ופתרונותיהן (2015-2016)14

• 20,7%השביל בצד הלקוח: חזית מעל בסיס (2016-2017)12

• 36,2%ההיסטוריה של שירותי מיקרו אמיתיים (2018-2019)21

• 44,8%ניסור מלא של המונוליט וייצוב הארכיטקטורה26

• 29,3%על תוכניות נוספות לפיתוח המערכת17

• 19,0%אני לא רוצה לדעת שום דבר על Dodo IS11

58 משתמשים הצביעו. 6 משתמשים נמנעו.

מקור: www.habr.com