בחירת סגנון אדריכלי (חלק 1)

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

מבוא

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

קצת היסטוריה

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

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

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

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

מונולית

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

גודל

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

מחוברות

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

פְּרִיסָה

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

מדרגיות

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

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

אמינות

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

אִינֶרצִיָה

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

מסקנה

בפעם הבאה נדבר על איך אנשים ניסו לפתור את הבעיות הללו על ידי מעבר לרכיבים ו-SOA.

קרא עוד:

• מדוע SQL Server אינו מבטיח למיין תוצאות ללא ORDER BY
• ארכיטקטורה למפתחים ומנהלים: מי צריך אילו כישורים?

מקור: www.habr.com