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

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

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

את המצב מתמצה בצורה הטובה ביותר בסדרת הציוצים הבאה שכתבתי ביולי:

בלבול רשת שירות מס' 1: Linkerd ~ = Nginx ~ = Haproxy ~ = שליח. אף אחד מהם לא שווה לאיסטיו. איסטיו זה משהו אחר לגמרי. 1 /

הראשונים הם פשוט מטוסי נתונים. לבד הם לא עושים כלום. הם בטח במצב רוח למשהו נוסף. 2/

Istio הוא דוגמה למישור בקרה הקושר את החלקים יחד. זוהי שכבה נוספת. /סוֹף

הציוצים הקודמים מזכירים כמה פרויקטים שונים (Linkerd, NGINX, HAProxy, Envoy ו-Istio), אך חשוב מכך מציגים את המושגים הכלליים של מישור נתונים, רשת שירות ומישור בקרה. בפוסט הזה אקח צעד אחורה ואדבר על מה אני מתכוון במונחים "מישור נתונים" ו"מטוס בקרה" ברמה גבוהה מאוד, ואז אדבר על איך התנאים חלים על הפרויקטים המוזכרים בטוויטים.

מהי בעצם רשת שירות?

איור 1: סקירת רשת שירות

האיור 1 ממחיש את הרעיון של רשת שירות ברמה הבסיסית ביותר שלה. ישנם ארבעה אשכולות שירות (AD). כל מופע שירות משויך לשרת proxy מקומי. כל תעבורת הרשת (HTTP, REST, gRPC, Redis וכו') ממופע אפליקציה בודד מועברת דרך פרוקסי מקומי לאשכולות השירות החיצוניים המתאימים. בדרך זו, מופע האפליקציה אינו מודע לרשת כולה ורק מודע ל-proxy המקומי שלו. למעשה, רשת המערכת המבוזרת הוסרה מהשירות.

מישור נתונים

ברשת שירות, שרת פרוקסי הממוקם באופן מקומי עבור האפליקציה מבצע את המשימות הבאות:

• גילוי שירות. אילו שירותים/אפליקציות זמינים עבור האפליקציה שלך?
• בדיקת בריאות. האם מופעי השירות שהוחזרו על ידי גילוי שירות בריאים ומוכנים לקבל תעבורת רשת? זה יכול לכלול בדיקות בריאות אקטיביות (למשל תגובה/בדיקת בריאות) ופסיביות (למשל שימוש ב-3 שגיאות 5xx רצופות כאינדיקציה למצב שירות לא בריא).
• ניתוב. כאשר מקבלים בקשה ל-"/foo" משירות REST, לאיזה אשכול שירותים יש לשלוח את הבקשה?
• איזון עומסים. לאחר בחירת אשכול שירותים במהלך הניתוב, לאיזה מופע שירות יש לשלוח את הבקשה? עם איזה פסק זמן? עם אילו הגדרות פריצת מעגל? אם הבקשה נכשלת, האם לנסות אותה שוב?
• אימות והרשאה. האם עבור בקשות נכנסות, האם ניתן לזהות/ לאשר את השירות המתקשר באמצעות mTLS או מנגנון אחר? אם הוא מזוהה/מורשה, האם מותר להתקשר לפעולה המבוקשת (נקודת הקצה) בשירות או שיש להחזיר תגובה לא מאומתת?
• יכולת תצפית. יש להפיק נתונים סטטיסטיים מפורטים, יומנים/יומנים ונתוני מעקב מבוזרים עבור כל בקשה, כך שהמפעילים יוכלו להבין זרימת תעבורה מבוזרת ובעיות ניפוי באגים כשהן מתעוררות.

מישור הנתונים אחראי על כל הנקודות הקודמות ברשת השירות. למעשה, ה-Proxy המקומי לשירות (Sidecar) הוא מישור הנתונים. במילים אחרות, מישור הנתונים אחראי על שידור מותנה, העברה וניטור של כל חבילת רשת שנשלחת לשירות או ממנו.

מטוס הבקרה

הפשטת הרשת שפרוקסי מקומי מספק במישור הנתונים היא קסומה(?). עם זאת, כיצד למעשה יודע ה-Proxy על המסלול "/foo" לשירות B? כיצד ניתן להשתמש בנתוני גילוי השירות המאוכלסים בבקשות proxy? כיצד מוגדרים הפרמטרים לאיזון עומסים, פסק זמן, שבירת מעגל וכו'? איך פורסים אפליקציה בשיטת כחול/ירוק או בשיטת המעבר לתעבורה חיננית? מי מגדיר את הגדרות האימות וההרשאה בכל המערכת?

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

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

איור 2: מטוס שליטה אנושי

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

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

איור 3: מטוס בקרה של רשת שירות מתקדמת

על איור 3 מציג את מישור הבקרה ה"מורחב" של רשת השירות. הוא מורכב מהחלקים הבאים:

• האדם: עדיין יש אדם (בתקווה שפחות כועס) שמקבל החלטות ברמה גבוהה לגבי המערכת כולה.
• ממשק משתמש במטוס בקרה: אדם מקיים אינטראקציה עם סוג כלשהו של ממשק משתמש כדי לשלוט במערכת. זה יכול להיות פורטל אינטרנט, יישום שורת פקודה (CLI) או ממשק אחר. באמצעות ממשק המשתמש, למפעיל יש גישה לפרמטרים גלובליים של תצורת המערכת כגון:
  • בקרת פריסה, כחול/ירוק ו/או מעבר תנועה הדרגתי
  • אפשרויות אימות והרשאה
  • מפרטי טבלת ניתוב, למשל כאשר אפליקציה A מבקשת מידע על "/foo" מה קורה
  • הגדרות איזון עומסים, כגון פסקי זמן, ניסיונות חוזרים, הגדרות שבירת מעגלים וכו'.
• מתזמן עומסי עבודה: השירותים מופעלים על התשתית באמצעות סוג כלשהו של מערכת תזמון/תזמור, כגון Kubernetes או Nomad. המתזמן אחראי לטעינת השירות יחד עם ה-proxy המקומי שלו.
• גילוי שירות. כאשר המתזמן מתחיל ומפסיק מופעי שירות, הוא מדווח על מצב הבריאות למערכת גילוי השירות.
• ממשקי API של תצורת Proxy Sidecar : פרוקסי מקומיים מחלצים באופן דינמי מצב ממרכיבי מערכת שונים תוך שימוש במודל עקבי בסופו של דבר ללא התערבות מפעיל. המערכת כולה, המורכבת מכל מופעי השירות הפועלים כעת ושרתי פרוקסי מקומיים, מתכנסת בסופו של דבר לאקוסיסטם אחד. ממשק ה-API של מטוס הנתונים האוניברסלי של Envoy הוא דוגמה אחת לאופן שבו זה עובד בפועל.

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

מישור נתונים ומישור בקרה. סיכום מישור נתונים לעומת מישור בקרה

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

נוף הפרויקט הנוכחי

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

• מטוסי נתונים: Linkerd, NGINX, HAProxy, Envoy, Traefik
• שליטה במטוסים: Istio, Nelson, SmartStack

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

Linkerd היה אחד משרתי ה-Proxy של מטוס הנתונים הראשונים עבור רשת השירות בתחילת 2016 ועשה עבודה נפלאה בהעלאת המודעות ותשומת הלב למודל עיצוב רשת השירות. כ-6 חודשים לאחר מכן, Envoy הצטרף ל-Linkerd (אם כי הוא היה עם Lyft מאז סוף 2015). Linkerd ו-Envoy הם שני הפרויקטים המוזכרים לרוב כאשר דנים ברשתות שירות.

Istio הוכרז במאי 2017. המטרות של פרויקט Istio דומות מאוד למישור הבקרה המורחב המוצג איור 3. Envoy for Istio הוא ה-proxy ברירת המחדל. לפיכך, Istio הוא מישור הבקרה, ו-Envoy הוא מישור הנתונים. תוך זמן קצר, Istio יצרה התרגשות רבה, ומטוסי נתונים אחרים החלו להשתלב כתחליף ל-Envoy (גם Linkerd וגם NGINX הדגימו אינטגרציה עם Istio). העובדה שניתן להשתמש במישורי נתונים שונים בתוך אותו מישור בקרה פירושה שמישור הבקרה ומישור הנתונים אינם בהכרח מחוברים בצורה הדוקה. API כגון ה-API הגנרי של מטוס הנתונים של Envoy יכול ליצור גשר בין שני חלקים של המערכת.

נלסון ו-SmartStack עוזרים להמחיש עוד יותר את ההפרדה בין מישור הבקרה למישור הנתונים. נלסון משתמש ב-Envoy כפרוקסי שלו ובונה מישור בקרה אמין עבור רשת השירות המבוססת על מחסנית HashiCorp, כלומר. נווד וכו'. SmartStack היה אולי הראשון מתוך גל חדש של רשתות שירות. SmartStack בונה מישור בקרה סביב HAProxy או NGINX, ומדגים את היכולת לנתק את מישור הבקרה מרשת השירות ממישור הנתונים.

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

טייק אווי מפתח

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

מקור: www.habr.com