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

או שכל חברה אומללה עם מונוליט אומללה בדרכה.

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

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

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

1. מונוליט מוקדם ב-Dodo IS (2011-2015). (אתה כאן)

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

3. שביל צד הלקוח: חזית מעל הבסיס (2016-2017). (בתהליך...)

4. ההיסטוריה של שירותי מיקרו אמיתיים. (2018-2019). (בתהליך...)

5. סיים ניסור של המונוליט וייצוב הארכיטקטורה. (בתהליך...)

ארכיטקטורה ראשונית

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

המודול הראשון בארכיטקטורה הוא קבלת הזמנות. התהליך העסקי היה:

• הלקוח מתקשר לפיצרייה;

• המנהל מרים טלפון;

• מקבל הזמנה בטלפון;

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

הממשק של מערכת המידע נראה בערך כך...

גרסה ראשונה מאוקטובר 2011:

שיפור קל בינואר 2012

דודו פיצה מערכת מידע משלוח מסעדת פיצה

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

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

• אחורי ב-ASP.NET MVC, שפת C#. המפתחים היו dotnetchiki, המחסנית הזו הייתה מוכרת ונעימה להם.

• Frontend על Bootstrap ו-JQuery: ממשקי משתמש על סגנונות ותסריטים שנכתבו בעצמם. 

• מסד נתונים MySQL: ללא עלויות רישיון, קל לשימוש.

• שרתים ב-Windows Server, מכיוון ש-.NET אז יכול להיות רק תחת Windows (לא נדון במונו).

פיזית, כל זה התבטא ב"הקדש אצל המארח". 

ארכיטקטורת יישומי כניסת הזמנה

אז כולם כבר דיברו על שירותי מיקרו, ו-SOA שימש בפרויקטים גדולים במשך 5 שנים, למשל, WCF שוחרר ב-2006. אבל אז הם בחרו בפתרון אמין ומוכח.

הנה זה.

Asp.Net MVC הוא Razor, אשר, לפי בקשה מטופס או מלקוח, מעבד דף HTML עם עיבוד שרת. בלקוח, סקריפטים של CSS ו-JS כבר מציגים מידע ובמידת הצורך, מבצעים בקשות AJAX דרך JQuery.

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

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

• ReceivingOrdersService קיבל וחישב את הרכב ההזמנה.

• ו-SmsService שלח SMS על ידי קריאה לשירותי API כדי לשלוח SMS.

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

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

כל זה יכול להיות מיוצג על ידי מודל כזה:

הזמנה דרך

שקול דרך ראשונית פשוטה ליצור סדר כזה.

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

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

• הלקוח נותן שמות למוצרים שהוא רוצה להוסיף להזמנה.

• נותן את כתובתו ושמו.

• המפעיל מקבל את ההזמנה.

• ההזמנה מוצגת בממשק ההזמנות המקובלות.

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

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

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

לאחר מכן, הזן את הכתובת ואת שם הלקוח. 

כאשר אתה לוחץ על "צור הזמנה":

• הבקשה נשלחת אל OrderController.SaveOrder().

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

• אנו משלימים את העגלה במידע על הלקוח ומעבירים אותו לשיטת AddOrder של מחלקת ReceivingOrderService, שם הוא נשמר במסד הנתונים. 

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

• ממשק תצוגת ההזמנות הולך ושולף את ההזמנות האחרונות ומציג אותן.

מודולים חדשים

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

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

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

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

...לתוך זה:

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

• אֲתַר - גרסה ראשונה אתר dodopizza.ru.

• יצוא: העלאת דוחות מ-Dodo IS עבור 1C. 

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

• fs - פרויקט לאירוח סטטי. מאוחר יותר התרחקנו ממנו, והעברנו את כל הסטטיות ל- Akamai CDN. 

שאר הבלוקים היו באפליקציית BackOffice. 

הסבר שם:

• קופאית - קופאית מסעדה.

• ShiftManager - ממשקים לתפקיד "מנהל משמרת": סטטיסטיקה תפעולית על מכירות פיצריה, יכולת הכנסת מוצרים לרשימת הסטופ, שינוי הסדר.

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

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

הם השתמשו בשכבת שירות משותפת, בלוק מחלקת דומיין משותף של Dodo.Core ובבסיס משותף. לפעמים הם עדיין יכלו להוביל לאורך המעברים זה לזה. כולל אתרים בודדים, כגון dodopizza.ru או personal.dodopizza.ru, עברו לשירותים כלליים.

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

להבנה טובה יותר של קנה המידה של המודולים שנעשו במערכת, הנה תרשים משנת 2012 עם תוכניות פיתוח:

עד 2015, הכל היה על המפה ואפילו יותר היה בהפקה.

• קבלת ההזמנות גדלה לבלוק נפרד של מרכז הקשר, שבו ההזמנה מתקבלת על ידי המפעיל.

• היו מסכים ציבוריים עם תפריטים ומידע תלויים בפיצריות.

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

• יחידת המסירה הפכה ל-Delivery Checkout נפרד, כאשר ההזמנה ניתנה לשליח שלקח בעבר את המשמרת. זמן עבודתו נלקח בחשבון לצורך חישוב השכר. 

במקביל, בשנים 2012 עד 2015 הופיעו למעלה מ-10 מפתחים, נפתחו 35 פיצריות, פרסו את המערכת לרומניה והתכוננו לפתיחת נקודות מכירה בארה"ב. המפתחים כבר לא עסקו בכל המשימות, אלא חולקו לצוותים. כל אחד מתמחה בחלק משלו של המערכת. 

בעיות

כולל בגלל הארכיטקטורה (אבל לא רק).

כאוס בבסיס

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

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

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

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

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

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

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

לכידות וערפול בקוד

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

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

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

ההיגיון היה או בבקרים או במחלקות השירות. 

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

המורכבות של פיתוח גדול

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

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

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

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

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

איך הבלוג Power of the Mind שם את הקופות במסעדות

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

בבלוג"כוח מחשבה” היה יישומון שהראה נתונים על הכנסות לשנה של כל הרשת. הווידג'ט ניגש ל-API הציבורי של Dodo, המספק נתונים אלה. נתון זה זמין כעת ב http://dodopizzastory.com/. הווידג'ט הוצג בכל עמוד ועשה בקשות בטיימר כל 20 שניות. הבקשה פנתה ל-api.dodopizza.ru וביקשה:

• מספר הפיצריות ברשת;

• סך הכנסות הרשת מתחילת השנה;

• הכנסות להיום.

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

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

התרשים נראה כך:

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

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

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

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

צמיחה עסקית מהירה

למה לא ניתן היה לעשות זאת מיד? פשוט תסתכל על התרשימים הבאים.

גם בשנים 2014-2015 הייתה פתיחה ברומניה והכנה בארה"ב.

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

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

פתרונות מהירים שעזרו

לבעיות נדרשו פתרונות. באופן קונבנציונלי, ניתן לחלק את הפתרונות ל-2 קבוצות:

• מהירים שמכבים את האש ונותנים מרווח ביטחון קטן וקונים לנו זמן לשנות.

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

הרשימה היבשה של שינויים מהירים היא כדלקמן:

הגדל את הבסיס המאסטר

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

מאז 2014 עברנו לתכלת, גם על הנושא הזה כתבנו באותה תקופה במאמר "כיצד Dodo Pizza מספק פיצה באמצעות Microsoft Azure Cloud". אבל אחרי סדרה של עליות בשרת עבור הבסיס, הם נתקלו בעלות. 

העתקים בסיסיים לקריאה

לבסיס נוצרו שני העתקים:

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

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

מטמון בקוד

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

מספר שרתי אחורי

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

כתוצאה מכך, הארכיטקטורה הפכה מסובכת יותר ...

... אבל חלק מהמתח הוסר.

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

מקור: www.habr.com