שירותי מיקרו: הגודל קובע, גם אם יש לך Kubernetes

19 בספטמבר במוסקבה התקיים הפגישה הנושאית הראשונה HUG (Highload++ User Group), שהוקדשה לשירותי מיקרו. הייתה מצגת "הפעלת Microservices: Size Matters, Even If You Have Kubernetes", שבה חלקנו את הניסיון הרב של פלנט בהפעלת פרויקטים עם ארכיטקטורת מיקרו-שירותים. קודם כל, זה יהיה שימושי לכל המפתחים שחושבים להשתמש בגישה זו בפרויקט הנוכחי או העתידי שלהם.

היכרות סרטון הדיווח (50 דקות, הרבה יותר אינפורמטיבי מהמאמר), כמו גם התמצית הראשית ממנו בצורת טקסט.

הערה: וידאו ומצגת זמינים גם בסוף פוסט זה.

מבוא

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

אתחיל עם הגרף הזה, שמחברו (בשנת 2015) היה מרטין פאולר:

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

אני אוסיף לגרף הזה למקרה של שימוש ב-Kubernetes:

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

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

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

והנה הרעיון המרכזי:

מה זה רגיל ארכיטקטורת microservice? זה אמור להביא לך יתרונות אמיתיים, להגדיל את יעילות העבודה שלך. אם נחזור לגרף, הנה הוא:

אם תתקשר אליה שימושי, ואז בצד השני של הגרף יהיה מַזִיק שירותי מיקרו (מפריעים לעבודה):

נחזור ל"רעיון המרכזי": האם עליי לסמוך על הניסיון שלי בכלל? מתחילת השנה הזו חיפשתי 85 פרויקטים. לא כולם היו מיקרו-שירותים (כשליש עד מחציתם היו בעלי ארכיטקטורה כזו), אבל זה עדיין מספר גדול. אנו (חברת פלנט) כמיקור חוץ מצליחים לראות מגוון רחב של אפליקציות שפותחו הן בחברות קטנות (עם 5 מפתחים) והן בגדולות (~500 מפתחים). יתרון נוסף הוא שאנו רואים את היישומים הללו חיים ומתפתחים עם השנים.

למה שירותי מיקרו?

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

1. גבולות ברורים של מודולריות;
2. פריסה עצמאית;
3. חופש לבחור טכנולוגיות.

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

אם נתאר כמה מהנקודות "בתחושות", אז:

• גבולות ברורים של מודולים: כאן יש לנו מונוליט נורא, ועכשיו הכל יהיה מסודר בצורה מסודרת במאגרי Git, שבהם הכל "על המדפים", החם והרך אינם מעורבים;
• עצמאות פריסה: נוכל להפעיל שירותים באופן עצמאי כך שהפיתוח יעבור מהר יותר (פרסם תכונות חדשות במקביל);
• עצמאות בפיתוח: אנו יכולים לתת שירות מיקרו זה לצוות/מפתח אחד, וזה לאחד לאחר, שבזכותו נוכל להתפתח מהר יותר;
• боאמינות רבה יותר: אם מתרחשת השפלה חלקית (מיקרו-שירות אחד מתוך 20 נופל), אז רק כפתור אחד יפסיק לפעול, והמערכת כולה תמשיך לתפקד.

ארכיטקטורת מיקרו שירות טיפוסית (מזיקה).

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

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

משילוב של סיבות, שירותי המיקרו אלה נכתבים בפלטפורמות שונות:

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

מה ההשלכות שלו?

גם לפאולר יש את זה יש מאמר - על "התשלום" עבור שימוש בשירותי מיקרו:

ונראה אם ​​הציפיות שלנו התקיימו.

ברור גבולות של מודולים...

אבל כמה מיקרו-שירותים אנחנו באמת צריכים לתקן?להפעיל את השינוי? האם אנחנו יכולים בכלל להבין איך הכל עובד ללא מעקב מבוזר (אחרי הכל, כל בקשה מעובדת על ידי חצי מהשירותים המיקרו-שירותים)?

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

עצמאות בפריסה...

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

חופש לבחור בטכנולוגיה...

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

עצמאות בפיתוח...

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

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

קנה מידה נפרד...

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

Боיותר אמינות...

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

יכולת מדידת עומס...

זה ממש טוב.

ה"קלילות" של שירותי מיקרו...

יש לנו לא רק ענק תקורה של הרשת (הבקשות ל-DNS מתרבות וכו'), אבל גם בגלל שאילתות המשנה הרבות שהתחלנו לשכפל נתונים (מטמון חנות), מה שהוביל לכמות משמעותית של אחסון.

והנה התוצאה של עמידה בציפיות שלנו:

אבל זה לא הכל!

כי:

• סביר להניח שנצטרך אוטובוס הודעות.
• איך לעשות גיבוי עקבי ברגע הנכון בזמן? היחיד реальный האפשרות היא לכבות את התנועה בשביל זה. אבל איך עושים את זה בייצור?
• אם אנחנו מדברים על תמיכה בכמה אזורים, אז ארגון קיימות בכל אחד מהם הוא משימה עתירת עבודה.
• מתעוררת הבעיה של ביצוע שינויים ריכוזיים. למשל, אם נצטרך לעדכן את גרסת ה-PHP, נצטרך להתחייב לכל מאגר (ויש עשרות כאלה).
• הגידול במורכבות התפעולית היא, באופן אקספוננציאלי, אקספוננציאלי.

מה לעשות עם כל זה?

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

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

אבל מה אם אנחנו כבר במצב הזה?

הצעד הראשון לפתרון כל בעיה הוא להסכים איתה ולהבין שזו בעיה, שאנחנו לא רוצים לסבול יותר.

אם במקרה של מונוליט מגודל (כשנגמרה לנו ההזדמנות לרכוש עבורו משאבים נוספים), אנחנו חותכים אותו, אז במקרה הזה מסתבר הסיפור ההפוך: כששירותי מיקרו מוגזמים כבר לא עוזרים, אלא מעכבים - לחתוך עודפים ולהגדיל!

לדוגמה, עבור התמונה הקולקטיבית שנדונה לעיל...

היפטר משירותי המיקרו המפוקפקים ביותר:

שלב את כל שירותי המיקרו האחראים ליצירת חזית קצה:

... למיקרו-שירות אחד, כתוב בשפה/מסגרת אחת (מודרנית ורגילה, כפי שאתה בעצמך חושב):

יהיה לו ORM אחד (DBMS אחד) וקודם כל כמה יישומים:

... אבל באופן כללי אתה יכול להעביר הרבה יותר לשם ולקבל את התוצאה הבאה:

יתרה מכך, ב-Kubernetes אנו מפעילים את כל זה במופעים נפרדים, מה שאומר שעדיין נוכל למדוד את העומס ולהתאים אותם בנפרד.

תִמצוּת

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

במילה "מיקרושירותים" חלק ה"מיקרו" מיותר.. הם "מיקרו" רק בגלל שהם קטנים יותר ממונוליט ענק. אבל אל תחשוב עליהם כעל משהו קטן.

ולמחשבה אחרונה, בואו נחזור לתרשים המקורי:

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

סרטונים ושקופיות

סרטון מהנאום (~50 דקות; למרבה הצער, הוא לא מעביר את הרגשות הרבים של המבקרים, שקבעו במידה רבה את הלך הרוח של הדיווח, אבל ככה זה):

הצגת הדו"ח:

נ.ב.

דיווחים נוספים בבלוג שלנו:

• «ניטור ו-Kubernetes» (דמיטרי סטוליארוב; 28 במאי 2018 ב-RootConf);
• «שיטות עבודה מומלצות ל-CI/CD עם Kubernetes ו-GitLab» (דמיטרי סטוליארוב; 7 בנובמבר 2017 ב-HighLoad++);
• «הניסיון שלנו עם Kubernetes בפרויקטים קטנים» (דמיטרי סטוליארוב; 6 ביוני 2017 ב-RootConf);
• «אנו בונים תמונות Docker עבור CI/CD במהירות ובנוחות עם Dapp» (דמיטרי סטוליארוב; 8 בנובמבר 2016 ב-HighLoad++);
• «שיטות משלוח רציפות עם Docker» (דמיטרי סטוליארוב; 31 במאי 2016 ב-RootConf).

ייתכן שתתעניין גם בפרסומים הבאים:

• «מותו של טירוף המיקרו-שירותים ב-2018";
• «7 שיטות עבודה מומלצות לשימוש בקונטיינרים לפי גוגל";
• «נתונים סטטיסטיים מ-The New Stack על האתגרים של יישום Kubernetes".

מקור: www.habr.com