הערה. תרגוםמחבר המאמר הזה (לוק פרקינס) הוא תומך מפתחים ב-CNCF, ביתם של פרויקטים בקוד פתוח כמו Linkerd, SMI (Service Mesh Interface) ו-Kuma (אגב, האם גם אתם תהיתם מדוע Istio לא ברשימה הזו?...). בניסיון נוסף להביא הבנה טובה יותר של ההייפ הטרנדי שנקרא "service mesh" לקהילת DevOps, הוא מפרט 16 יכולות אופייניות שפתרונות כאלה מספקים.
היום ― הוא אחד הנושאים החמים ביותר בהנדסת תוכנה (ובצדק!). אני חושב שזו טכנולוגיה מבטיחה להפליא ואני חולם לראות אותה מאומצת באופן נרחב (כשזה הגיוני, כמובן). עם זאת, עדיין יש לה הילה של מסתורין עבור רוב האנשים. אפילו אלה ש... אני מכיר אותו היטב איתו, לעתים קרובות מתקשים לנסח את יתרונותיו ומה בדיוק הוא (כולל עבדכם הנכבד). במאמר זה, אנסה לתקן את המצב על ידי רישום מגוון תרחישי שימוש "רשתות שירות"*.
* הערת המתרגם: מעתה ואילך במאמר זה, תרגום זה ("service mesh") ישמש עבור המונח החדש עדיין service mesh.
אבל קודם כל אני רוצה להעיר כמה הערות:
- מעולם לא עבדתי או השתמשתי ברשתות שירות מחוץ לפרויקטים שביצעת עבור החינוך שלי. מצד שני, כתבתי המון תיעוד עבור רשת השירות הפנימית של טוויטר בשנת 2015 (היא אפילו לא נקראה אז "רשת שירות") ותרמתי לאתר ולתיעוד עבור... , אז זה אומר משהו.
- הרשימה שלי היא זמנית ולא שלמה. סביר להניח שיהיו מקרי שימוש שאני לא מודע להם, וסביר להניח שיצוצו מקרי שימוש חדשים עם הזמן ככל שהטכנולוגיה תתפתח ותהפוך לפופולרית יותר.
- יחד עם זאת, לא כל יישום רשת שירותים קיים תומך בכל מקרי השימוש המפורטים. לכן, יש לקרוא את ההצהרות שלי כמו "רשת שירותים יכולה..." כ"חלק, ואולי כל, מימושי רשת שירותים פופולריים יכולים...".
- סדר הדוגמאות לא משנה.
רשימה קצרה:
- גילוי שירותים;
- הצפנה;
- אימות והרשאה;
- איזון עומסים;
- שבירת מעגל חשמלי;
- קנה מידה אוטומטי;
- פריסות קנריות;
- פריסות כחולות-ירוקות;
- בדיקת בריאות;
- ניתוק עומסים;
- שיקוף תנועה;
- בִּדוּד;
- הגבלת קצב בקשות, ניסיונות חוזרים ופסקי זמן;
- טלמטריה;
- בְּדִיקָה;
- רְאִיָה.
1. גילוי שירותים
בקיצור: התחבר לשירותים אחרים ברשת באמצעות שמות פשוטים.
שירותים צריכים להיות מסוגלים "למצוא" זה את זה באופן אוטומטי באמצעות שמות מתאימים, כגון service.api.production, pets/staging או cassandraסביבות ענן מאופיינות בגמישות שלהן, ושם אחד יכול להסתיר מספר מופעי שירות. ברור שבמצב כזה בלתי אפשרי פיזית לקודד את כל כתובות ה-IP.
בנוסף, כאשר שירות אחד מוצא אחר, הוא אמור להיות מסוגל לשלוח בקשות לשירות זה ללא חשש שהן יגיעו לקלט של המופע הפגום שלו. במילים אחרות, רשת השירות צריכה לנטר את תקינות כל מופעי השירות ולשמור על רשימת המארחים מעודכנת ככל האפשר.
כל רשת שירותים מיישמת גילוי שירותים בצורה שונה. נכון לעכשיו, הדרך הנפוצה ביותר היא להאציל סמכויות לתהליכים חיצוניים כמו Kubernetes DNS. בעבר, בטוויטר, השתמשנו במערכת שמות למטרה זו. בנוסף, טכנולוגיית רשת השירותים מאפשרת ליצור מנגנוני מתן שמות מותאמים אישית (אם כי עדיין לא נתקלתי במימוש SM עם פונקציונליות כזו).
2. הצפנה
בקיצור: להיפטר מתעבורה לא מוצפנת בין שירותים ולהפוך את התהליך הזה לאוטומטי וניתן להרחבה.
נחמד לדעת שתוקפים לא יכולים לחדור לרשת הפנימית שלך. חומות אש עושות עבודה מצוינת במניעת זה. אבל מה קורה אם האקר אכן חודר? האם הוא יוכל לעשות מה שהוא רוצה עם התעבורה התוך-שירותית? בואו נקווה שזה לא יקרה. כדי למנוע תרחיש כזה, עליך ליישם רשת אמון אפס, שבה כל התעבורה בין שירותים מוצפנת. רוב רשתות השירות המודרניות משיגות זאת באמצעות שיתוף פעולה הדדי. (TLS הדדי, mTLS). במקרים מסוימים, mTLS עובד בעננים ובאשכולות שלמים (אני חושב שיום אחד התקשורת הבין-פלנטרית תתארגן באופן דומה).
כמובן, עבור רשת שירות mTLS אופציונליכל שירות יכול לטפל ב-TLS משלו, אבל זה אומר למצוא דרך לייצר אישורים, להפיץ אותם בין מארחי שירותים, לכלול קוד ביישום שיטען את האישורים האלה מהקבצים. אה, ואל תשכחו לחדש את האישורים האלה במרווחי זמן קבועים. רשתות שירות הופכות mTLS לאוטומטיות עם מערכות כמו , אשר בתורן הופכות את תהליך הנפקת וסבב התעודות לאוטומטי.
3. אימות והרשאה
בקיצור: קבע מי יוזם את הבקשה וקבע מה מותר לו לעשות עוד לפני שהבקשה מגיעה לשירות.
שירותים לעתים קרובות רוצים לדעת, מי מגיש בקשה (אימות) ובאמצעות מידע זה, מחליט כי לנושא זה מותר לעשות (אישור). במקרה זה, הכינוי "מי" עשוי להסתתר:
- שירותים אחרים. זה נקרא "אימות" עמית"לדוגמה, שירות
webרוצה לגשת לשירותdbרשתות שירות בדרך כלל פותרות בעיות כאלה באמצעות mTLS: אישורים במקרה זה משמשים כמזהה הכרחי. - חלק מהמשתמשים האנושיים. זה נקרא "אימות" בקשות"לדוגמה, המשתמש
haxor69רוצה לקנות מנורה חדשה. רשתות שירות מספקות מנגנונים שונים, כגון .רבים מאיתנו עשו זאת בקוד האפליקציה שלנו. בקשה מגיעה, אנחנו מסתכלים על טבלה
users, מצא את המשתמש והשווה את הסיסמה, לאחר מכן בדוק את העמודהpermissionsוכו'. במקרה של רשת שירות, זה קורה עוד לפני שהבקשה מגיעה לשירות.
לאחר שקבענו ממי הגיעה הבקשה, עלינו לקבוע מה מותר לאובייקט לעשות. חלק מרשתות השירות מאפשרות לך להגדיר מדיניות בסיסית (לגבי מי יכול לעשות מה) כקבצי YAML או בשורת הפקודה, בעוד שאחרות מציעות אינטגרציה עם מסגרות כמו המטרה הסופית היא שהשירותים שלכם יקבלו כל בקשה בביטחון שהיא מגיעה ממקור אמין. и פעולה זו מותרת.
4. איזון עומסים
בקיצור: פזרו את העומס בין מופעי השירות לפי דפוס מסוים.
"שירות" בסעיף השירות מורכב לעתים קרובות מעותקים זהים רבים. לדוגמה, כיום השירות cache מורכב מ-5 עותקים, ומחר מספרם עשוי לעלות ל-11. בקשות נשלחות אל cache, צריך להיות מופץ לפי מטרה ספציפית. לדוגמה, כדי למזער את ההשהיה או כדי למקסם את ההסתברות להגיע למופע פעיל. האלגוריתם הנפוץ ביותר הוא אלגוריתם שירות Round-robin, אך ישנם רבים אחרים, כגון אלגוריתם השירות המשוקלל (מְשׁוּקלָל) שאילתות (ניתן לבחור יעדים מועדפים), צלצול (טַבַּעַת) גיבוב (השתמש בגיבוב עקבי עבור מארחים במעלה הזרם) או שיטת השאילתות הנמוכות ביותר (ניתנת עדיפות למופע עם מספר השאילתות הנמוך ביותר).
למאזני עומסים קלאסיים יש תכונות נוספות, כגון אחסון במטמון HTTP והגנה מפני DDoS, אך הן אינן רלוונטיות במיוחד לתעבורה ממזרח למערב (היישום הטיפוסי של רשת שירותים). כמובן, אין צורך בהכרח להשתמש ברשת שירותים לאיזון עומסים, אך היא מאפשרת לך להגדיר ולשלוט במדיניות איזון עומסים עבור כל שירות ממישור בקרה מרכזי, ובכך מבטלת את הצורך להפעיל ולקבוע תצורה של מאזני עומסים נפרדים במחסנית הרשת.
5. ניתוק מעגל
בקיצור: עצירת התנועה לשירות הבעייתי ושליטה בנזק בתרחישים הגרועים ביותר.
אם מסיבה כלשהי השירות אינו יכול להתמודד עם התעבורה, רשת השירות מספקת מספר אפשרויות לפתרון בעיה זו (אחרות יידונו בסעיפים הרלוונטיים). ניתוק מעגלים חשמליים הוא האפשרות החמורה ביותר לניתוק השירות מתעבורה. עם זאת, אין בכך היגיון בפני עצמו - יש צורך בתוכנית גיבוי. ניתן לספק לחץ אחורי. () לשירותים שמבצעים בקשות (רק זכרו להגדיר את רשת השירות שלכם לכך!), או, לדוגמה, צביעת דף הסטטוס באדום והפניית משתמשים לגרסה הבאה של הדף עם "הלוויתן הנופל" ("טוויטר מושבת").
רשתות שירות לא רק מאפשרות לך לקבוע, שם תתרחש השבתה ולאחר מכן כי יבוא בעקבותיו. במקרה זה, "כאשר" יכול לכלול כל שילוב של פרמטרים שצוינו: המספר הכולל של בקשות לתקופה מסוימת, מספר החיבורים המקבילים, בקשות ממתינות, ניסיונות חוזרים פעילים וכו'.
כנראה שלא תרצו להשתמש יתר על המידה בניתוק מעגלים, אבל נחמד לדעת שיש לכם תוכנית גיבוי למקרה חירום.
6. קנה מידה אוטומטי
בקיצור: הגדלה או הקטן של מספר מופעי השירות בהתבסס על קריטריונים שצוינו.
רשתות שירות אינן מתזמנות, ולכן הן לא לְבַצֵעַ קנה מידה בכוחות עצמם. עם זאת, הם יכולים לספק מידע שמתכננים יכולים להשתמש בו כדי לקבל החלטות. מכיוון שלרשתות שירות יש גישה לכל התעבורה בין שירותים, יש להם שפע של מידע על מה שקורה: אילו שירותים חווים בעיות, אילו אינם מנוצלים מספיק (הקיבולת שהוקצתה להם מתבזבזת) וכו'.
לדוגמה, Kubernetes מדרגת שירותים בהתבסס על ניצול המעבד והזיכרון של הפודים. (ראו את הדיווח שלנו)" - משוער. תרגום), אבל אם תחליטו להתאים את הגודל על סמך כל מדד אחר (במקרה שלנו, מדד הקשור לתנועה), תצטרכו מדד ייעודי. מראה איך לעשות את זה עם , и , אבל התהליך עצמו די מורכב. היינו רוצים שרשת השירותים תפשט אותה, ותאפשר לנו לקבוע תנאים כמו "להגדיל את מספר מופעי השירות". auth, אם מספר הבקשות הממתינות לביצוע עולה על הסף למשך דקה."
7. פריסות קנרי
בקיצור: בדיקת תכונות או גרסאות חדשות של שירות על קבוצת משנה של משתמשים.
נניח שאתם בונים מוצר SaaS ואתם עומדים לשלוח גרסה חדשה ומגניבה. בדקתם אותו ב-staging, והוא עובד מצוין. אבל עדיין יש לכם כמה חששות לגבי איך הוא יתנהג בתנאים אמיתיים. במילים אחרות, אתם רוצים לבדוק את הגרסה החדשה על משימות אמיתיות מבלי לסכן את אמון המשתמשים שלכם. פריסות קנרי מצוינות לכך. הן מאפשרות לכם להדגים תכונה חדשה לקבוצת משנה של משתמשים. קבוצת משנה זו יכולה להיות המשתמשים הנאמנים ביותר שלכם, או אלו שמשתמשים בגרסה החינמית של המוצר, או משתמשים שהתנדבו להיות "שפני ניסוי".
רשתות שירות עושות זאת על ידי מתן אפשרות לציין קריטריונים למי רואה איזו גרסה של האפליקציה שלך, ולנתב את התנועה בהתאם. שום דבר לא משתנה עבור השירותים עצמם. גרסה 1.0 של שירות מניחה שכל הבקשות מגיעות ממשתמשים שאמורים לראות אותו, וגרסה 1.1 מניחה את אותו הדבר עבור המשתמשים שלה. בינתיים, ניתן לשנות את אחוז התנועה בין הגרסה הישנה לחדשה, ולהפנות מספר הולך וגדל של משתמשים לגרסה החדשה אם היא יציבה ו"שפני הניסיונות" שלך נותנים אור ירוק.
8. פריסות כחול-ירוקות
TL;DR: השקת פיצ'ר חדש ומגניב, אבל היו מוכנים לבטל אותו באופן מיידי.
משמעות היא להשיק שירות "כחול" חדש, שיפעל במקביל לשירות הישן וה"ירוק". אם הכל ילך כשורה והשירות החדש יוכיח את עצמו כראוי, ניתן יהיה לבטל בהדרגה את הישן. (אבוי, יום אחד גם השירות ה"כחול" החדש הזה יסבול מאותו גורל כמו ה"ירוק" וייעלם...) פריסות כחולות-ירוקות שונות מפריסות קנריות בכך שהתכונה החדשה מכסה פִּתְאוֹם משתמשים (לא חלק); הנקודה כאן היא שיהיה "פורט גיבוי" מוכן למקרה שמשהו משתבש.
רשתות שירות מציעות דרך נוחה מאוד לבדוק שירות "כחול" ולעבור באופן מיידי לשירות "ירוק" פעיל במקרה של בעיות. שלא לדבר על כך שהן גם מספקות מידע רב (ראה "טלמטריה" להלן) על פעולת השירות "הכחול", מה שעוזר להבין האם הוא מוכן לפעולה מלאה.
הערה. תרגוםניתן לקרוא עוד על אסטרטגיות הפריסה השונות ב-Kubernetes (כולל הקנרית, הכחולה/ירוקה ואחרות שהוזכרו) ב .
9. בדיקת בריאות
בקיצור: יש לנטר אילו מופעי שירות תקינים ולהגיב לאלו שכבר אינם תקינים.
בדיקת בריאות (בדיקת בריאות) עוזר להחליט האם מופעי שירות מוכנים לקבל ולעבד תעבורה. לדוגמה, במקרה של שירותי HTTP, בדיקת תקינות עשויה להיראות כמו בקשת GET לנקודת קצה /healthתשובה 200 OK פירושו שהאינסטנס תקין, כל דבר אחר - שהוא אינו מוכן לקבל תעבורה. רשתות שירות מאפשרות לך לציין הן את אופן בדיקת התקינות והן את תדירות ביצוע בדיקה זו. לאחר מכן ניתן להשתמש במידע זה למטרות אחרות - לדוגמה, לאיזון עומסים ולשבירת מעגלים.
לכן, בדיקות תקינות אינן מקרה שימוש עצמאי, אלא משמשות בדרך כלל להשגת מטרות אחרות. כמו כן, בהתאם לתוצאות בדיקות התקינות, ייתכן שיידרשו פעולות חיצוניות (יחסית למטרות אחרות של רשת השירות): לדוגמה, עדכון דף הסטטוס, יצירת בעיה ב-GitHub או מילוי כרטיס JIRA. ורשת השירות מציעה מנגנון נוח לאוטומציה של כל זה.
10. ניתוק עומסים
בקיצור: ניתוב מחדש של תנועה בתגובה לעלייה זמנית בשימוש.
אם שירות עמוס בתעבורה, ניתן להפנות באופן זמני חלק מהתנועה הזו למיקום אחר (למשל, "להשליך" או "לשפוך" אותה) (לִשְׁפּוֹך) (לדוגמה, לשירות גיבוי או למרכז נתונים, או לשרת קבוע נושא. כתוצאה מכך, השירות ימשיך לעבד בקשות מסוימות במקום לקרוס ולא לעבד דבר כלל. ניתוק עומסים עדיף על שבירת שרשרת, אך עדיין לא מומלץ להשתמש בו יתר על המידה. זה עוזר למנוע כשלים מדורגים שגורמים לקריסה של שירותים במורד הזרם.
11. מקביליות/שיקוף של תעבורה
בקיצור: שלח בקשה אחת למספר מקומות בו זמנית.
לעיתים יש צורך לשלוח בקשה (או מבחר של בקשות) למספר שירותים בו זמנית. דוגמה אופיינית לכך היא שליחת חלק מתעבורת הייצור לשירות staging. שרת האינטרנט הראשי של הייצור שולח בקשה לשירות downstream. products.production ורק אליו. ורשת השירות מעתיקה באופן חכם את הבקשה הזו ושולחת אותה אל products.staging, ששרת האינטרנט אפילו לא יודע עליו.
מקרה שימוש קשור נוסף עבור רשת שירות שניתן ליישם מעל מקביליות תעבורה הוא זה כרוך בשליחת אותן בקשות לגרסאות שונות של שירות ובדיקה האם כל הגרסאות מתנהגות באותו אופן. עדיין לא ראיתי יישום של רשת שירותים עם מערכת בדיקות רגרסיה משולבת כמו... , אבל הרעיון עצמו נראה מבטיח.
12. בידוד
TL;DR: חלקו את רשת השירות שלכם למיני-רשתות.
ידוע גם בשם הִתפַּלְגוּתבידוד הוא אמנות חלוקת רשת שירותים למקטעים נפרדים מבחינה לוגית שאינם יודעים דבר זה על זה. בידוד דומה קצת ליצירת רשתות פרטיות וירטואליות. ההבדל העיקרי הוא שעדיין מקבלים את כל היתרונות של רשת שירותים (כמו גילוי שירותים), אך עם אבטחה נוספת. לדוגמה, אם תוקף מצליח לחדור לשירות בתת-רשת אחת, הוא לא יוכל לראות אילו שירותים פועלים בתת-רשתות אחרות או ליירט את התעבורה שלהן.
ייתכנו גם יתרונות ארגוניים. ייתכן שתרצו לחלק שירותים לתת-רשתות בהתבסס על מבנה החברה שלכם ולשחרר את המפתחים מהעומס הקוגניטיבי של מעקב אחר כל רשת השירותים.
13. הגבלת קצב בקשות, ניסיונות חוזרים ופסקי זמן
בקיצור: אין עוד צורך לכלול משימות ניהול בקשות גוזלות זמן בבסיס הקוד שלך.
ניתן להתייחס לכל הדברים הללו כאל מקרי שימוש נפרדים, אך החלטתי לקבץ אותם יחד בגלל דבר אחד המשותף להם: הם משחררים את משקלם של משימות ניהול מחזור חיי הבקשות שבדרך כלל מטופלות על ידי ספריות יישומים. אם אתם בונים שרת אינטרנט של Ruby on Rails (לא משולב עם רשת השירות) שמבצע בקשות לשירותי backend דרך , היישום יצטרך להחליט בעצמו מה לעשות אם N בקשות נכשלות. הוא יצטרך גם להבין כמה תעבורה שירותים אלה יכולים להתמודד עם ולקודד את הפרמטרים הללו באמצעות ספרייה מיוחדת. בנוסף, היישום יצטרך להחליט מתי לוותר ולתת לבקשה להשתבש (על ידי פסק זמן). וכדי לשנות אחד מהפרמטרים הנ"ל, יהיה צורך לעצור את שרת האינטרנט, להגדיר אותו מחדש ולהפעיל אותו מחדש.
האצלת משימות אלו לרשת השירותים לא רק אומרת שמפתחי שירותים לא צריכים לחשוב עליהן, אלא גם שניתן להתייחס אליהן בצורה גלובלית יותר. אם יש לכם שרשרת שירותים מורכבת, נניח A –> B –> C –> D –> E, עליכם לקחת בחשבון את מחזור החיים המלא של בקשה. אם אתם צריכים להאריך את זמני היציאה בשירות C, הגיוני לעשות זאת בבת אחת, ולא בצורה חלקה: עדכון קוד השירות והמתנה לבקשת ה-pull שתתקבל ולמערכת ה-CI לפרוס את השירות המעודכן.
14. טלמטריה
בקיצור: אספו את כל המידע הדרוש (והלא ממש הכרחי) מהשירותים.
טלמטריה היא מונח מטריה הכולל מדדים, מעקב מבוזר ויומני רישום. רשתות שירות מציעות מנגנונים לאיסוף ועיבוד שלושת סוגי הנתונים. כאן הדברים נהיים מעט מטושטשים, מכיוון שמספר האפשרויות האפשריות גדול מדי. עבור מדדים, יש וכלים אחרים בהם ניתן להשתמש כדי לאסוף יומני רישום , , וכו ' (לדוגמה, ClickHouse עם שלנו עבור K8s - הערת המתרגם), עבור מעקב מבוזר יש וכו'. כל רשת שירותים עשויה לתמוך בכלים מסוימים ולא באחרים. יהיה מעניין לראות אם הפרויקט יוכל לספק התכנסות מסוימת.
במקרה זה, היתרון של טכנולוגיית רשת השירותים הוא שמכולות צדדיות יכולות, באופן עקרוני, לאסוף את כל הנתונים הנ"ל מהשירותים שלהן. במילים אחרות, אתם מקבלים מערכת איסוף טלמטריה אחת לרשותכם, ורשת השירותים יכולה לעבד את כל המידע הזה בדרכים שונות. לדוגמה:
- יומני זנב משירות מסוים ב-CLI;
- מעקב אחר נפח בקשות מלוח המחוונים של רשת השירות;
- לאסוף עקבות מבוזרות ולהעביר אותן למערכת כמו יגר.
תשומת לב, שיפוט סובייקטיבי: באופן כללי, טלמטריה היא תחום שבו לא רוצים הרבה הפרעות של רשת השירות. איסוף מידע בסיסי ומעקב אחר כמה "מדדי זהב" תוך כדי תנועה כמו שיעור הצלחה והשהייה זה בסדר, אבל בואו נקווה שלא נראה ערימות של פרנקנשטיין שמנסות להחליף מערכות ייעודיות, שחלקן כבר מבוססות ומובנות היטב.
15. ביקורת
TL;DR: אלו ששוכחים את לקחי ההיסטוריה נידונים לחזור עליהם.
ביקורת היא אמנות הניטור של אירועים חשובים במערכת. במקרה של רשת שירותים, פירוש הדבר עשוי להיות מעקב אחר מי הגיש בקשות לנקודות קצה ספציפיות של שירותים ספציפיים, או כמה פעמים התרחש אירוע מסוים הקשור לאבטחה בחודש האחרון.
ברור שביקורת קשורה קשר הדוק מאוד לטלמטריה. ההבדל הוא שטלמטריה קשורה בדרך כלל לדברים כמו ביצועים וכשירות טכנית, בעוד שביקורת יכולה להתייחס לנושאים משפטיים ואחרים שאינם בתחום הטכני בלבד (לדוגמה, עמידה בתקנת הגנת המידע הכללית של האיחוד האירופי).
16. הדמיה
TL;DR: יחי React.js, מעיין הממשקים המוזרים.
אולי יש מונח טוב יותר, אבל אני לא מכיר אותו. אני מתכוון רק לייצוג גרפי של רשת השירות או חלק מהמרכיבים שלה. הדמיות אלו יכולות לכלול אינדיקטורים כמו השהיות ממוצעות, מידע על תצורת מכולות צדדיות, תוצאות בדיקת תקינות והתראות.
עבודה בסביבה מוכוונת שירותים קשורה לעומס קוגניטיבי גבוה בהרבה בהשוואה לסביבה של הוד מלכותו המונולית. לכן, יש להפחית את הלחץ הקוגניטיבי בכל מחיר. ממשק גרפי פשוט לשילוב השירות עם היכולת ללחוץ על כפתור ולקבל את התוצאה הרצויה יכול להיות מכריע לצמיחתה של טכנולוגיה זו.
לא נכללו ברשימה
במקור התכוונתי לכלול עוד כמה מקרי שימוש ברשימה, אבל אז החלטתי שלא לעשות זאת. הנה הם, יחד עם הסיבות להחלטתי:
- מרכז נתונים מרובהלדעתי, זה לא כל כך מקרה שימוש כמו יישום צר וספציפי של רשתות שירות או קבוצה כלשהי של תכונות כמו גילוי שירותים.
- כניסה ויציאהזהו תחום קשור, אך הגבלתי את עצמי (אולי באופן מלאכותי) למקרה השימוש של "תנועה ממזרח למערב". כניסה ויציאה ראויות למאמר נפרד.
מסקנה
זה הכל להיום! שוב, רשימה זו מותנית מאוד וסביר להניח שאינה שלמה. אם אתם חושבים שפספסתי משהו או שטעיתי, צרו איתי קשר בטוויטר (אנא שמרו על כללי ההגינות.
נ.ב מהמתרגם
האיור העיקרי למאמר מבוסס על תמונה מהמאמר "" (מאת גרגורי מקינון) זה מראה כיצד חלק מהפונקציונליות מהיישומים (בירוק) הועברה לרשת השירות המספקת את החיבורים ביניהן (בכחול).
קרא גם בבלוג שלנו:
- «";
- «";
- «".
מקור: www.habr.com
