מהם מיקרו-שירותים? ארכיטקטורת התוכנה הבאה שלך

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

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

מהם מיקרו-שירותים?

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

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

אדריכלות מיקרו-שירותים לעומת אדריכלות מונוליטית

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

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

מושגים מוגבלים: כיצד להגדיר מיקרו-שירות

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

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

מיקרו-שירותים לעומת ארכיטקטורה מכוונת שירות לעומת שירותי אינטרנט

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

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

תקשורת מיקרו-שירותים

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

באופן כללי, התקשורת בין מיקרו-שירותים צריכה להיות א-סינכרונית , במובן זה ששרשורי הקוד אינם חסומים בהמתנה לתגובות. (עדיין עדיף להשתמש בפרוטוקולי תקשורת סינכרוניים כגון HTTP, אם כי פרוטוקולים אסינכרוניים כגון AMQP (Advanced Message Queuing Protocol) נפוצים גם בארכיטקטורות המיקרו-שירותים.) סוג זה של צימוד רופף הופך את ארכיטקטורת המיקרו-שירותים לגמישה יותר לנוכח הכישלון. של רכיבים או חלקים נפרדים ברשת, המהווה יתרון מרכזי.

שירותי מיקרו, Java ו- Boot Boot ו- Cloud Cloud

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

כתוצאה מהיסטוריה זו, ישנן מסגרות Java רבות המאפשרות לך לבנות מיקרו-שירותים. אחד הפופולריים ביותר הוא Spring Boot, אשר תוכנן במיוחד עבור שירותי מיקרו; אתחול מורחב על ידי Spring Cloud, שכשמו כן הוא, מאפשר לך לפרוס גם את השירותים האלה לענן. ל- Pivotal Software, מפתחת Spring, יש הדרכה טובה בנושא פיתוח מיקרו-שירות באמצעות מסגרות אלה.

שירותי מיקרו ושירותים: Docker, Kubernetes, ועוד

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

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

אביב, למרות שהוא פופולרי, קשור לפלטפורמת Java. לעומת זאת, מערכות מבוססות מיכל הן מצולעות: כל שפת תכנות שתומכת מערכת ההפעלה יכולה להריץ במיכל, מה שמעניק יותר גמישות למתכנתים. ואכן, יתרון גדול של שירותי המיקרו הוא שבכל שירות ניתן לכתוב בכל שפה שהכי הגיונית או שמפתחים הכי מרגישים בנוח איתה. ואכן, ניתן לבנות מחדש שירות בשפה חדשה מבלי להשפיע על המערכת כולה, כל עוד ממשקי ה- API שלו נשארים יציבים. ל- DZone יש מאמר הדן בעניין היתרונות והחסרונות של Spring Cloud לעומת Kubernetes למיקרו-שירותים. 

דפוסי עיצוב מיקרו-שירותים

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

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

שירותי מיקרו וענן : AWS ותכלת

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