4 אסטרטגיות פריסה למיקרו-שירותים גמישים

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

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

פריסות בקנריות

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

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

בדיקת A / B

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

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

פריסות כחול-ירוק

דפוס הפריסה הכחול-ירוק כולל הפעלת שתי סביבות ייצור במקביל: אחת לשחרור יציב הנוכחי (כחול) ואחת לבמה ולבצע בדיקות במהדורה הבאה (ירוק). אסטרטגיה זו מאפשרת שחרור גרסאות תוכנה מעודכנות בצורה ניתנת לחזרה. צוותי Devops יכולים להשתמש בטכניקה זו כדי להפוך הפעלות גרסאות חדשות לאוטומטיות באמצעות צינור CI / CD.

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

הצללת תנועה

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

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

ארבע אסטרטגיות, מטרה אחת

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

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

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

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

מנואל זאף הוא ראש מוצר ה- OSS בחברת Containous, חברת רשת ענן שמאחורי פרויקטי הקוד הפתוח Traefik ו- Maesh.

-

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