היי הבר!

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

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

קנה מידה אופקי

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

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

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

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

CQRS

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

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

1. הלקוח שלח בקשה לשרת.
2. השרת התחיל זמן עיבוד ארוך.
3. השרת הגיב ללקוח עם התוצאה.

בואו נדמיין שבנקודה 2 החיבור נשבר (או שהרשת התחברה מחדש, או שהמשתמש הלך לדף אחר, ניתק את החיבור). במקרה זה, יהיה קשה לשרת לשלוח תגובה למשתמש עם מידע על מה בדיוק עובד. באמצעות CQRS, הרצף יהיה מעט שונה:

1. הלקוח נרשם לעדכונים.
2. הלקוח שלח בקשה לשרת.
3. השרת הגיב "הבקשה התקבלה".
4. השרת הגיב עם התוצאה דרך הערוץ מנקודה "1".

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

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

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

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

מקורות אירועים

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

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

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

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

תכונות חשובות של גישה זו:

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

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

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

ועבור שני משתמשים הדיאגרמה תיראה כך (שירותים המיועדים למשתמשים שונים מסומנים בצבעים שונים):

בונוסים משילוב כזה:

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

עם זאת, החסרונות נראים מיד:

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

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

כתוצאה:

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

Sharding

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

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

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

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

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

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

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

אירוח תוכן סטטי

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

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

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

• השרת מספק כתובת URL להורדה. זה יכול להיות בצורת file_id + key, כאשר מפתח הוא חתימה מיני-דיגיטלית המעניקה את הזכות לגשת למשאב במשך XNUMX השעות הקרובות.
• הקובץ מופץ על ידי nginx פשוט עם האפשרויות הבאות:
  • שמירת תוכן במטמון. היות ושירות זה יכול להיות ממוקם בשרת נפרד, השארנו לעצמנו עתודה לעתיד עם היכולת לאחסן את כל הקבצים האחרונים שהורדת בדיסק.
  • בדיקת המפתח בזמן יצירת החיבור
• אופציונלי: עיבוד תוכן בסטרימינג. לדוגמה, אם אנו דוחסים את כל הקבצים בשירות, אז נוכל לבצע unzipping ישירות במודול זה. כתוצאה מכך: פעולות IO נעשות היכן שהן שייכות. ארכיון ב-Java יקצה בקלות הרבה זיכרון נוסף, אבל שכתוב שירות עם היגיון עסקי לתנאי Rust/C++ עשוי להיות גם לא יעיל. במקרה שלנו, נעשה שימוש בתהליכים שונים (או אפילו שירותים), ולכן אנו יכולים להפריד בצורה יעילה למדי בין לוגיקה עסקית ופעולות IO.

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

כדוגמה נוספת (לחיזוק): אם עבדת עם Jenkins/TeamCity, אז אתה יודע ששני הפתרונות כתובים ב-Java. שניהם הם תהליך ג'אווה שמטפל גם בתזמור בנייה וגם בניהול תוכן. בפרט, לשניהם יש משימות כמו "העברת קובץ/תיקיה מהשרת." כדוגמה: הנפקת חפצים, העברת קוד מקור (כשהסוכן לא מוריד את הקוד ישירות מהמאגר, אלא השרת עושה זאת עבורו), גישה ללוגים. כל המשימות הללו שונות בעומס ה-IO שלהן. כלומר, מסתבר שהשרת האחראי על ההיגיון העסקי המורכב חייב במקביל להיות מסוגל לדחוף ביעילות זרימות גדולות של נתונים דרכו. ומה שהכי מעניין זה שאפשר להאציל פעולה כזו לאותו nginx בדיוק לפי אותה סכמה (חוץ מזה שצריך להוסיף את מפתח הנתונים לבקשה).

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

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

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

מסקנה

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

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

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

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

מקור: www.habr.com