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

שלום עמיתים.

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

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

תמונת בזק אייזק סמית' מ- Unsplash

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

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

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

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

הגדר את הרמה הראשונית

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

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

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

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

בניית ידע על אחסון ואחזור נתונים

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

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

תמונת בזק סמואל זלר מ- Unsplash

לאחר שתהיה לך הבנה מספקת של דפוסי אחסון הנתונים השונים, המשך ללימוד עקביות וזמינות הנתונים. קודם כל, אתה צריך להבין משפט CAP לפחות במונחים כלליים, ולאחר מכן לטש את הידע הזה על ידי הסתכלות מקרוב על דפוסים מבוססים עֲקֵבִיוּת и נְגִישׁוּת. כך תפתחו הבנה בתחום ותבינו שקריאה וכתיבה של נתונים הם למעשה שתי בעיות שונות מאוד, שלכל אחת יש אתגרים ייחודיים משלה. חמוש בכמה דפוסי עקביות וזמינות, אתה יכול להגדיל משמעותית את ביצועי המערכת תוך הבטחת זרימת נתונים חלקה ליישומים שלך.

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

דפוסי תקשורת

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

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

תמונת בזק טוני סטודארד מ- Unsplash

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

הפצת חיבורים

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

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

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

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

כדאי גם לדעת על רשתות להעברת תוכן (CDN). CDN הוא רשת גלובלית מבוזרת של שרתי פרוקסי המספקת מידע מצמתים הממוקמים גיאוגרפית קרובים יותר למשתמש ספציפי. עדיף להשתמש ב-CDN אם אתה עובד עם קבצים סטטיים שנכתבו ב-JavaScript, CSS ו-HTML. בנוסף, שירותי ענן המספקים מנהלי תעבורה נפוצים כיום, למשל, Azure Traffic Manager, נותן לך הפצה גלובלית והשהייה מופחתת בעת עבודה עם תוכן דינמי. עם זאת, שירותים כאלה הם בדרך כלל שימושיים במקרים שבהם אתה צריך לעבוד עם שירותי אינטרנט חסרי מדינה.

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

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

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

• עקרונות מוצקים
• מושגים עיצוב מונחה דומייןבפרט אגרגטים, צוותים ואירועים
• ארכיטקטורה משושה
• הפרדת תחומי אחריות לפקודות ובקשות (CQRS)
• הרשמה לאירוע
• דוגמן שחקן
• דפוסי עיצוב MVC, MVVM ו-MVP

גישות שיתופיות

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

תמונת בזק קליידיקו מ- Unsplash

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

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

מקור: www.habr.com