שיטות מומלצות לשימוש בשירות רשמי (קנוני)
הערה: שירותים קנוניים נתמכים באופן אוטומטי ב-Cloud Service Mesh מגרסה 1.6.8 ואילך.
שירותים קנוניים מאפשרים לכם לנווט בין הרבה הגדרות שונות. כדי ליהנות מחוויית שימוש מיטבית בלוחות הבקרה של Cloud Service Mesh Service, מומלץ לפעול לפי השיטות המומלצות הבאות כשמגדירים את השירותים:
- שמירת שירות ייחודי [מרחב שמות, שם] בכל הרשת.
- הגדרת אפליקציית תוכנה אחת לכל שירות קנוני.
- לא לקבץ שירותים רשמיים (קנוניים) בסביבות שונות (לדוגמה, prod/stage/dev).
- שימוש בלוחות בקרה של Cloud Monitoring לתצוגות ברמה גבוהה יותר של כמה שירותים.
- מומלץ לתכנן ששירותים קנוניים יפעלו לאורך זמן בסביבת הייצור.
שמירת שירות ייחודי [מרחב שמות, שם] בכל ה-mesh
אם שירות קנוני שנפרס באשכול או באזור מסוים כולל את אותו מרחב שמות של Kubernetes ואת אותו שם של שירות קנוני כמו שירות שנפרס באשכול או באזור אחר, Cloud Service Mesh מניח שמדובר באותו שירות לוגי.
ההתנהגות הזו עקבית עם העיקרון של "זהות" בצי, שלפיו למרחב שמות צריך להיות אותו משמעות והוא צריך לייצג את אותו ישות בכל הצי.
אפליקציית תוכנה אחת לכל שירות רשמי (קנוני)
שירותים רשמיים (קנוניים) נועדו לייצג שירות לוגי יחיד או מיקרו-שירות. הם נועדו לכלול קבצים בינאריים או עומסי עבודה הומוגניים שמייצגים את אותה אפליקציית תוכנה ואת אותה פונקציה עסקית.
אפשר להגדיר שירות קנוני כדי לקבץ כמה מיקרו-שירותים שונים מבחינה רעיונית, אבל במקרה כזה לוחות הבקרה של השירותים לא יספקו את הערך המלא שלהם.בלוחות הבקרה של השירותים יוצג צבירה של רכיבים שונים, שכל אחד מהם עשוי לפעול ולהיות מוגדר בצורה שונה מאוד. יהיה קשה או אפילו בלתי אפשרי להבין את המצב, הביצועים וההגדרות של כל המערכת.
הדברים הבאים הם לא בהכרח שיטות עבודה לא טובות, אבל יכול להיות שהשירות הקנוני שלכם גדול מדי אם:
- יש תנועת רשת בין עומסי עבודה שונים במסגרת שירות קנוני יחיד.
- שירות קנוני כולל כמה עומסי עבודה שנפרסים בלוחות זמנים שונים של מהדורות.
- צוותים שונים בארגון אחראים להפעלה של חלקים שונים בשירות קנוני יחיד.
לא לקבץ שירות רשמי (קנוני) בסביבות שונות
ארגונים טכנולוגיים רבים משתמשים בכמה סביבות פריסה כדי להבטיח את איכות התוכנה ולצמצם את הסיכון. הסביבות האלה כוללות לרוב dev, test, staging, prod או קבוצת משנה כלשהי.
גם אם אתם פורסים את אותו שירות קונספטואלי בכל אחד מהסביבות השונות שלכם, לא מומלץ להגדיר אותם כשירות קנוני יחיד. השירותים האלה לא זהים, והם לא מייצגים את אותה רמה של דאגה או התמקדות תפעולית בארגון שלכם.
לדוגמה, כשל בשירות ייצור קריטי עלול לגרום לבעיות בדפים בשעה 3 לפנות בוקר ולמצבי חירום. אתם לא רוצים שאף אחד יקבל התראה אם הפריסה של 'פיתוח' תיכשל באמצע הלילה. הדבר נכון גם לגבי הבנת הביצועים, הקיבולת והבטיחות של הגרסה.
יש שלוש דרכים להפריד בין שירותים לסביבות שונות, מהדרך הקלה ביותר אבל הכי פחות מדויקת, ועד לדרך שדורשת הכי הרבה מאמץ אבל היא הכי יעילה:
- אם רוצים להפריד בין כמה שמות שירותים, למשל,
payments-prodו-payments-test. - אפשר להשתמש בכמה מרחבי שמות, למשל
billing-teamו-billing-team-test. - הפרדה באמצעות כמה ציים, אחד לכל סביבה.
מומלץ להשתמש בלוחות בקרה מותאמים אישית ב-Cloud Monitoring לצורך צבירות שרירותיות
במקום להגדיל באופן מלאכותי את היקף השירותים הקנוניים כדי להציג נתונים מצטברים, אפשר להשתמש בלוחות בקרה של Cloud Monitoring כדי ליצור תצוגות ברמה גבוהה יותר של כמה שירותים לוגיים בו-זמנית.
שירותים רשמיים (קנוניים) מיועדים לפעול לאורך זמן
במקרים שאינם פיתוח, בדיקה או חיפוש, שירותים קנוניים צריכים לייצג שירותים לוגיים גלובליים ברמה גבוהה. השירותים האלה משתנים לאט, והם בדרך כלל קיימים לאורך זמן. האריכות הזו כוללת את העובדה שלא משנים את שמות השירותים. אפשר לשנות את השמות שלהם, אבל שינוי כזה משפיע על מדדים, על SLO ועל יומנים. עם זאת, אפשר לשנות את השדה Display name בלי שזה יפריע.
שירות קנוני חדש מייצג בדרך כלל תוכנה חדשה או מעודכנת, ושירות קנוני שיוצא משימוש מייצג בדרך כלל הוצאה משימוש של שירות. היכולת שלכם לראות את היסטוריית הביצועים של השירות, התוכנית והקיבולת של הפרויקט תלויה בשמירה על מושג יחיד של השירות ב-Cloud Service Mesh למשך כל משך החיים שלו.
שימו לב שהמצב שונה ממשאבים ברמה נמוכה יותר, כמו מכונות וירטואליות, Pods/Deployments של Kubernetes ואפילו אשכולות שלמים, שלעתים קרובות מתווספים ומוסרים כחלק מעדכון ומאחזקה של מערכות ייצור.