ארכיטקטורת שירות מיקרו: יתרונות וחסרונות

שירותי מיקרו הם דרך לפרק אפליקציה גדולה למודולים מחוברים באופן רופף המתקשרים זה עם זה באמצעות API פשוט. לאחרונה, רק אנשים מטומטמים לא דיברו על שירותי מיקרו. זה הופך יותר ויותר פופולרי. הסגנון האדריכלי המודולרי נראה מתאים במיוחד לסביבות מבוססות ענן והוא הולך וגדל בפופולריות. לפני שניכנס לפרטים, בואו נסתכל על הכל במבט ממעוף הציפור . לכן: שירותי מיקרו הם דרך לפרק פרויקט גדול למודולים קטנים, עצמאיים ומקושרים באופן רופף. מודולים עצמאיים אחראים למשימות מוגדרות בבירור ובדידות ומתקשרים זה עם זה באמצעות API פשוט ונגיש. במילים אחרות, שירותי מיקרו הם פשוט סגנון אדריכלי שונה לעיצוב יישומי אינטרנט מורכבים, בעיקר. אבל מה כל כך רע בפתרונות אדריכליים קיימים כגון SOA (ארכיטקטורה מכוונת שירות)? נראה שרוב הפתרונות הארגוניים המודרניים שנכתבו באמצעות SOA עובדים די טוב. זה עשוי להיות זמן מצוין לדבר על כמה מהאתגרים איתם מתמודד התעשייה בימים אלה... בואו נתחיל בדוגמה פשוטה. נניח שאני צריך להפעיל יישום קלאסי שנכתב ב-Java. תחילה אפתח את ה-User Interface, לאחר מכן את שכבת הלוגיקה העסקית, עם מספר רכיבים שיתקשרו עם ה-UI, ולבסוף את שכבת מסד הנתונים, שתהיה נגישה לבסיס הנתונים הקבוע. כעת לפי העובדה שאני רוצה להריץ את האפליקציה, אצור WAR/EAR/JAR ואעלה אותו על שרת (כגון JBoss, Tomcat או WebLogic). מכיוון שזה נעשה הכל באחד, אני מקבל אפליקציה מונוליטית, כלומר כל הרכיבים נמצאים במקום אחד... דוגמה בתמונה: סביר להניח שאתה כבר מכיר את הגישה הזו והשתמשת בה, אבל הרעיון הוא להשתמש בדוגמה זו כדי להראות אילו אתגרים יאלצו מפתחים להתמודד עם הפתרון הארכיטקטוני הזה. יישום מונוליטי: מאתגר אתגרים

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

יחד עם זאת, אנו מוכנים לשקול ולהבין את המשמעות של שירותי מיקרו, כלומר כיצד ניתן להשתמש בהם כדי לשחזר את הגמישות שאבדה עם סגנון ה-SOA. אלוהים Microservices להצלה אחד המאפיינים החשובים ביותר בכל פתרון אדריכלי הוא מדרגיות. בזמן שלמדתי מיקרו-שירותים בפעם הראשונה, ראיתי שהכל כל כך דומה לציטוטים מהספר "אמנות המדרגיות". זוהי התחלה מצוינת ומקום לדיון. ספר זה מגדיר את מה שנקרא "קוביית מדרגיות", המתאר מערכת מדרגיות תלת מימדית: כפי שניתן לראות, ציר ה-X מתאר "קנה מידה אופקי" (שראינו זמין גם עבור ארכיטקטורות מונוליטיות), ציר ה-Y מייצג קנה מידה במובן של הפרדת רכיבי שירות שונים . הרעיון של ציר Z מובן כאשר הנתונים מחולקים והאפליקציה שולחת בקשות בדיוק למקום שבו הנתונים נמצאים. כלומר, לא כולם נמצאים במקום אחד. הרעיון של ציר ה-Y הוא זה בו נתמקד ביתר פירוט. ציר זה מייצג פירוק פונקציונלי . באסטרטגיה זו, פונקציות שונות יכולות להיחשב כשירותים עצמאיים. לכן, על ידי הרכבה של האפליקציה כולה רק כשהכל נעשה, מפתחים יכולים להעלות שירותים בודדים ללא תלות זה בזה ולא לחכות שאחרים יסיימו לעבוד על המודולים שלהם. זה לא רק ישפר את זמן הפיתוח, אלא גם יציע את הגמישות לשנות ולחווט מחדש ללא צורך לדאוג לגבי שאר רכיבי האפליקציה. הבה נשווה את הדיאגרמה הזו עם התרשים המונוליטי הקודם: מיקרו-שירותים: יתרונות נראה כי היתרונות של מיקרו-שירותים מספיקים למדי כדי לשכנע מפתחים ארגוניים כמו Amazon, Netflix, Ebay להתחיל להשתמש בגישה זו. בניגוד ליישומים אדריכליים מונוליטיים, שירותי מיקרו:

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

Microservices: תכונות של הרכבה ווירטואליזציה כעת אנו מבינים מה הם Microservices. והיתרון הגדול ביותר הוא שהוא מותקן על ידי יותר מארכיון WAR/EAR/JAR אחד. אבל איך זה מותקן? הדרך הטובה ביותר להרכיב שירותי מיקרו בתוך מכולות. קונטיינר הוא מערכת הפעלה וירטואלית מוגדרת במלואה, עם מוגדרת הסביבה הדרושה, המסייעת לבודד את הגישה למשאבי מערכת החומרה עליה מותקן הקונטיינר. הפתרון המפורסם ביותר בשוק הוא כמובן Docker . מכונות וירטואליות מ-IaaS (תשתית כשירות) כמו AWS יכולות לעבוד מצוין גם להרכבת שירותי מיקרו, אבל ייתכן שמיקרו-שירותים קלים יחסית לא ישתמשו בכל המשאבים שנמצאים במכונה הוירטואלית, מה שיכול להפחית את רווחיות השימוש. אתה יכול גם להעלות את שירותי המיקרו שלך באמצעות חבילת OSGI (Open Service Gateway Initiative). במקרה זה, כל שירותי המיקרו יפעלו ב-JVM יחיד, אך הדבר כרוך בבעיות החלפה בין שליטה ובידוד. Microservices: חסרונות זה ש"זה הכל מגניב" ו"לא ראינו את זה קודם" לא אומר שאין חסרונות. להלן רשימה של תחומי כאב אפשריים שמביאה עמה ארכיטקטורת מיקרו-שירותים:

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

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