מונוליטים ומיקרו-שירותים הם שתי גישות בסיסיות לבניית יישומים. יש אנשים הרואים בהם מורשת ומודרנית, בהתאמה. אבל זה לא ממש נכון. הבחירה ביניהם היא שאלה מורכבת מאוד, שלשניהם יש יתרונות וחסרונות. רוב היישומים החדשים אינם צריכים להיות מיקרו-שירותים מההתחלה. זה מהיר יותר, קל יותר וזול יותר להתחיל כמונוליט ולעבור למיקרו-שירותים מאוחר יותר אם אתה מוצא את זה מועיל. עם הזמן, ככל שיישומי מונוליט הופכים פחות ופחות ניתנים לתחזוקה, חלק מהצוותים מחליטים שהדרך היחידה לפתור את הבעיה היא להתחיל לשחזר את האפליקציה שלהם לשירותי מיקרו. צוותים אחרים מקבלים את ההחלטה הזו רק בגלל ש"שירותי מיקרו הם מגניבים". תהליך זה לוקח הרבה זמן ולפעמים מביא אפילו יותר הוצאות תחזוקה. לפני שנכנסים לזה, חיוני לשקול היטב את כל היתרונות והחסרונות ולהבטיח שהגעת למגבלות הארכיטקטורה המונוליטית הנוכחית שלך. וזכרו, קל יותר לשבור מאשר לבנות. במאמר זה, אנחנו לא הולכים להשוות מונוליטים למיקרו-שירותים. במקום זאת, נדון בשיקולים, דפוסים ועקרונות שיעזרו לך: השג את המיטב מהמונוליט הנוכחי שלך ואפשר להכין אותו לפריצה לשירותי מיקרו; לספק העברה חלקה ממונוליט לשירותי מיקרו; להבין מה עוד עשוי להשתנות עם העברת שירותי מיקרו. מונוליט מודולרי הדבר הראשון שעליך לעשות הוא להסתכל על מבנה הפרויקט שלך. אם אין לך מודולים, אני ממליץ לך לשקול אותם. הם לא גורמים לך לשנות את הארכיטקטורה שלך למיקרו-שירותים (וזה טוב כי אנחנו רוצים להימנע מכל התחזוקה המתאימה) אלא לוקחים מהם יתרונות רבים. בהתאם לכלי האוטומציה של בניית הפרויקט שלך (למשל, maven, gradle או אחר), אתה יכול לפצל את הפרויקט שלך למודולים נפרדים ועצמאיים. מודולים מסוימים עשויים להיות משותפים לאחרים, בעוד שאחרים עשויים להכיל אזורי תחום ספציפיים או להיות ספציפיים לתכונה, ומביאים פונקציונליות עצמאית ליישום שלך. זה ייתן לך את היתרונות הבאים: חלקים מנותקים מהאפליקציה שלך. ניתן לפתח תכונות באופן עצמאי, תוך מזעור קונפליקטים. הרבה יותר קל להרכיב אנשים חדשים מכיוון שהם לא צריכים לצלול עמוק לתוך הפרויקט כולו; במקום זאת, הם יכולים להתחיל מחלקים מבודדים. בדיקות משופרות, כי עכשיו אתה יכול לבדוק כל מודול בנפרד. אם אתה צריך לעבור למיקרו-שירותים בסופו של דבר, יש לך בסיס חזק מאוד לכך. כפי שאתה רואה, המונוליט המודולרי הוא הדרך להפיק את המיטב משני העולמות. זה כמו להפעיל מיקרו-שירותים עצמאיים בתוך מונוליט בודד, אך הימנעות משירותי מיקרו בטחונות תקורה. אחת המגבלות שעלולות להיות לך - היא אי היכולת לשנות את קנה המידה של מודולים שונים באופן עצמאי. יהיו לך מופעי מונוליט רבים ככל הנדרש על ידי המודול הטעון ביותר, מה שעלול להוביל לצריכת משאבים מוגזמת. החיסרון הנוסף הוא המגבלות של שימוש בטכנולוגיות שונות. לדוגמה, אתה לא יכול לערבב Java, Golang ו-Python במונוליט מודולרי, אז אתה נאלץ להישאר עם טכנולוגיה אחת (שבדרך כלל, לא מהווה בעיה). דפוס תאנה החונקת תחשוב על דפוס תאנה חנוק. הוא לוקח את שמו מעץ שעוטף ובסופו של דבר מחליף את המארח שלו. באופן דומה, הדפוס מציע להחליף חלקים מאפליקציה מדור קודם בשירותים חדשים בזה אחר זה, ולחדש מערכת ישנה מבלי לגרום לשיבושים משמעותיים. במקום לנסות שיפוץ מסוכן, הכל בבת אחת, אתה מעדכן את המערכת חלק אחר חלק. שיטה זו מועילה כאשר מתמודדים עם מונוליטים גדולים ומורכבים שקשה להחליפם במאמץ אחד. על ידי אימוץ דפוס Strangler Fig, צוותים יכולים לבטל לאט את המערכת הישנה תוך טיפוח הצמיחה של המערכת החדשה, מזעור סיכונים והבטחת אספקת ערך מתמשכת. כדי ליישם את דפוס התאנה החונקת, עליך לבצע שלושה שלבים: כאן, אתה מזהה איזה חלק לחלץ מהמונוליט וליישם אותו כשירות מיקרו נפרד. שכתב את החלק הזה באמצעות טכנולוגיות מודרניות וטפל בבעיות של היישום הקודם. נצל את ההזדמנות שלך לעשות את זה טוב יותר. לְשַׁנוֹת. כאשר מיקרו-שירות חדש מוכן לייצור, אתה מפעיל אותו בתשתית שלך, תוך שמירה על היישום מדור קודם. אתה מפיץ תנועה בפרופורציה מסוימת, מעביר בהדרגה יותר ויותר תנועה למימוש החדש, אבל תמיד יש לך את הגרסה הקודמת שלך כחזרה. לְהִתְקַיֵם יַחַד. לאחר זמן מה, כאשר אתה מאמין שהמיקרו-שירות החדש שלך אמין מספיק, העבר את כל התעבורה אל המיקרו-שירות החדש והסר את המורשת. לְחַסֵל. אם תנקוט בשלושת השלבים האלה, תפרק בהדרגה מונוליט לשירותי מיקרו. היתרונות העיקריים של השימוש בתבנית Strangler Fig הם: במקום לשבור רע ולהתחיל שיפוץ מערכת מלא בזמן, סוחף ומסוכן, הדפוס מאפשר לך לעבור צעד אחר צעד. אתה יכול לאט לאט לעדכן את המערכת שלך ולסנכרן את השינוי הזה עם תוכניות פיתוח תכונות. לדוגמה, אתה יכול למצוא חלק מהמונוליט שפיתוח תכונות מסוים ישפיע ברצינות ולבחור בו כמועמד להגירה של שירותים מיקרוניים. הגירה הדרגתית. היתרון הזה נובע מההצהרה הקודמת. תהליך המודרניזציה אינו חוסם את הצוות שלך מלספק תכונות חדשות ללא הרף. בעוד שצוות אחד מפתח תכונות חדשות, אחר מחזיר מודולים עצמאיים. משלוח רציף. דפוס Strangler Fig עוזר לצוות להתמקד במודרניזציה של חלקים ספציפיים של המערכת. מיקוד זה מאפשר לצוות להקדיש תשומת לב רבה יותר לפרטים באזורים ספציפיים, למצוא בעיות פוטנציאליות מוקדם יותר ולמזער את ההשפעה הכוללת על האפליקציה. הפחתת סיכונים. סוגיות ושיקולים בעת יישום דפוס Strangler Fig, עליך לתכנן את אסטרטגיית ההגירה בקפידה. זה כולל זיהוי אילו רכיבים להחליף תחילה, הבטחת אינטגרציה נכונה בין חלקים ישנים לחדשים ושמירה על מודלים עקביים של נתונים. הצוותים צריכים גם להקים ערוצי תקשורת ברורים ומערכות ניטור כדי לעקוב אחר ההתקדמות וההשפעה של כל החלפה. השלכות הגירה של שירותי מיקרו כפי שדיברנו קודם, המעבר לשירותי מיקרו מביא יתרונות. עם זאת, זה גם הופך דברים רבים אחרים לקשים ויקרים יותר. לדוגמה, צוותי QA ו-Dev עשויים להתמודד עם מצב שבו הם לא יכולים עוד לבדוק במכונות מקומיות מכיוון שהיכולת להפעיל מספר שירותי מיקרו באופן מקומי מוגבלת. לחלופין, היומנים שלך עשויים להיות פחות חכמים מכיוון שבמקום ששירות אחד יעבד זרימה אחת, מספר שירותים מעבדים אותו כעת. כתוצאה מכך, כדי להציג את רצף היומן המלא, עליך ליישם מכשור ומעקב מתאימים. בואו נדון בכמה היבטים מכריעים שכדאי לכם לשקול ואולי לתכנן לפני שהשינוי בשירותי המיקרו שלכם מתחיל. פריסה ותשתיות לשירותי מונולית ומיקרו יש דרישות תשתית מינימליות שונות. בעת הפעלת יישום מונוליט, אתה יכול בדרך כלל לשמור על תשתית פשוטה יותר. אפשרויות כמו מכונות וירטואליות או פתרונות PaaS (כגון AWS EC2) יספיקו. כמו כן, אתה יכול להתמודד עם חלק גדול מהקנה המידה, התצורה, השדרוגים והניטור באופן ידני או עם כלים פשוטים. כתוצאה מכך, אתה יכול להימנע מהגדרות תשתית מורכבות ולהסתמך על מפתחים או מהנדסי תמיכה מבלי לדרוש מומחיות נרחבת ב-DevOps. עם זאת, אימוץ ארכיטקטורת שירותי מיקרו משנה את הדינמיקה הזו. ככל שמספר השירותים גדל, גישה ידנית ומעשית הופכת במהירות ללא מעשית. כדי לתזמר, להרחיב ולנהל ביעילות מספר שירותים, תזדקק לפלטפורמות מיוחדות כמו Kubernetes או, לפחות, שירות קונטיינר מנוהל, המציג שכבה חדשה של מורכבות ודרישות תפעוליות. שכבת פלטפורמה תחזוקה של יישום מונוליט היא פשוטה יחסית. אם מתעורר CVE, אתה מעדכן את התלות המושפעת במקום אחד. צריכים לתקנן תקשורת שירות חיצונית? הטמעו מעטפת יחידה והשתמשו בה מחדש בכל בסיס הקוד. בסביבת שירותי מיקרו, המשימות הפשוטות הללו הופכות למורכבות הרבה יותר. מה שהיה קודם טריוויאלי כרוך כעת בתיאום שינויים על פני מספר שירותים עצמאיים, כל אחד עם מחזור החיים והתלות שלו. המורכבות הנוספת מגדילה עלויות הן בזמן והן במשאבים. והמצב מחמיר כשיש לך צוותים רבים והרבה שירותים שונים. לכן, ארגונים רבים מציגים שכבת פלטפורמה ייעודית, המנוהלת בדרך כלל על ידי צוות פלטפורמה. המטרה היא ליצור בסיס שכל שירותי המיקרו יכולים לרשת: ניהול תלות נפוצה, הטמעת דפוסים סטנדרטיים ואספקת עטיפות מוכנות. על ידי איחוד אלמנטים אלה ברמת הפלטפורמה, אתה מפשט משמעותית את התחזוקה ומטפח עקביות בכל המערכת. מַסְקָנָה פריצת מונוליט למיקרו-שירותים היא טרנספורמציה אדריכלית משמעותית הדורשת שיקול דעת ותכנון מדוקדקים. במאמר זה, דנו בצעדים שתוכל לנקוט כדי להתכונן אליו ולעבור את התהליך בצורה חלקה. היצמדות לתבנית Strangler Fig תספק לך את התהליך המצטבר ותבטיח יציבות מערכת לאורך כל השינוי. כמו כן, המונוליט המודולרי לא רק יכול להוות שלב הכנה מועיל אלא גם יכול להביא יתרונות שעשויים לעורר אותך לשקול מחדש את החלטת הטרנספורמציה של המיקרו-שירותים שלך ולהימנע ממורכבות תפעולית מתאימה.
