אדריכלות מיקרו-שירות:
משלי , בטח קיבלת הבנה בסיסית באדריכלות מיקרו-שירותים.אבל, להיות מקצועי עם ידרוש לא רק את היסודות. בבלוג זה תוכלו להיכנס לעומק המושגים האדריכליים וליישם באמצעות מחקר מקרה של UBER.
איך להכין אינטל כפול בג'אווה
בבלוג זה תוכלו ללמוד על הדברים הבאים:
- הגדרה של אדריכלות מיקרו-שירותים
- מושגי מפתח של אדריכלות מיקרו-שירותים
- יתרונות וחסרונות של אדריכלות מיקרו-שירותים
- UBER - מחקר מקרה
אתה יכול להתייחס ל , כדי להבין את היסודות והיתרונות של מיקרו-שירותים.
זה יהיה הוגן רק אם אתן לך את ההגדרה מיקרו-שירותים.
הגדרת שירותי מיקרו
ככזה, אין הגדרה נכונה של Microservices המכונה Microservice Architecture, אך ניתן לומר שזו מסגרת המורכבת משירותים קטנים, הניתנים לפריסה בנפרד, המבצעים פעולות שונות.
שירותי המיקרו מתמקדים בתחום עסקי אחד שניתן ליישם כשירותים פריסה עצמאיים לחלוטין ולהטמיע אותם על ערימות טכנולוגיה שונות.
איור 1: ההבדל בין אדריכלות מונוליטית למיקרו-שירותים - אדריכלות מיקרו-שירותים
עיין בתרשים לעיל כדי להבין את ההבדל בין ארכיטקטורה מונוליטית למיקרו-שירותים.להבנה טובה יותר של ההבדלים בין שני הארכיטקטורות, תוכלו לעיין בבלוג הקודם שלי
כדי לגרום לך להבין טוב יותר, הרשה לי לספר לך כמה מושגי מפתח בארכיטקטורת מיקרו-שירותים.
מושגי מפתח של אדריכלות מיקרו-שירותים
לפני שתתחיל לבנות יישומים משלך באמצעות מיקרו-שירותים עליך להיות ברור לגבי היקף הפונקציות והפונקציות של היישום שלך.
להלן כמה הנחיות שיש לעקוב אחריהן בעת דיון במיקרו-שירותים.
הנחיות בעת תכנון שירותי מיקרו
- כמפתח, כאשר אתה מחליט לבנות יישום להפריד בין התחומים ולהיות ברור עם הפונקציות.
- כל שירות מיקרו שתעצב יתרכז רק בשירות אחד של היישום.
- וודא שתכננת את היישום באופן שכל שירות ניתן לפרוס בנפרד.
- וודא כי התקשורת בין מיקרו-שירותים נעשית באמצעות שרת חסר מדינה.
- ניתן לקדם מחדש כל שירות לשירותים קטנים יותר, עם שירותים מיקרו משלהם.
כעת, לאחר שקראת את ההנחיות הבסיסיות בעת תכנון מיקרו-שירותים, בואו נבין את הארכיטקטורה של מיקרו-שירותים.
כיצד עובדת אדריכלות מיקרו-שירות?
ארכיטקטורת מיקרו-שירות טיפוסית (MSA) צריכה להיות מורכבת מהרכיבים הבאים:
- לקוחות
- ספקי זהות
- ממשק API של Gateway
- פורמטים להעברת הודעות
- מאגרי מידע
- תוכן סטטי
- הַנהָלָה
- גילוי שירות
עיין בתרשים להלן.
איור 2: אדריכלות מיקרו-שירותים - אדריכלות מיקרו-שירותים
אני יודע שהארכיטקטורה נראית מעט מורכבת, אבל תןאנילפשט את זה בשבילך.
1. לקוחות
הארכיטקטורה מתחילה בסוגים שונים של לקוחות, ממכשירים שונים שמנסים לבצע יכולות ניהול שונות כגון חיפוש, בנייה, תצורה וכו '.
2. ספקי זהות
בקשות אלה מהלקוחות מועברות לאחר מכן לספקי הזהות המאמתים את בקשות הלקוחות ומתקשרים לבקשות ל- API Gateway. הבקשות מועברות לאחר מכן לשירותים הפנימיים באמצעות שער API מוגדר היטב.
3. שער ה- API
מכיוון שלקוחות לא מתקשרים ישירות לשירותים, API Gateway משמש כנקודת כניסה עבור הלקוחות להעברת בקשות למיקרו-שירותים מתאימים.
היתרונות בשימוש בשער API כוללים:
- ניתן לעדכן את כל השירותים מבלי שהלקוחות ידעו.
- השירותים יכולים גם להשתמש בפרוטוקולי העברת הודעות שאינם ידידותיים לאינטרנט.
- שער ה- API יכול לבצע פונקציות רוחביות כגון מתן אבטחה, איזון עומסים וכו '.
לאחר קבלת בקשות הלקוחות, הארכיטקטורה הפנימית מורכבת ממיקרו-שירותים המתקשרים זה עם זה באמצעות הודעות לטיפול בבקשות הלקוח.
4. פורמטים להעברת הודעות
ישנם שני סוגים של הודעות שדרכם הם מתקשרים:
- הודעות סינכרוניות: במצב שלקוחות ממתינים לתגובות משירות, מיקרו-שירותים בדרך כלל נוטים להשתמש REST (העברת מדינה ייצוגית) מכיוון שהוא מסתמך על שרת לקוח חסר מדינה, ו- פרוטוקול HTTP . פרוטוקול זה משמש כיוון שמדובר בסביבה מבוזרת שכל פונקציונליות ומיוצגת עם משאב לביצוע פעולות
- הודעות אסינכרוניות: במצב בו לקוחות אינם ממתינים לתגובות משירות, מיקרוסרוויס בדרך כלל נוטים להשתמש בפרוטוקולים כגון AMQP, STOMP, MQTT . פרוטוקולים אלה משמשים בתקשורת מסוג זה מכיוון שמוגדר אופי ההודעות והודעות אלה צריכות להיות אינטראקטיביות בין היישומים.
השאלה הבאה שעשויה לעלות על דעתך היא כיצד האפליקציות המשתמשות במיקרו-שירותים מטפלות בנתונים שלהן?
5. טיפול בנתונים
ובכן, כל Microservice מחזיק בבסיס נתונים פרטי כדי ללכוד את הנתונים שלהם וליישם את הפונקציונליות העסקית בהתאמה. כמו כן, מאגרי המידע של Microservices מתעדכנים באמצעות ה- API של השירות שלהם בלבד. עיין בתרשים להלן:
איור 3: ייצוג של שירותי מיקרו-שירותים המטפלים בנתונים - אדריכלות מיקרו-שירותים
השירותים הניתנים על ידי MicroServices מועברים לכל שירות מרוחק התומך בתקשורת בין-תהליכית עבור ערימות טכנולוגיות שונות.
6. תוכן סטטי
לאחר שמיקרו-שירותים מתקשרים בתוכם, הם פורסים את התוכן הסטטי לשירות אחסון מבוסס ענן שיכול לספק אותם ישירות ללקוחות באמצעות רשתות משלוח תוכן (CDN) .
מלבד הרכיבים שלעיל, ישנם כמה רכיבים אחרים המופיעים בארכיטקטורת מיקרו-שירותים טיפוסית:
7. ניהול
רכיב זה אחראי על איזון השירותים בצמתים וזיהוי כשלים.
8. גילוי שירות
משמש כמדריך למיקרו-שירותים למציאת דרך התקשורת ביניהם מכיוון שהוא מנהל רשימת שירותים עליהם נמצאים הצמתים.
הירשם לערוץ היוטיוב שלנו כדי לקבל עדכונים חדשים ..!
כעת, בואו נבדוק את היתרונות והחסרונות של ארכיטקטורה זו כדי להבין טוב יותר מתי להשתמש בארכיטקטורה זו.
יתרונות וחסרונות של אדריכלות מיקרו-שירותים
עיין בטבלה שלהלן.
| היתרונות של אדריכלות מיקרו-שירותים | חסרונות של מיקרו-שירות ארכיטקטורה |
| חופש להשתמש בטכנולוגיות שונות | מגביר אתגרים לפתרון בעיות |
| כל מיקרו-שירות מתמקד ביכולת עסקית אחת | מגביר את העיכוב בגלל שיחות מרחוק |
| תומך ביחידות פרידות בודדות | מאמצים מוגברים לתצורה ולפעולות אחרות |
| מאפשר מהדורות תוכנה תכופות | קשה לשמור על בטיחות העסקה |
| מבטיח אבטחה של כל שירות | קשה לעקוב אחר נתונים על פני גבולות שירות שונים |
| שירותים מרובים מפותחים ונפרסים במקביל | קשה להעביר קוד בין שירותים |
בואו נבין יותר על מיקרו-שירותים על ידי השוואת הארכיטקטורה הקודמת של UBER לזו הנוכחית.
לימוד מקרה אובר
הארכיטקטורה הקודמת של UBER
כמו חברות סטארט-אפ רבות, UBER החלה את דרכה בארכיטקטורה מונוליטית שנבנתה להנפקה אחת בעיר אחת. נראה כי לאחר בסיס קוד אחד ניקה באותה תקופה, ופתר את בעיות הליבה העסקיות של UBER. עם זאת, כאשר UBER החלה להתרחב ברחבי העולם הם התמודדו בקפדנות עם בעיות שונות ביחס למדרגיות ואינטגרציה מתמשכת.
איור 4: אדריכלות מונוליטית של UBER - אדריכלות מיקרו-שירותים
התרשים שלמעלה מתאר את הארכיטקטורה הקודמת של UBER.
- קיים REST API שאיתו הנוסע והנהג מתחברים.
- שלושה מתאמים שונים משמשים עם API בתוכם, לביצוע פעולות כגון חיוב, תשלומים, שליחת מיילים / הודעות שאנו רואים כאשר אנו מזמינים מונית.
- מסד נתונים של MySQL לאחסון כל הנתונים שלהם.
לכן, אם אתה מבחין כאן כל התכונות כגון ניהול נוסעים, חיוב, מאפייני התראות, תשלומים, ניהול נסיעה וניהול נהגים הורכבו במסגרת אחת.
הצהרת בעיה
בעוד UBER החלה להתרחב ברחבי העולם סוג זה של מסגרת הציג אתגרים שונים. להלן כמה מהאתגרים הבולטים
- היה צריך לבנות מחדש את כל התכונות, לפרוס אותן ולבדוק אותן שוב ושוב כדי לעדכן תכונה אחת.
- תיקון באגים הפך לקשה ביותר במאגר יחיד, שכן מפתחים נאלצו לשנות את הקוד שוב ושוב.
- קנה מידה של תכונות בו זמנית עם הצגת תכונות חדשות ברחבי העולם היה די קשה להתמודד יחד.
פִּתָרוֹן
כדי להימנע מבעיות כאלה, החליט UBER לשנות את הארכיטקטורה שלה וללכת אחר חברות אחרות עם צמיחת יתר כמו אמזון, נטפליקס, טוויטר ורבות אחרות. לפיכך, UBER החליטה לפרק את הארכיטקטורה המונוליטית שלה למספר בסיסי קוד כדי ליצור ארכיטקטורת מיקרו-שירות.
עיין בתרשים למטה כדי לבחון את ארכיטקטורת המיקרו-שירות של UBER.
איור 5: אדריכלות מיקרו-שירות של UBER - אדריכלות מיקרו-שירות
- השינוי העיקרי שנצפה כאן הוא הכנסת ה- API Gateway דרכו מחוברים כל הנהגים והנוסעים. משער ה- API כל הנקודות הפנימיות מחוברות כמו ניהול נוסעים, ניהול נהג, ניהול נסיעה ואחרים.
- היחידות הן יחידות נפרדות נפרדות המבצעות פונקציות נפרדות.
- לדוגמא: אם אתה רוצה לשנות משהו במיקרו-שירותים לחיוב, אתה רק צריך לפרוס רק מיקרו-שירותים לחיוב ולא צריך לפרוס את האחרים.
- כל התכונות הועברו כעת בנפרד, כלומר התלות ההדדית בין כל תכונה ותכונה הוסרה.
- לדוגמא, כולנו יודעים שמספר האנשים שמחפשים מוניות יותר יחסית לאנשים שמזמינים מונית ומשלמים תשלומים. זה גורם לנו להסיק מכך שמספר התהליכים העובדים על שירות המיקרו-ניהול של הנוסעים הוא יותר ממספר התהליכים העובדים על תשלומים.
בזהדֶרֶך, UBER הרוויח מהשינוישֶׁלָהאדריכלות ממונוליתית ועד מיקרו-שירותים.
אני מקווה שנהניתם לקרוא את הפוסט הזה על Microservice Architecture.אעלה עוד בלוגים, שיכילו גם ידיים.
מעוניין ללמוד עוד על מיקרו-שירותים?
אם ברצונך ללמוד שירותי מיקרוסופט ולבנות יישומים משלך, עיין ב שמגיע עם הדרכה חיה בהנחיית מדריך וניסיון פרויקט אמיתי. הכשרה זו תעזור לך להבין את שירותי המיקרו-שירותים לעומק ותסייע לך להשיג שליטה בנושא.
יש לך שאלה עבורנו? אנא הזכיר זאת בסעיף ההערות של ” אדריכלות מיקרו-שירות ”ואחזור אליך.