למה אנחנו מייצרים Enterprise Service Mesh?

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

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

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

ברמת פרוקסי (מישור נתונים):

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

ברמת מישור הבקרה:

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

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

מדוע יש צורך ב-Service Mesh במגזר העסקי?

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

בנוסף, Service Mesh מפשט את הקשר בין ספקים לצרכנים. כיום, הרבה יותר קל לספקי API ולצרכנים להסכים על ממשקים וחוזים בעצמם, מבלי לערב מתווך ובורר אינטגרציה מיוחדים - אפיק השירות הארגוני. גישה זו משפיעה באופן משמעותי על שני אינדיקטורים. מהירות הבאת פונקציונליות חדשה לשוק (Time-to-Market) עולה, אך במקביל עלות הפתרון עולה, שכן האינטגרציה צריכה להיעשות באופן עצמאי. השימוש ב-Service Mesh על ידי צוותי פיתוח פונקציונליות עסקית עוזר לשמור על איזון כאן. כתוצאה מכך, ספקי API יכולים להתמקד אך ורק ברכיב האפליקציה של השירות שלהם ופשוט לפרסם אותו ב-Service Mesh - ה-API יהפוך מיידית לזמין לכל הלקוחות, ואיכות האינטגרציה תהיה מוכנה לייצור ולא תדרוש אף אחד שורת קוד נוסף.

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

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

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

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

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

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

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

למה אתה צריך התאמה אישית של Service Mesh?

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

שירות עיבוד אירועים

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

זה די מוזר ש-Remote Procedure Call (RPC) נתמך על ידי כל הגרסאות של Service Mesh, אבל הם לא ידידותיים ל-EDA. כי Service Mesh הוא סוג של אינטגרציה מבוזרת מודרנית, ו-EDA הוא דפוס ארכיטקטוני מאוד רלוונטי שמאפשר לך לעשות דברים ייחודיים מבחינת חווית הלקוח.

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

שירות העברת קבצים

בנוסף ל-EDA, זה יהיה נחמד להיות מסוגל להעביר קבצים: בקנה מידה Enterprise, לעתים קרובות רק שילוב קבצים אפשרי. בפרט, נעשה שימוש בתבנית האדריכלית ETL (חילוץ, טרנספורמציה, עומס). בו, ככלל, כולם מחליפים קבצים באופן בלעדי: נעשה שימוש ב-Big Data, מה שלא מעשי לדחוף פנימה בקשות נפרדות. היכולת לתמוך באופן מקורי בהעברת קבצים ב- Enterprise Service Mesh מעניקה לך את הגמישות שהעסק שלך צריך.

שירות תזמור

לארגונים גדולים יש כמעט תמיד צוותים שונים שמייצרים מוצרים שונים. למשל, בבנק יש צוותים שעובדים עם פיקדונות, בעוד שאחרים עובדים עם מוצרי הלוואות, ויש לא מעט מקרים כאלה. אלה אנשים שונים, צוותים שונים שמייצרים את המוצרים שלהם, מפתחים את ממשקי ה-API שלהם ומספקים אותם לאחרים. ולעתים קרובות מאוד יש צורך להרכיב את השירותים הללו, כמו גם ליישם לוגיקה מורכבת לקריאה ברצף לסט של ממשקי API. כדי לפתור את הבעיה הזו צריך פתרון בשכבת האינטגרציה שיפשט את כל ההיגיון המרוכב הזה (קריאה למספר APIs, תיאור מסלול הבקשה וכו'). זהו שירות התזמור ב-Enterprise Service Mesh.

AI ו-ML

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

שירות שער API

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

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

שירות תמיכה לפרוטוקולים ותבניות נתונים ספציפיים (שער AS)

נכון לעכשיו, רוב פתרונות Service Mesh יכולים לעבוד באופן מקורי רק עם תעבורת HTTP ו-HTTP2 או במצב מופחת ברמת TCP/IP. ה-Enterprise Service Mesh מתהווה עם פרוטוקולי העברת נתונים רבים אחרים מאוד ספציפיים. מערכות מסוימות עשויות להשתמש במתווכים של הודעות, אחרות משולבות ברמת מסד הנתונים. אם לחברה יש SAP, היא יכולה גם להשתמש במערכת אינטגרציה משלה. יתרה מכך, כל זה עובד ומהווה חלק חשוב מהעסק.

אתה לא יכול פשוט לומר: "בואו נטוש את המורשת וניצור מערכות חדשות שיכולות להשתמש ב-Service Mesh." כדי לחבר את כל המערכות הישנות עם החדשות (בארכיטקטורת מיקרו-שירות), מערכות שיכולות להשתמש ב-Service Mesh יצטרכו סוג של מתאם, מתווך, שער. מסכים, זה יהיה נחמד אם זה מגיע בקופסה יחד עם השירות. שער AC יכול לתמוך בכל אפשרות אינטגרציה. רק תאר לעצמך, אתה פשוט מתקין Enterprise Service Mesh והוא מוכן לאינטראקציה עם כל הפרוטוקולים שאתה צריך. גישה זו חשובה לנו מאוד.

כך בערך אנחנו מדמיינים את הגרסה הארגונית של Service Mesh (Enterprise Service Mesh). ההתאמה האישית המתוארת פותרת את רוב הבעיות המתעוררות כאשר מנסים להשתמש בגרסאות קוד פתוח מוכנות של פלטפורמת האינטגרציה. ארכיטקטורת Service Mesh, שהוצגה רק לפני שנתיים, ממשיכה להתפתח, ואנו נרגשים להיות מסוגלים לתרום לפיתוחה. אנו מקווים שהניסיון שלנו יועיל לך.

מקור: www.habr.com