הערה. תרגום: רשת שירות היא תופעה שעדיין אין לה תרגום יציב לרוסית (לפני יותר משנתיים הצענו את האפשרות "רשת לשירותים", וקצת מאוחר יותר, כמה עמיתים החלו לקדם באופן פעיל את השילוב "מסננת שירות") . דיבור מתמיד על הטכנולוגיה הזו הוביל למצב שבו המרכיבים השיווקיים והטכניים שלובים זה בזה יותר מדי. החומר הנפלא הזה של אחד מחברי המונח המקורי נועד להביא בהירות למהנדסים ולא רק.
קומיקס מ
מבוא
אם אתה מהנדס תוכנה שעובד איפשהו בתחום של מערכות עורפיות, המונח "רשת שירות" כנראה כבר השתרש היטב בראש שלך במהלך השנים האחרונות. הודות לצירוף מקרים מוזר, הביטוי הזה משתלט על הענף יותר ויותר, וההייפ והצעות הקידום הנלוות גדלים כמו כדור שלג, עפים במורד הגבעה ולא מראים סימני האטה.
רשת שירות נולדה במים העכורים והמוטים של המערכת האקולוגית של ענן. למרבה הצער, זה אומר שחלק גדול מהמחלוקת סביבו נע בין "דיבורים דלי קלוריות" ועד - אם להשתמש במונח טכני - שטויות גמורות. אבל אם תחתכו את כל הרעש, תגלו שלרשת השירות יש פונקציה מאוד אמיתית, מוגדרת וחשובה.
בפוסט הזה, אנסה לעשות בדיוק את זה: לספק מדריך ישר, מעמיק, ממוקד מהנדס לרשת שירות. אני לא רק אענה על השאלה: "מה זה?", - אבל גם "למה?"ו - "למה עכשיו?". לבסוף, אנסה לשרטט מדוע (לדעתי) הטכנולוגיה המסוימת הזו גרמה להייפ כל כך מטורף, שהוא כשלעצמו סיפור מעניין.
מי אני
שלום לכולם! שמי . אני אחד היוצרים - פרויקט רשת השירות הראשון והפרויקט שאשם בהופעתו של המונח רשת שירות ככזה (סליחה חבר'ה!). (הערה תרגום.: אגב, עם שחר הופעת המונח הזה, לפני יותר מ-2,5 שנים, כבר תרגמנו את החומר המוקדם של אותו מחבר בשם "".) גם אני מוביל הוא סטארט-אפ שבונה דברים מגניבים של שירות רשת כמו Linkerd ו .
אתם בטח יכולים לנחש שיש לי דעה מאוד מגמתית וסובייקטיבית בנושא הזה. עם זאת, אנסה לשמור על הטיה למינימום (למעט סעיף אחד: "למה מדברים כל כך הרבה על רשת שירות?", - שבו אשתף בכל זאת את הרעיונות המוקדמים שלי). אני גם אעשה כמיטב יכולתי להפוך את המדריך הזה לאובייקטיבי ככל האפשר. בדוגמאות ספציפיות, אסתמך בעיקר על הניסיון של Linkerd, תוך הצבעה על ההבדלים (אם בכלל) שאני מכיר ביישום סוגים אחרים של רשת שירות.
אוקיי, הגיע הזמן לעבור לפינוקים.
מהי רשת שירות?
למרות כל ההייפ, רשת השירות היא די פשוטה מבחינה מבנית. זה רק חבורה של פרוקסי של מרחב משתמש הממוקמים "ליד" שירותים (נדבר קצת על "קרוב" מאוחר יותר), בתוספת סט של תהליכי בקרה. ה-proxies נקראים ביחד מישור נתונים, ותהליכי הבקרה נקראים מטוס בקרה. מישור הנתונים מיירט שיחות בין שירותים ועושה איתם "כל דבר אחר"; מישור הבקרה, בהתאמה, מתאם את התנהגות ה-proxy ומספק לך גישה, כלומר. מפעיל, ל-API, המאפשר לתפעל ולמדוד את הרשת כולה.
מה זה הפרוקסי הזה? זהו פרוקסי TCP של הקטגוריה "מודע לשכבה 7". (כלומר "לוקח בחשבון" שכבה 7 של מודל OSI) כמו HAProxy ו-NGINX. אתה יכול לבחור פרוקסי לטעמך; Linkerd משתמש בפרוקסי Rust, בעל שם לא מסובך . הרכבנו אותו במיוחד עבור רשת שירות. רשתות אחרות מעדיפות פרוקסי אחרים (Envoy היא בחירה נפוצה). עם זאת, בחירת פרוקסי היא רק עניין של יישום.
מה עושים שרתי פרוקסי אלו? ברור שהם שיחות פרוקסי לשירותים וממנו (באופן קפדני, הם פועלים כ-proxys ו-proxys הפוך, ומטפלים בשיחות נכנסות ויוצאות כאחד). והם מיישמים מערך תכונות שמתמקד בשיחות между שירותים. התמקדות זו בתעבורה בין שירותים היא מה שמבדיל בין שירות רשת פרוקסי לבין, למשל, שערים של API או פרוקסי כניסה (האחרונים מתמקדים בקריאות המגיעות לאשכול מהעולם החיצון). (הערה. תרגום: להשוואה של בקרי Kubernetes Ingress קיימים, שרבים מהם משתמשים ב-Envoy שהוזכר כבר, ראה .)
אז, גילינו את מישור הנתונים. מישור הבקרה פשוט יותר: זהו סט של רכיבים המספקים את כל המכניקה שמטוס הנתונים צריך כדי להפעיל בצורה מתואמת, לרבות גילוי שירות, הנפקת תעודות TLS, צבירה מטרית וכו'. מישור הנתונים מודיע למישור הבקרה על התנהגותו; בתורו, מישור הבקרה מספק API המאפשר לך לשנות ולנטר את ההתנהגות של מישור הנתונים בכללותו.
להלן תרשים של מישור הבקרה ומישור הנתונים ב-Linkerd. כפי שניתן לראות, מישור הבקרה כולל מספר רכיבים שונים, כולל מופע של Prometheus שאוסף מדדים משרתי פרוקסי, כמו גם רכיבים אחרים כגון destination (גילוי שירות), identity (רשות אישורים, CA) ו public-api (נקודות קצה עבור אינטרנט ו-CLI). לעומת זאת, מישור הנתונים הוא פרוקסי מקושר פשוט ליד מופע האפליקציה. זהו רק דיאגרמה לוגית; בפריסה בעולם האמיתי, אולי יהיו לך שלושה העתקים של כל רכיב של מטוס בקרה ומאות או אלפי פרוקסי במישור הנתונים.
(המלבנים הכחולים בתרשים זה מסמלים את גבולות התרמילים של Kubernetes. ניתן לראות שהמכולות עם שרת-proxy נמצאים באותו תרמיל כמו מיכלי האפליקציה. סכימה זו ידועה בשם מיכל צד.)
לארכיטקטורת רשת השירות יש כמה השלכות חשובות. ראשית, מכיוון שהמשימה של פרוקסי היא ליירט שיחות בין שירותים, רשת שירות הגיונית רק אם האפליקציה שלך נוצרה עבור קבוצה מסוימת של שירותים. רֶשֶׁת אחד יכול השתמש עם מונוליטים, אבל ברור שזה מיותר למען פרוקסי יחיד, וסביר להניח שהפונקציונליות שלו לא תהיה מבוקשת.
תוצאה חשובה נוספת היא שרשת השירות דורשת עָצוּם מספר פרוקסי. למעשה, Linkerd משרשרת פרוקסי linkerd לכל מופע של כל שירות (יישומים אחרים מוסיפים פרוקסי לכל מארח/מארח/VM. בכל מקרה זה הרבה). שימוש פעיל כזה בפרוקסי כשלעצמו טומן בחובו מספר סיבוכים נוספים:
- פרוקסי במישור הנתונים צריכים להיות מָהִיר, כי לכל קריאה יש כמה קריאות ל-proxy: אחת בצד הלקוח, אחת בצד השרת.
- כמו כן, פרוקסי חייב להיות קָטָן и קל. כל אחד מהם יצרוך משאבי זיכרון ומעבד, וצריכה זו תגדל באופן ליניארי עם האפליקציה.
- תזדקק למנגנון כדי לפרוס ולעדכן מספר רב של פרוקסי. לעשות את זה ידנית זו לא אופציה.
באופן כללי, רשת השירות נראית כך (לפחות ממעוף הציפור): אתה פורס חבורה של פרוקסי מרחב משתמש ש"עושים משהו" עם תעבורה פנימית בין שירותים, ומשתמשים במישור הבקרה כדי לנטר ולנהל אותם.
הגיע הזמן לשאלה "למה?"
למה מיועדת רשת שירות?
למי שנתקל לראשונה ברעיון של רשת שירות, נסלח קצת להתפעל. עיצוב רשת השירות אומר שלא רק שהוא יגדיל את זמן האחזור של האפליקציה, אלא גם יגדיל לִצְרוֹך משאבים ו יוסיף חבורה של מנגנונים חדשים בתשתית. ראשית אתה מקים רשת שירות, ואז פתאום אתה מוצא את עצמך צריך לתת שירות למאות (אם לא אלפי) פרוקסי. השאלה היא מי יעשה זאת מרצונו?
התשובה לשאלה זו כוללת שני חלקים. ראשית, עלויות העסקאות הקשורות לפריסת פרוקסי אלו יכולות להיות מופחתות באופן משמעותי עקב שינויים מסוימים המתרחשים במערכת האקולוגית (עוד על כך בהמשך).
שנית, מכשיר כזה הוא למעשה דרך מצוינת להכניס היגיון נוסף למערכת. ולא רק כי ניתן להוסיף הרבה פיצ'רים חדשים באמצעות רשת השירות, אלא גם כי ניתן לעשות זאת מבלי להפריע למערכת האקולוגית. למעשה, כל מודל רשת השירות מבוסס על ההנחה הזו: במערכת מרובת שירותים, לא משנה מה לעשות שירותים בודדים, תעבורה ביניהם היא הנקודה האידיאלית להוספת פונקציונליות.
לדוגמה, ב-Linkerd (כמו ברוב הרשתות) הפונקציונליות מתמקדת בעיקר בקריאות HTTP, כולל HTTP/2 ו-gRPC*. הפונקציונליות עשירה למדי - ניתן לחלק אותה לשלוש מחלקות:
- תכונות הקשורות ל מהימנות. נסה שוב בקשות, פסקי זמן, גישה קנרית (פיצול תנועה/הפניה מחדש) וכו'.
- תכונות הקשורות ל ניטור. צבירת אחוזי הצלחה, עיכובים ונפחי בקשות לכל שירות או יעדים בודדים; בניית מפות טופולוגיות של שירותים וכו'.
- תכונות הקשורות ל אבטחה. TLS הדדי, בקרת גישה וכו'.
* מנקודת המבט של Linkerd, gRPC כמעט ולא שונה מ-HTTP/2: הוא רק משתמש ב-protobuf במטען. מנקודת מבטו של מפתח, שני הדברים האלה כמובן שונים.
רבים מהמנגנונים הללו פועלים ברמת הבקשה (ומכאן "פרוקסי L7"). לדוגמה, אם השירות Foo מבצע קריאת HTTP ל-service Bar, ה-linked-proxy בצד של Foo יכול בצורה חכמה לאזן עומסים ולנתב שיחות ממופעי Foo ל-Bar על סמך זמן השהייה שנצפה; הוא יכול לחזור על הבקשה במידת הצורך (ואם היא אימפוטנטית); הוא יכול להקליט את קוד התגובה ואת הזמן הקצוב, וכן הלאה. באופן דומה, ה-linked-proxy בצד הסרגל יכול לדחות בקשה אם היא אינה מותרת או אם חריגה ממגבלת הבקשה; יכול לתקן את העיכוב מצידו וכו'.
פרוקסי יכולים "לעשות משהו" גם ברמת החיבור. לדוגמה, שרת פרוקסי בצד Foo יכול ליזום חיבור TLS, ושרת proxy בצד הסרגל יכול לסיים אותו, ושני הצדדים יכולים לאמת את תעודות ה-TLS של זה*. זה מספק לא רק הצפנה בין שירותים, אלא גם דרך מאובטחת קריפטוגרפית לזהות שירותים: Foo ובר יכולים "להוכיח" שהם מי שהם אומרים שהם.
* "חבר של חבר" פירושו שגם תעודת הלקוח מאומתת (TLS הדדי). ב-TLS "קלאסי", למשל בין דפדפן לשרת, לרוב מאומתת האישור של צד אחד בלבד (השרת).
בין אם הם פועלים ברמת הבקשה או החיבור, חשוב להדגיש שכל פונקציות רשת השירות הן מִבצָעִי אופי. Linkerd לא מסוגלת לשנות את הסמנטיקה של המטען - למשל, הוספת שדות למקטע JSON או ביצוע שינויים ב-protobuf. על תכונה חשובה זו נדבר מאוחר יותר כאשר נדבר על ESB ותוכנות ביניים.
זוהי קבוצת התכונות שמציעה רשת השירות. נשאלת השאלה: למה לא ליישם אותם ישירות באפליקציה? ולמה בכלל להתעסק עם פרוקסי?
מדוע רשת שירות היא רעיון טוב
בעוד היכולות של רשת השירות שובות לב, הערך העיקרי שלה לא ממש טמון בתכונות. בסופו של דבר אנחנו פחית ליישם אותם ישירות באפליקציה (בהמשך נראה שזה היה המקור של רשת השירות). אם לנסח את זה במשפט אחד, הערך של רשת שירות הוא: הוא מספק פונקציונליות קריטית להפעלת תוכנת שרת מודרנית באופן עקבי, ערימה, אגנוסטית של קוד יישומים.
בואו ננתח את ההצעה הזו.
«פונקציות קריטיות להפעלת תוכנת שרת מודרנית". אם אתה בונה אפליקציית שרת טרנזקציות המחוברת לאינטרנט הציבורי שמקבלת בקשות מהעולם החיצון ועונה להן תוך זמן קצר - למשל, אפליקציית אינטרנט, שרת API, והרוב המכריע של אפליקציות מודרניות אחרות - ו אם אתה מיישם את זה כמערכת של שירותים המקיימים אינטראקציה סינכרונית אחד עם השני, ואם אתה כל הזמן משדרג את התוכנה הזו, מוסיף תכונות חדשות, ואם תיאלץ לשמור על מערכת זו במצב תקין במהלך השינוי - במקרה זה, מזל טוב , אתה יוצר תוכנת שרת מודרנית . וכל התכונות הנהדרות המפורטות לעיל מתבררות כקריטיות עבורך. היישום חייב להיות אמין, מאובטח, ואתה חייב להיות מסוגל לראות מה הוא עושה. את השאלות הללו רשת השירות עוזרת לפתור.
(אוקיי, ההכרעה שלי שגישה זו היא הדרך המודרנית לבנות תוכנת שרת התגנבה לפסקה הקודמת. אחרים מעדיפים לפתח מונוליטים, "שירותי מיקרו תגובתיים" ודברים אחרים שאינם נופלים תחת ההגדרה שניתנה לעיל. לאנשים אלה כנראה יש דעה שונה משלי, ובתמורה, אני סבורה שהם "שגויים" - אם כי בכל מקרה, רשת השירות לא מאוד שימושית עבורם).
«אחיד לכל הערימה". התכונות שמספקת רשת השירות אינן רק קריטיות. הם חלים על כל השירותים באפליקציה, ללא קשר לאיזו שפה הם כתובים, באיזו מסגרת הם משתמשים, מי כתב אותם, איך הם נפרסו וכל שאר הדקויות של הפיתוח והשימוש בהם.
«קוד אפליקציה בלתי תלוי". לבסוף, רשת השירות לא רק מספקת פונקציונליות עקבית על פני כל הערימה, היא עושה זאת באופן שאינו מצריך עריכת האפליקציה. הבסיס הבסיסי של הפונקציונליות של רשת שירות, לרבות משימות של הגדרה, עדכון, הפעלה, תחזוקה וכו', הוא אך ורק ברמת הפלטפורמה ואינו תלוי באפליקציה. האפליקציה יכולה להשתנות מבלי להשפיע על רשת השירות. בתורו, רשת השירות יכולה להשתנות ללא כל התערבות אפליקציה.
בקיצור, רשת השירות לא רק מספקת פונקציונליות חיונית, אלא היא עושה זאת באופן גלובלי, אחיד ובלתי תלוי ביישום. וכך, בעוד שניתן ליישם את הפונקציונליות של רשת שירות בקוד של שירות (לדוגמה, כספרייה הכלולה בכל שירות), גישה זו לא תספק את האחידות והעצמאות שהן כה חשובות במקרה של רשת שירות.
וכל מה שאתה צריך לעשות הוא להוסיף חבורה של פרוקסי! אני מבטיח, בקרוב מאוד נבחן את העלויות התפעוליות הקשורות להוספת ה-proxys הללו. אבל קודם כל, בואו נעצור ונסתכל על הרעיון הזה של עצמאות מנקודת מבט של שונים אנשים.
למי עוזרת רשת השירות?
עד כמה שזה לא נוח, כדי שטכנולוגיה תהפוך לחלק חשוב מהמערכת האקולוגית, היא חייבת להתקבל על ידי אנשים. אז מי מעוניין ברשת שירות? מי מרוויח מהשימוש בו?
אם אתה מפתח תוכנת שרת מודרנית, אתה יכול לחשוב על הצוות שלך כעל קבוצה בעלי שירותיםשיחד מפתחים ומיישמים היגיון עסקי, ו בעלי פלטפורמותמעורב בפיתוח הפלטפורמה הפנימית עליה פועלים שירותים אלו. בארגונים קטנים, אלו יכולים להיות אותם אנשים, אך ככל שהחברה גדלה, תפקידים אלו נוטים להיות בולטים יותר ואף מחולקים לתפקידי משנה... (יש כאן הרבה מה לומר על האופי המשתנה של devops, ההשפעה הארגונית של שירותי מיקרו וכו'.) נ. אבל לעת עתה, בואו ניקח את התיאורים האלה כמובן מאליו).
מנקודת מבט זו, הנהנים המובהקים מרשת השירות הם בעלי הפלטפורמה. הרי בסופו של דבר המטרה של צוות הפלטפורמה היא ליצור פלטפורמה פנימית שעליה יוכלו בעלי שירות ליישם היגיון עסקי ולעשות זאת באופן שיבטיח שהם יהיו כמה שיותר עצמאיים מהפרטים העכורים של פעולתו. לא רק שרשת שירות מציעה יכולות קריטיות להשגת מטרה זו, היא עושה זאת באופן שבתורו אינו כופה תלות על בעלי השירות.
גם בעלי השירותים מרוויחים, אם כי בצורה עקיפה יותר. המטרה של בעל השירות היא להיות פרודוקטיבי ככל האפשר ביישום ההיגיון של התהליך העסקי, וככל שיצטרך לדאוג פחות לנושאים תפעוליים, כך ייטב. במקום לאכוף, למשל, מדיניות לנסות שוב או TLS, הם יכולים להתמקד אך ורק בעסק ולקוות שהפלטפורמה תדאג לכל השאר. עבורם זה יתרון גדול.
לא ניתן להפריז בערכה הארגוני של חלוקה כזו בין בעלי הפלטפורמות והשירותים. אני חושב שהיא תורמת בסיסי תרומה לערך רשת השירות.
למדנו את הלקח הזה כשמעריץ מוקדם של Linkerd אמר לנו למה הם בחרו ברשת השירות: כי זה אפשר להם "להמשיך לדבר למינימום". הנה כמה פרטים: חבר'ה מחברה גדולה אחת העבירו את הפלטפורמה שלהם ל-Kubernetes. מכיוון שהאפליקציה עבדה עם מידע רגיש, הם רצו להצפין את כל התקשורת באשכולות. עם זאת, המצב הסתבך בשל נוכחותם של מאות שירותים ומאות צוותי פיתוח. הסיכוי ליצור קשר עם כולם ולשכנע אותם לכלול תמיכה ב-TLS בתוכניות שלהם לא מצא חן בעיניהם בכלל. על ידי התקנת Linkerd, הם עברו אחריות ממפתחים (מנקודת מבטם זו הייתה צרות מיותרות) ועד לפלטפורמות, שעבורן זה היה בראש סדר העדיפויות. במילים אחרות, Linkerd פתר עבורם לא כל כך בעיה טכנית אלא ארגונית.
בקיצור, רשת השירות היא, במקום זאת, לא פתרון טכני, אלא סוציו-טכני בעיות. (תודה על הצגת המונח הזה.
האם רשת השירות תפתור את כל הבעיות שלי?
כן. כלומר, לא!
כשמסתכלים על שלושת סוגי התכונות שפורטו לעיל - אמינות, אבטחה וצפייה - מתברר שרשת השירות אינה פתרון מלא לאף אחת מהבעיות הללו. למרות ש-Linkerd יכולה לשלוח בקשות חוזרות ונשנות (אם היא יודעת שהן חסרות יכולת), היא אינה מסוגלת לקבל החלטות לגבי מה להחזיר למשתמש אם השירות ירד סופית - החלטות כאלה חייבות להתקבל על ידי האפליקציה. Linkerd יכולה לשמור נתונים סטטיסטיים על בקשות מוצלחות, אבל היא לא מסוגלת לבדוק את השירות ולספק את המדדים הפנימיים שלו - לאפליקציה צריכה להיות ערכת כלים כזו. ולמרות ש-Linkerd מסוגלת לארח mTLS, פתרונות אבטחה מלאים דורשים הרבה יותר.
תת-קבוצה של המאפיינים באזורים אלה המוצעים על ידי רשת השירות מתייחסים אליהם תכונות פלטפורמה. בזה אני מתכוון לפונקציות ש:
- בלתי תלוי בהיגיון העסקי. האופן שבו היסטוגרמות שיחות נבנות בין Foo ל-Bar הוא בלתי תלוי לחלוטין בשאלה אם מדוע פו מתקשר לבר.
- קשה ליישם נכון. ב-Linkerd, ניסיונות חוזרים מותאמים לכל מיני דברים מפוארים כמו תקציבי ניסיון חוזר. (נסה שוב תקציבים), מכיוון שגישה לא מתוחכמת וראשית ליישום דברים כאלה בהחלט תוביל להופעתה של מה שמכונה "מפולת של בקשות" (נסה שוב סערה) ובעיות אחרות ספציפיות למערכות מבוזרות.
- היעיל ביותר כאשר מיישמים אותו בעקביות. מנגנון TLS הגיוני רק אם מיושם בכל מקום.
מכיוון שתכונות אלו מיושמות בשכבת ה-proxy (ולא בשכבת האפליקציה), רשת השירות חושפת אותן ב- פּלַטפוֹרמָה, לא יישומים. לפיכך, אין זה משנה באיזו שפה כתובים השירותים, באיזו מסגרת הם משתמשים, מי כתב אותם ולמה. פרוקסי עובדים מעבר לכל הפרטים הללו, והבסיס הבסיסי של פונקציונליות זו, לרבות משימות ההגדרה, העדכון, ההפעלה, התחזוקה וכו', טמון אך ורק ברמת הפלטפורמה.
דוגמאות ליכולות רשת שירות
לסיכום, רשת שירות אינה פתרון מלא לאמינות, צפייה או אבטחה. היקף התחומים הללו מרמז על השתתפות חובה של בעלי שירותים, צוותי Ops / SRE ובעלי עניין אחרים בחברה. רשת השירות מספקת רק "נתח" ברמת הפלטפורמה לכל אחד מהאזורים הללו.
מדוע רשת השירות הפכה פופולרית דווקא עכשיו?
אתה בטח תוהה עכשיו: בסדר, אם רשת השירות כל כך טובה, למה לא התחלנו לפרוס מיליוני פרוקסי על הערימה לפני עשר שנים?
לשאלה הזו יש תשובה בנאלית: לפני עשר שנים כולם בנו מונוליטים, ואף אחד לא היה צריך רשת שירות. זה נכון, אבל לדעתי התשובה הזו מחמיצה את הנקודה. אפילו לפני עשר שנים, הרעיון של מיקרו-שירותים כדרך מבטיחה ליצור מערכות בקנה מידה גדול נדון ויושם רבות בחברות כמו טוויטר, פייסבוק, גוגל ונטפליקס. התפיסה הכללית - לפחות בחלקים של התעשייה שהייתי איתם בקשר - הייתה ששירותי מיקרו הם "הדרך הנכונה" לבנות מערכות גדולות, גם אם זה היה קשה.
כמובן, למרות שהיו חברות שניצלו שירותי מיקרו לפני עשר שנים, הן לא הדביקו פרוקסי בכל מקום שיכלו כדי ליצור רשת שירות. עם זאת, אם אתה מסתכל היטב, הם עשו משהו דומה: רבות מהחברות הללו הטילו חובה להשתמש בספרייה פנימית מיוחדת ליצירת רשת (לפעמים נקראת ספריית הלקוחות השומן, ספריית לקוחות שמנים).
לנטפליקס היה Hysterix, לגוגל היה את סטאבי, לטוויטר הייתה ספריית Finagle. פיינגל, למשל, היה חובה עבור כל שירות חדש בטוויטר. הוא טיפל הן בצד הלקוח והן בצד השרת של החיבורים, איפשר בקשות חוזרות, נתמך בניתוב בקשות, איזון עומסים ומדידה. זה סיפק שכבה עקבית של אמינות וצפייה בכל ערימת הטוויטר, ללא קשר למה שהשירות עשה. כמובן, זה עבד רק עבור שפות JVM והתבסס על מודל תכנות שהיה צריך לשמש עבור האפליקציה כולה. עם זאת, הפונקציונליות שלו הייתה כמעט זהה לזו של רשת השירות. (למעשה, הגרסה הראשונה של Linkerd הייתה רק Finagle עטופה בצורת פרוקסי.)
כך, לפני עשר שנים היו לא רק microservices, אלא גם ספריות פרוטו-service-mesh מיוחדות שפתרו את אותן בעיות שרשת השירות פותרת היום. עם זאת, רשת השירות עצמה לא הייתה קיימת אז. הייתה צריכה להיות משמרת נוספת לפני שהיא הופיעה.
וכאן טמונה התשובה העמוקה יותר, חבויה בשינוי אחר שחל ב-10 השנים האחרונות: חלה ירידה חדה בעלות פריסת המיקרו-שירותים. החברות שהוזכרו לעיל שהשתמשו בשירותי מיקרו לפני עשור - טוויטר, נטפליקס, פייסבוק, גוגל - היו חברות בהיקף עצום ומשאבים עצומים. לא רק היה להם את הצורך, אלא גם את היכולת לבנות, לפרוס ולהפעיל יישומים גדולים המבוססים על שירותי מיקרו. האנרגיה והמאמץ שהשקיעו מהנדסי טוויטר במעבר מגישה מונוליטית לגישה של שירותי מיקרו הם מדהימים. (בכנות, כמו העובדה שזה עבד.) סוג זה של תמרון תשתית היה אז בלתי אפשרי עבור חברות קטנות יותר.
מהר קדימה להווה. כיום יש סטארטאפים שבהם היחס בין שירותי מיקרו למפתחים הוא 5:1 (או אפילו ), ויותר מכך, הם מתמודדים איתם בהצלחה! אם סטארטאפ של 5 אנשים מסוגל להפעיל 50 מיקרו-שירותים בלי להתאמץ, אז משהו הפחית בבירור את עלות היישום שלהם.
1500 שירותי מיקרו במונזו; כל קו הוא כלל רשת קבוע המאפשר תעבורה
ההפחתה הדרמטית בעלות תפעול שירותי המיקרו היא תוצאה של תהליך אחד: הפופולריות הגוברת של מכולות и מתזמרים. זו בדיוק התשובה העמוקה לשאלה מה תרם להופעתה של רשת השירות. אותה טכנולוגיה הפכה גם את רשת השירות וגם את שירותי המיקרו לאטרקטיביים: Kubernetes ו- Docker.
למה? ובכן, Docker פותר בעיה אחת גדולה - בעיית האריזה. על ידי אריזה של אפליקציה ותלויות זמן הריצה שלה (שאינן רשתיות) בקונטיינר, Docker הופך את האפליקציה ליחידה ניתנת לשינוי שניתן לארח ולהריץ בכל מקום. יחד עם זאת, זה מאוד מפשט את התפעול. רב לשוני stack: מכיוון שמיכל הוא יחידת ביצוע אטומית, זה לא משנה מה יש בפנים, בין אם זה יישום JVM, Node, Go, Python או Ruby, למטרות פריסה ותפעול. אתה פשוט מפעיל את זה וזהו.
Kubernetes לוקח הכל לשלב הבא. כעת, כשיש חבורה של "דברים הניתנים להפעלה" ומכונות רבות להפעיל אותם, יש צורך בכלי שיכול להתאים אותם זה לזה. במובן הרחב, אתה נותן לקוברנטס קונטיינרים רבים ומכונות רבות, וזה מתאים אותם זה לזה (כמובן שזה תהליך דינמי ומשתנה כל הזמן: קונטיינרים חדשים מסתובבים במערכת, מכונות מתחילות ועוצרות וכו'. אולם, Kubernetes לוקח את כל זה בחשבון).
לאחר הגדרת Kubernetes, הזמן שלוקח לפרוס ולתפעל שירות אחד אינו שונה בהרבה מהעלות לפריסה ותפעול של עשרה שירותים (למעשה, זה כמעט זהה עבור 100 שירותים). תוסיפו לזה קונטיינרים כמנגנון אריזה שמעודד הטמעה רב-לשונית, וקיבלתם המון יישומים חדשים המיושמים כמיקרו-שירותים הכתובים במספר שפות, בדיוק מסוג הסביבה שרשת השירות כל כך מתאימה לה.
אז, הגענו לתשובה לשאלה מדוע הרעיון של רשת שירות הפך פופולרי דווקא עכשיו: האחידות ש- Kubernetes מספקת לשירותים ישימה ישירות למשימות התפעוליות העומדות בפני רשת השירות. אתה אורז פרוקסי במיכלים, נותן ל-Kubernetes את המשימה להדביק אותם בכל מקום אפשרי, והרי! כתוצאה מכך, אתה מקבל רשת שירות, בעוד Kubernetes שולט בכל המכניקה של הפריסה שלה. (לפחות ממעוף הציפור. כמובן, יש הרבה ניואנסים לתהליך הזה.)
לסיכום: הסיבה שרשת השירות הפכה פופולרית עכשיו ולא לפני עשר שנים היא ש-Kubernetes ו-Docker לא רק שהגדילו משמעותית צורך בו, מפשט את היישום של יישומים כקבוצות של מיקרו-שירותים רב לשוניים, אך גם מופחת באופן משמעותי עלויות להפעלתו על ידי מתן מנגנונים לפריסה ותחזוקה של פארקי פרוקסי צדדיים.
למה מדברים כל כך הרבה על רשת השירות?
אזהרה: בסעיף הזה, אני נוקט בכל מיני הנחות, השערות, המצאות ומידע פנים.
חפשו "רשת שירות" ותתקלו בהמון תוכן דל קלוריות ממוחזר, פרויקטים מוזרים וקליידוסקופ של עיוות ראוי לתא הד. כל טכנולוגיה מפוארת חדשה עושה זאת, אבל במקרה של רשת שירות הבעיה חריפה במיוחד. למה?
ובכן, זו אשמתי בחלקה. עשיתי כמיטב יכולתי לקדם את Linkerd ואת רשת השירות בכל הזדמנות, באמצעות אינספור פוסטים ומאמרים בבלוג כמו זה. אבל אני לא כזה חזק. כדי לענות באמת על השאלה הזו, אנחנו צריכים לדבר קצת על המצב הכללי. ואי אפשר לדבר על זה בלי להזכיר פרויקט אחד: היא רשת שירות בקוד פתוח שפותחה במשותף על ידי גוגל, יבמ וליפט.
(לשלושת החברות הללו יש תפקידים שונים מאוד: נראה שהמעורבות של Lyft מוגבלת רק לשם; הן כותבות את Envoy אך אינן משתמשות או מעורבות בפיתוח של Istio. IBM מעורבת בפיתוח של Istio ומשתמשת בו. גוגל היא מעורב מאוד בפיתוח של Istio, אבל עד כמה שאני יכול לדעת, לא ממש משתמש בו.)
פרויקט Istio בולט בשני דברים. ראשית, זה המאמץ השיווקי העצום שגוגל, במיוחד, משקיעה בקידום שלה. אני מעריך שרוב האנשים המודעים כיום למושג רשת השירות למדו עליו לראשונה בזכות Istio. התכונה השנייה היא כמה רע התקבלה איסטיו. בעניין הזה, אני, כמובן, צד מעוניין, אבל מנסה להישאר אובייקטיבי ככל האפשר, אני עדיין לא יכול שלא , לא מאוד ספציפי (אם כי לא ייחודי: systemd עולה בראש, ...) עבור פרויקט קוד פתוח.
(בפועל נראה שיש לאיסטיו בעיות לא רק במורכבות וב-UX, אלא גם בביצועים. למשל, במהלך שנערך על ידי צד שלישי, מומחים מצאו מצבים שבהם זמן האחזור של הזנב של Istio היה גבוה פי 100 מזה של Linkerd, כמו גם מצבים עם מחסור במשאבים, כאשר Linkerd המשיך לתפקד בהצלחה, ואיסטיו הפסיק לעבוד לחלוטין.)
אם נניח בצד את התיאוריות שלי לגבי למה זה קרה, אני מאמין שההייפ מחוץ לקנה מידה סביב רשת השירות נובע מהמעורבות של גוגל. כלומר, שילוב של שלושת הגורמים הבאים:
- קידום אובססיבי של Istio על ידי Google;
- יחס הולם וביקורתי כלפי הפרויקט;
- הפופולריות הרקיעת שחקים לאחרונה של Kubernetes, שזכרה עדיין טרי.
יחד, גורמים אלו מתלכדים למעין סביבה משכרת ואנוקסית שבה נחלשת יכולת השיפוט הרציונלית, ונשאר רק מגוון נפלא. .
מנקודת המבט של לינקרד, זה... מה שהייתי מתאר כברכה מעורבת. כלומר, זה נהדר ש-service mesh נכנסה למיינסטרים בצורה שלא עשתה זאת ב-2016 כאשר Linkerd התחילה לראשונה והיה ממש קשה לגרום לאנשים לשים לב לפרויקט. עכשיו אין בעיה כזו! אבל החדשות הרעות הן שנוף רשת השירות כל כך מבלבל היום, שכמעט בלתי אפשרי להבין אילו פרויקטים באמת שייכים לקטגוריית רשת השירות (שלא לדבר על להבין איזה מהם הכי מתאים למקרה שימוש מסוים). זהו בהחלט פריצת עסקאות לכולם (ובהחלט ישנם מקרים שבהם Istio או פרויקט אחר מתאימים יותר מ-Linkerd, מכיוון שהאחרון עדיין אינו פתרון אוניברסלי).
מהצד של Linkerd, האסטרטגיה שלנו הייתה להתעלם מהרעש, להמשיך להתמקד בפתרון הבעיות האמיתיות בקהילה, ובעצם לחכות שההייפ יגווע. בסופו של דבר ההייפ יירגע ונוכל להמשיך לעבוד בשלום.
עד אז, כולנו נצטרך להתאזר בסבלנות.
האם רשת השירות תועיל לי, מהנדס תוכנה צנוע?
השאלון הבא יעזור לענות על שאלה זו:
האם אתם עוסקים אך ורק ביישום ההיגיון העסקי? במקרה זה, רשת השירות לא תהיה שימושית עבורך. כלומר, כמובן, ייתכן שתתעניין בזה, אבל באופן אידיאלי, רשת השירות לא אמורה להשפיע ישירות על שום דבר בסביבה שלך. תמשיך לעבוד על מה שאתה משלם עליו.
האם אתם מתחזקים פלטפורמה בחברה המשתמשת ב-Kubernetes? כן, במקרה הזה אתה צריך רשת שירות (אלא אם כן, כמובן, אתה משתמש ב-K8s רק כדי להפעיל מונוליט או עיבוד אצווה - אבל אז אני רוצה לשאול למה אתה צריך K8s). סביר להניח שתקבלו הרבה מיקרו-שירותים שנכתבו על ידי אנשים שונים. כולם מקיימים אינטראקציה זה עם זה וקשורים לסבך של תלות בזמן ריצה, ואתה צריך למצוא דרך להתמודד עם הכל. השימוש ב-Kubernetes מאפשר לך לבחור רשת שירות "לעצמך". לשם כך, הכירו את היכולות והתכונות שלהם וענו על השאלה האם כל אחד מהפרויקטים הזמינים מתאים לכם (אני ממליץ להתחיל את המחקר עם Linkerd).
האם אתה מפעיל פלטפורמה עבור חברה שאינה משתמשת ב-Kubernetes אך משתמשת בשירותי מיקרו? במקרה זה, רשת השירות תהיה שימושית עבורך, אך השימוש בה יהיה לא טריוויאלי. כמובן שאתה יכול לְחַקוֹת רשת שירות על ידי אירוח של חבורה של פרוקסי, אבל יתרון חשוב של Kubernetes הוא בדיוק מודל הפריסה: תחזוקה ידנית של פרוקסי אלו תדרוש הרבה יותר זמן, מאמץ ועלות.
האם אתה אחראי על הפלטפורמה בחברה שעובדת עם מונוליטים? במקרה זה, כנראה שאינך זקוק לרשת שירות. אם אתה עובד עם מונוליטים (או אפילו קבוצות של מונוליטים) שיש להם דפוסי אינטראקציה מוגדרים היטב ולעתים רחוקות משתנים, אז לרשת השירות אין הרבה מה להציע לך. אז אתה יכול פשוט להתעלם מזה ולקוות שזה ייעלם כמו חלום רע...
מסקנה
כנראה ש-service mesh עדיין לא צריך להיקרא "הטכנולוגיה הכי מטורפת בעולם" - הכבוד המפוקפק הזה שייך כנראה לביטקוין או AI. אולי היא בחמישייה הראשונה. אבל אם חותכים את שכבות הרעש, מתברר שרשת השירות מביאה יתרונות אמיתיים למי שבונה אפליקציות על Kubernetes.
אני רוצה שתנסה את Linkerd - התקנת אותו באשכול Kubernetes (או אפילו Minikube במחשב נייד) ואתה יכול לראות בעצמך על מה אני מדבר.
שאלות נפוצות
- אם אתעלם מרשת השירות, היא תיעלם?
- אני חייב לאכזב אותך: רשת השירות איתנו כבר הרבה זמן.
- אבל אני לא רוצה להשתמש ברשת שירות!
- ובכן, זה לא הכרחי! פשוט קרא את השאלון שלי למעלה כדי לראות אם אתה צריך לפחות להכיר את היסודות שלו.
— האם זה לא ESB/כלי ביניים ישנים וטובים עם רוטב חדש?
- רשת שירות עוסקת בלוגיקה תפעולית, לא סמנטית. אוטובוס שירות ארגוני (). שמירה על הפרדה זו עוזרת לרשת השירות להימנע מאותו גורל.
- במה שונה רשת שירות משערי API?
יש מיליון מאמרים בנושא זה. פשוט גוגל.
האם Envoy היא רשת שירות?
- לא, Envoy היא לא רשת שירות, זה שרת פרוקסי. זה יכול לשמש כדי לארגן רשת שירות (והרבה יותר - זה פרוקסי לשימוש כללי). אבל כשלעצמו, זה לא רשת שירות.
- Network Service Mesh - האם זה רשת שירות?
- לא. למרות השם, זו לא רשת שירות (איך אתם אוהבים ניסים שיווקיים?).
- האם רשת השירות תעזור למערכת האסינכרונית התגובתית שלי המבוססת על תור הודעות?
- לא, רשת השירות לא תעזור לך.
- באיזו רשת שירות עלי להשתמש?
- , ההחלטה הקלה.
- הכתבה מבאסת! / המחבר מוזמן!
- אנא שתף את הקישור אליו עם כל החברים שלך כדי שיוכלו להשתכנע בכך!
תודות
כפי שניתן לנחש מהכותרת, מאמר זה נוצר בהשראת החיבור הפנטסטי של ג'יי קרפס "". פגשתי את ג'יי לפני עשר שנים בזמן שעשיתי ראיון ב-Linked In ומאז הוא מהווה השראה עבורי.
למרות שאני אוהב לקרוא לעצמי "מפתח Linkerd", המציאות היא שאני יותר מתחזק של הקובץ README.md בפרויקט. עובד על Linkerd היום , , אנשים, והפרויקט הזה לא היה אפשרי ללא הקהילה המדהימה של תורמים ומשתמשים.
ולבסוף, תודה מיוחדת ליוצר של Linkerd, (primus inter pares), שיחד איתי לפני שנים רבות, צלל ראש לתוך כל המהומה הזו עם רשת השירות.
נ.ב מהמתרגם
קרא גם בבלוג שלנו:
- «";
- «";
- «";
- «";
- «".
מקור: www.habr.com