שלום, הבר. היום אני ממשיך בסדרת פרסומים שכתבתי במיוחד לתחילתו של זרם חדש של הקורס. .
מבוא
הבחירה בסגנון אדריכלי היא אחת ההחלטות הטכניות הבסיסיות בעת בניית מערכת מידע. בסדרת מאמרים זו, אני מציע לנתח את הסגנונות האדריכליים הפופולריים ביותר ליישומי בנייה ולענות על השאלה מתי איזה סגנון אדריכלי הוא העדיף ביותר. בתהליך ההצגה אנסה לשרטט שרשרת הגיונית שמסבירה את התפתחות סגנונות אדריכליים ממונוליטים למיקרו-שירותים.
В עסקנו במונוליט והגענו למסקנה שלמונוליט יש מספר בעיות: גודל, קישוריות, פריסה, מדרגיות, אמינות וקשיחות.
הפעם אני מציע לדבר על האפשרויות של ארגון מערכת כמכלול של מודולים/ספריות (ארכיטקטורה מוכוונת רכיבים) או שירותים (ארכיטקטורה מוכוונת שירות).
ארכיטקטורה מכוונת רכיבים
ארכיטקטורה מכוונת רכיבים כוללת ביצוע של מערכת כסט של רכיבים שניתן להשתמש בהם בפרויקטים נוכחיים ועתידיים כאחד. בעת פירוק מערכת לרכיבים, נלקחים בחשבון: יכולת השימוש החוזרת שלהם, ההחלפה שלהם, עצמאות הקשר, הרחבה, אנקפסולציה ועצמאות.
בשימוש נכון ברכיבים נפתרת בעיית "כדור הלכלוך הגדול" (גודל גדול + צימוד גבוה), והרכיבים עצמם יכולים לייצג גם יחידות הרכבה (מודולים, ספריות) וגם יחידות פריסה (שירותים). יחידות הפריסה לא תמיד ממפות לתהליך הפועל: לדוגמה, יישום אינטרנט ומסד נתונים נפרסים יחד.
לרוב, מונוליטים מפותחים כקבוצה של מודולים. גישה זו מובילה לפיתוח עצמאי, אך הבעיות של קנה מידה ופריסה עצמאיים, סובלנות תקלות ועצמאות מחסנית הטכנולוגיה הכוללת נותרות. לכן המודול הוא רכיב עצמאי בחלקו.
הבעיה הגדולה ביותר עם מונוליט כזה היא שהחלוקה למודולים היא הגיונית בלבד וניתן להפר אותה בקלות על ידי מפתחים. עשוי להופיע מודול ליבה, שהופך בהדרגה למזבלה, גרף התלות בין המודולים עשוי לגדול וכן הלאה. כדי למנוע בעיות כאלה, הפיתוח צריך להתבצע על ידי צוות מאוד בוגר, או בהנחיית "אדריכל" העוסק בבדיקת קוד במשרה מלאה ומכה את ידיהם של מפתחים שמפרים את המבנה הלוגי.
המונוליט ה"אידיאלי" הוא קבוצה של מודולים מופרדים לוגית, שכל אחד מהם מסתכל לתוך מסד הנתונים שלו.
ארכיטקטורה מוכוונת - שירות
אם המערכת אמורה להיות מאורגנת בצורה של מערך שירותים, אז אנחנו מדברים על ארכיטקטורה מוכוונת שירות. העקרונות שלו הם יכולת פעולה הדדית של יישומים ממוקדי משתמש, שימוש חוזר בשירותים עסקיים, עצמאות מחסנית טכנולוגית ואוטונומיה (התפתחות עצמאית, מדרגיות ופריסה).
ארכיטקטורה מוכוונת שירות (SOA = ארכיטקטורה מכוונת שירות) פותרת את כל הבעיות שזוהו של מונוליט: רק שירות אחד מושפע כאשר מתרחש שינוי, וממשק API מוגדר היטב תומך באנקפסולציה טובה של רכיבים.
אבל לא הכל כל כך חלק: SOA יוצר בעיות חדשות. שיחות מרחוק יקרות יותר משיחות מקומיות, וחלוקת אחריות בין רכיבים התייקרה משמעותית.
אגב, אפשרות של פריסה עצמאית היא מאפיין חשוב מאוד של השירות. אם יש לפרוס שירותים יחד או יתרה מכך, ברצף מסוים, אזי המערכת לא יכולה להיחשב מוכוונת שירות. במקרה זה, הם מדברים על מונוליט מבוזר (נחשב לאנטי-דפוס לא רק מנקודת המבט של SOA, אלא גם מנקודת המבט של ארכיטקטורת מיקרו-שירותים).
ארכיטקטורה מוכוונת שירות נתמכת היטב על ידי קהילת האדריכלים והספקים. זה מרמז על נוכחות של קורסים והסמכות רבים, דפוסים מפותחים היטב. האחרון כולל, למשל, את אפיק השירות הארגוני הידוע (ESB = אפיק שירות ארגוני). יחד עם זאת, ESB הוא מטען של ספקים; זה לא בהכרח חייב לשמש ב-SOA.
הפופולריות של ארכיטקטורה מוכוונת שירות הגיעה לשיא בסביבות 2008, ולאחר מכן היא החלה לרדת, שהפכה דרמטית משמעותית לאחר הופעת שירותי המיקרו (~2015).
מסקנה
לאחר שדנו באפשרויות של ארגון מערכות מידע בצורה של שירותים ומודולים, אני מציע לעבור סוף סוף לעקרונות של ארכיטקטורת מיקרו-שירותים ולהקדיש תשומת לב מיוחדת להבדל בין ארכיטקטורת מיקרו-שירותים לארכיטקטורה מוכוונת שירותים בחלק הבא.
מקור: www.habr.com