שוב שלום!.. ערב תחילת הקורס הכנו תרגום שימושי נוסף.
רשת שירות היא שכבת תשתית ניתנת להגדרה, עם אחזור נמוך, הדרושה לטיפול בכמויות גדולות של תקשורת בין-תהליכים מבוססת רשת בין ממשקי תכנות יישומים (API). Service Mesh מאפשרת תקשורת מהירה, אמינה ומאובטחת בין שירותי תשתית אפליקציות מכולות ולעתים קרובות ארעיות. Service Mesh מספק יכולות כגון גילוי שירות, איזון עומסים, הצפנה, שקיפות, מעקב, אימות והרשאה ותמיכה בדפוסי כיבוי אוטומטי (מפסק).
רשת שירות מיושמת בדרך כלל על ידי מתן כל מופע שירות עם מופע proxy, הנקרא קרונית צד. קרונית צד לטפל בתקשורת בין שירותים, לפקח ולפתור בעיות אבטחה, כלומר כל מה שניתן להפשט משירותים בודדים. בדרך זו, מפתחים יכולים לכתוב, לתחזק ולהגיש קוד יישומים בשירותים, ומנהלי מערכת יכולים לעבוד עם ה-Service Mesh ולהפעיל את האפליקציה.
Istio מ-Google, IBM ו- Lyft היא כיום ארכיטקטורת רשת השירות המפורסמת ביותר. ו-Kubernetes, שפותחה במקור בגוגל, היא כעת המסגרת היחידה לתזמורת קונטיינר הנתמכת על ידי Istio. ספקים מנסים ליצור גרסאות נתמכות מסחרית של Istio. יהיה מעניין לראות אילו דברים חדשים הם יכולים להביא לפרויקט הקוד הפתוח.
עם זאת, Istio היא לא האפשרות היחידה שכן יישומי Service Mesh אחרים מפותחים. תבנית sidecar proxy הוא היישום הפופולרי ביותר, כפי שניתן לשפוט לפי הפרויקטים Buoyant, HashiCorp, Solo.io ואחרים. יש גם ארכיטקטורות חלופיות: ערכת הכלים הטכנולוגית של Netflix היא אחת הגישות שבהן מיושמת פונקציונליות ה-Service Mesh באמצעות ספריות Ribbon, Hysterix, Eureka, Archaius, כמו גם פלטפורמות כמו Azure Service Fabric.
ל-Service Mesh יש גם טרמינולוגיה משלה עבור רכיבי שירות ופונקציות:
- מסגרת תזמור מכולות. ככל שמתווספים יותר ויותר קונטיינרים לתשתית האפליקציה, יש צורך בכלי נפרד לניטור וניהול קונטיינרים – מסגרת תזמורת קונטיינרים. Kubernetes כבשה היטב את הנישה הזו, עד כדי כך שאפילו המתחרות העיקריות שלה Docker Swarm ו-Mesosphere DC/OS מציעות אינטגרציה עם Kubernetes כחלופה.
- שירותים ומופעים (Kubernetes Pods). מופע הוא עותק פועל יחיד של שירות מיקרו. לפעמים מופע אחד הוא מיכל אחד. ב-Kubernetes, מופע מורכב מקבוצה קטנה של מיכלים עצמאיים הנקראים תרמיל. לקוחות ממעטים לגשת ישירות למופע או לפוד; לעתים קרובות יותר, הם ניגשים לשירות, שהוא קבוצה של מופעים זהים, ניתנים להרחבה וסובלני תקלות (עותקים).
- Proxy Sidecar. Sidecar Proxy עובד עם מופע בודד או פוד. המטרה של Sidecar Proxy היא לנתב תעבורה או פרוקסי שמגיעה מהמכולה איתו היא עובדת ולהחזיר תעבורה. Sidecar מקיים אינטראקציה עם Proxies Sidecar אחרים ומנוהל על ידי מסגרת תזמורת. יישומי Service Mesh רבים משתמשים ב-Sidecar Proxy כדי ליירט ולנהל את כל התעבורה פנימה ומחוץ למופע או פוד.
- גילוי שירות. כאשר מופע צריך לתקשר עם שירות אחר, הוא צריך למצוא (לגלות) מופע בריא וזמין של השירות האחר. בדרך כלל, המופע מבצע חיפושי DNS. מסגרת התזמורת של מיכל שומרת על רשימה של מופעים שמוכנים לקבל בקשות ומספקת ממשק לשאילתות DNS.
- איזון עומסים. רוב מסגרות תזמור המכולות מספקות איזון עומסים בשכבה 4 (הובלה). Service Mesh מיישמת איזון עומסים מורכב יותר בשכבה 7 (רמת אפליקציה), עשירה באלגוריתמים ויעילה יותר בניהול תעבורה. ניתן לשנות את הגדרות איזון העומס באמצעות ה-API, המאפשר לך לתזמן פריסות כחול-ירוק או קנרי.
- Шифрование. Service Mesh יכול להצפין ולפענח בקשות ותגובות, ולהסיר נטל זה מהשירותים. Service Mesh יכול גם לשפר את הביצועים על ידי תעדוף או שימוש חוזר בחיבורים מתמשכים קיימים, ולהפחית את הצורך בחישוב יקר ליצירת קשרים חדשים. היישום הנפוץ ביותר של הצפנת תעבורה הוא TLS הדדי (mTLS), שבו תשתית מפתח ציבורי (PKI) מייצרת ומפיצה אישורים ומפתחות לשימוש על ידי Sidecar Proxy.
- אימות והרשאה. רשת השירות יכולה לאשר ולאמת בקשות שנעשות מבחוץ או בתוך האפליקציה, ולשלוח רק בקשות מאומתות למופעים.
- תמיכה בדפוסי כיבוי אוטומטי. Service Mesh תומך , המבודד מקרים לא בריאים ואז מחזיר אותם בהדרגה למאגר המקרים הבריאים בעת הצורך.
החלק של יישום Service Mesh שמנהל תעבורת רשת בין מופעים נקרא מטוס נתונים. צור ופרוס תצורה השולטת בהתנהגות מטוס נתונים, מבוצע באמצעות נפרד מטוס בקרה. מטוס בקרה בדרך כלל כולל או מתוכנן להתחבר ל-API, CLI או GUI כדי לשלוט באפליקציה.
מישור הבקרה ב-Service Mesh מפיץ את התצורה בין ה-Sidecar Proxy למישור הנתונים.
ארכיטקטורת Service Mesh משמשת לעתים קרובות לפתרון בעיות תפעוליות מורכבות באמצעות קונטיינרים ומיקרו-שירותים. חלוצים בתחום הן חברות כמו Lyft, Netflix וטוויטר, המספקות שירותים יציבים למיליוני משתמשים ברחבי העולם. (). עבור יישומים פחות תובעניים, ארכיטקטורות פשוטות יותר יספיקו ככל הנראה.
סביר להניח שארכיטקטורת Service Mesh לא תהיה התשובה לכל בעיות תפעול ואספקה של אפליקציות. לאדריכלים וליזמים יש ארסנל עצום של כלים, ורק אחד מהם הוא פטיש, שבין הרבה משימות חייב לפתור רק אחת - פטישת מסמרים. , למשל, כולל מספר מודלים שונים המספקים רצף של גישות לפתרון בעיות באמצעות שירותי מיקרו.
האלמנטים שמתחברים יחד בארכיטקטורת Service Mesh, כגון NGINX, קונטיינרים, Kubernetes ומיקרו-שירותים כגישה ארכיטקטונית, יכולים להיות פרודוקטיביים באותה מידה בהטמעות שאינן שירות Mesh. לדוגמה, Istio תוכננה כארכיטקטורת רשת שירות מלאה, אך המודולריות שלה פירושה שמפתחים יכולים לבחור וליישם רק את רכיבי הטכנולוגיה שהם צריכים. עם זאת בחשבון, חשוב לפתח הבנה ברורה של תפיסת השירות Mesh, גם אם אינך בטוח שאי פעם תוכל ליישם אותה במלואה באפליקציה שלך.
מקור: www.habr.com