סקירה כללית של ניהול מתקדם של תעבורת נתונים

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

‫Cloud Service Mesh מספק יכולות מתקדמות לניהול תעבורה שמאפשרות לכם שליטה פרטנית באופן הטיפול בתעבורה. ‫Cloud Service Mesh תומך בתרחישי השימוש הבאים:

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

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

ניהול תעבורת נתונים ב-Service mesh של Cloud Service Mesh מתבסס על המשאבים הבאים:

• משאב Mesh, שמזהה את Service mesh ומייצג את הרכיב שאחראי על העברת התנועה והחלת כללי המדיניות. במשאב Mesh מוגדרת גם היציאה שדרכה מתבצעת חסימת התנועה.
• משאב Gateway, שמזהה פרוקסי ביניים ומייצג את הרכיב שמקשיב לרשימה של זוגות של כתובות IP:יציאה, מעביר תנועה ומחיל מדיניות.
• משאב Route, שיכול להיות אחד מכמה סוגים, ומכיל מידע על ניתוב תנועה לרשת. משאבי Route מזהים שמות מארחים ויציאות שבהם לקוחות יכולים להשתמש כדי לנתב תנועה לשירותי קצה עורפיים. אלה סוגי המשאבים של Route:
  • ‫HTTPRoute, שזמין רק ברשתות שמשתמשות ב-Envoy proxies. כשמשתמשים במשאב HTTPRoute כדי להגדיר את שרתי ה-proxy של Envoy לשליחת בקשות HTTP, כל היכולות שמתוארות במסמך הזה זמינות.
  • ‫TCPRoute, שזמין רק ברשתות שמשתמשות ב-Envoy proxies.
  • ‫TLSRoute, שזמין רק ברשתות שמשתמשות ב-Envoy proxies.
  • ‫GRPCRoute, שזמין ברשתות באמצעות קובצי עזר חיצוניים של Envoy ו-gRPC ללא proxy. כשמשתמשים בשירותי gRPC או באפליקציות בלי שרת Proxy עם Cloud Service Mesh, חלק מהיכולות שמתוארות במסמך הזה לא זמינות.
• שירות קצה עורפי, שאליו משויכים משאבי Route.

הגדרות אישיות

כדי להגדיר ניהול מתקדם של תנועה, משתמשים באותם משאבים של Route ושירותי קצה עורפיים שבהם משתמשים כשמגדירים את Cloud Service Mesh. בתמורה, Cloud Service Mesh מגדיר את שרתי ה-proxy של Envoy ואת אפליקציות ה-gRPC ללא שרת Proxy כדי לאכוף את כללי המדיניות המתקדמים לניהול תעבורה שהגדרתם.

באופן כללי, השלבים הם:

1. מגדירים משאב Mesh כדי לזהות את רשת השירות.

2. מגדירים את המשאבים של Route כך שיבצעו את הפעולות הבאות, על סמך המאפיינים של הבקשה היוצאת:

   1. בוחרים את שירות ה-Backend שאליו מנותבות הבקשות.

   2. אפשר לבצע פעולות נוספות.

3. מגדירים את שירות הקצה העורפי כדי לשלוט באופן שבו התעבורה מופצת לקצוות העורפיים ולנקודות הקצה אחרי שבוחרים שירות יעד.

ניתוב תעבורת הנתונים ופעולות

ב-Cloud Service Mesh, התנועה מנותבת על סמך ערכים במשאב Mesh, במשאב Route ובמשאב של שירות קצה עורפי. כל היכולות המתקדמות של ניהול תנועה שקשורות לניתוב ולפעולות מוגדרות באמצעות אובייקטים של Route.

בקטעים הבאים מוסבר על התכונות המתקדמות לניהול תנועה שאפשר להגדיר באובייקטים Route.

טיפול בבקשות

כשלקוח שולח בקשה, היא מטופלת לפי השלבים הבאים:

1. הבקשה מותאמת למשאב Route ספציפי באופן הבא:

   • אם משתמשים ב-Envoy:
     • כותרת המארח בבקשת ה-HTTP מושוות לשדה hostnames בכל משאב HTTPRoute או GRPCRoute כדי לבחור את משאב Route הנכון לבקשה. רק למשאבים HTTPRoute ו-GRPCRoute יש את השדה hostnames.
     • כתובת ה-IP מותאמת לניתוב תעבורת TCP באמצעות TCPPRoute.
     • נעשה שימוש ב-SNI וב-ALPN להעברת TLS באמצעות TLSRoute.
     • למשאבים HTTPRoute ו-GRPCRoute שמשויכים ל-Mesh או ל-Gateway צריכים להיות שמות מארחים ייחודיים. אם מנסים לצרף כמה מסלולים עם שמות מארחים סותרים, התצורה נדחית.
     • באופן דומה, השדה IP:Port של TCPRoute חייב להיות ייחודי, אחרת ההגדרה תידחה.
     • באופן דומה, SNI ו-ALPN צריכים להיות ייחודיים עבור TLSRoute.
     • אם יש שמות מארחים חופפים, כמו a.example.com ו-*.example.com, הבקשה תתאים לנתיב הספציפי יותר.
   • אם משתמשים ב-gRPC בלי שרת Proxy:
     • לקוחות gRPC ללא proxy משתמשים בסכימת זיהוי השמות xds. הם פותרים את hostname[:port] ב-URI של היעד על ידי שליחת בקשה ל-Cloud Service Mesh.
     • רק היציאה של משאב GRPCRoute מושווית ליציאה ב-URI של היעד (לדוגמה, xds:///example.hostname:8080). ה-URI של היעד חייב להיות זהה למחרוזת בשדה hostnames של GRPCRoute.

2. המשאב Route יכול להכיל מידע נוסף על ניתוב וכללים.

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

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

ניתוב פשוט שמבוסס על מארח ונתיב

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

• המארח של הבקשה הוא החלק של שם הדומיין בכתובת URL – לדוגמה, החלק של המארח בכתובת ה-URL http://example.com/video/ הוא example.com.
• הנתיב של הבקשה הוא החלק בכתובת ה-URL שמופיע אחרי שם המארח. לדוגמה, הנתיב בכתובת ה-URL http://example.com/video/ הוא /video.

אתם מגדירים ניתוב פשוט שמבוסס על מארח ונתיב במפת כללי הניתוב, שכוללת את הרכיבים הבאים:

• Mesh
• ‫HTTPRoute או GRPCRoute

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

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

• אם המארח של הבקשה (למשל example.com) תואם לשם המארח של HTTPRoute:

  1. ה-RouteRule נבדק בשלב הבא. התג RouteRule מציין איך להתאים תנועה ואיך לנתב תנועה כשהתנועה מתאימה.
  2. כל RouteRule מכיל התאמה אחת או יותר של נתיבים שמוערכים ביחס לנתיב של הבקשה.
  3. אם נמצאת התאמה, הבקשה מנותבת לשירות שצוין ב-RouteAction.

מידע נוסף על שדות המשאבים של HTTPRoute ועל אופן הפעולה שלהם זמין במאמרי העזרה בנושא ממשק API של שירות רשת.

ניתוב ופעולות מתקדמים

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

באופן כללי, ניתוב מתקדם ופעולות פועלים כך:

1. בדומה לניתוב פשוט, המארח של הבקשה מושווה לכללי המארח שהגדרתם ב-HTTPRoute או ב-GRPCRoute. אם המארח בבקשה תואם לשם המארח, מתבצעת הערכה של HTTPRoute או GRPCRoute.
2. אחרי שבוחרים מסלול, אפשר להחיל פעולות.

ניתוב מתקדם

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

תנאי התאמה נוספים ופרטים על headerMatches ו-queryParameterMatches מופיעים בדף network services API בארכיטקטורת REST.

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

	אפליקציה מבוססת HTTP	אפליקציה מבוססת gRPC
מארחי HTTP לעומת מארחי gRPC	המארח הוא החלק של שם הדומיין בכתובת ה-URL שהאפליקציה קוראת לו. לדוגמה, החלק של המארח בכתובת ה-URL http://example.com/video/ הוא example.com.	המארח הוא השם שבו הלקוח משתמש ב-URI של הערוץ כדי להתחבר לשירות ספציפי. לדוגמה, החלק של המארח ב-URI של הערוץ xds:///example.com הוא example.com.
נתיבי HTTP לעומת נתיבי gRPC	הנתיב הוא החלק בכתובת ה-URL שמופיע אחרי שם המארח. לדוגמה, חלק הנתיב בכתובת ה-URL http://example.com/video הוא /video.	הנתיב נמצא בכותרת :path של בקשת HTTP/2 ונראה כך: /SERVICE_NAME/METHOD_NAME. לדוגמה, אם קוראים לשיטה Download בשירות gRPC ‏Example, התוכן של הכותרת :path נראה כך: /Example/Download.
כותרות gRPC אחרות (מטא-נתונים)		פרוטוקול gRPC תומך בשליחת מטא-נתונים בין לקוח gRPC לשרת gRPC כדי לספק מידע נוסף על קריאה לשירות מרוחק (RPC). המטא-נתונים האלה הם בצורה של צמדי מפתח/ערך שמועברים ככותרות בבקשת HTTP/2.

פעולות

ב-Cloud Service Mesh אפשר לציין פעולות ששרתי ה-proxy של Envoy או אפליקציות gRPC ללא proxy מבצעים כשמתבצעת בקשה. אפשר להגדיר את הפעולות הבאות באמצעות Cloud Service Mesh.

פעולה	שם השדה ב-API	תיאור
הפניות אוטומטיות	redirect [pathredirect?]	מחזירה קוד תגובה מסוג 3xx שניתן להגדרה. הוא גם מגדיר את כותרת התגובה Location עם ה-URI המתאים, ומחליף את המארח והנתיב כמו שצוין בפעולת ההפניה.
שכתוב של כתובות URL	urlRewrite	הפונקציה משנה את החלק של שם המארח בכתובת ה-URL, את החלק של הנתיב בכתובת ה-URL או את שניהם, לפני שליחת בקשה לשירות לקצה העורפי שנבחר.
טרנספורמציות של כותרות	requestHeaderModifier/responseHeaderModifier?	הוספה או הסרה של כותרות בקשה לפני שליחת בקשה לשירות הקצה העורפי. אפשר גם להוסיף או להסיר כותרות תגובה אחרי קבלת תגובה משירות לקצה העורפי.
שיקוף תנועה	requestMirrorPolicy	בנוסף להעברת הבקשה לשירות הקצה העורפי שנבחר, המערכת שולחת בקשה זהה לשירות הקצה העורפי המשוכפל שהוגדר על בסיס שליחה ללא המתנה לתשובה. מאזן העומסים לא מחכה לתגובה מהקצה העורפי שאליו הוא שולח את הבקשה המשוכפלת. שיקוף שימושי לבדיקת גרסה חדשה של שירות קצה עורפי. אפשר להשתמש בה גם כדי לנפות באגים בשגיאות בייצור בגרסת ניפוי באגים של שירות הקצה העורפי, במקום בגרסת הייצור.
פיצול תנועה לפי משקל	weiDestination.serviceNameght	מאפשרת להפיץ תנועה של כלל תואם לכמה שירותים לקצה העורפי, באופן יחסי למשקל שהמשתמש מגדיר לכל שירות לקצה העורפי. היכולת הזו שימושית להגדרת פריסות מדורגות או בדיקות A/B. לדוגמה, אפשר להגדיר את פעולת המסלול כך ש-99% מהתנועה יישלחו לשירות שמריץ גרסה יציבה של אפליקציה, ו-1% מהתנועה יישלחו לשירות נפרד שמריץ גרסה חדשה יותר של אותה אפליקציה.
ניסיונות חוזרים	retryPolicy	היא מגדירה את התנאים שבהם מאזן העומסים מנסה שוב בקשות שנכשלו, את משך ההמתנה של מאזן העומסים לפני הניסיון החוזר ואת המספר המקסימלי של ניסיונות חוזרים שמותרים.
זמן קצוב לתפוגה	timeout	מציינת את הזמן הקצוב לתפוגה של הנתיב שנבחר. הזמן הקצוב לתפוגה מחושב מהרגע שבו הבקשה עוברת עיבוד מלא ועד הרגע שבו התשובה עוברת עיבוד מלא. הזמן הקצוב לתפוגה כולל את כל הניסיונות החוזרים.
הזרקת תקלות	faultInjectionPolicy	הוספת שגיאות כשמטפלים בבקשות כדי לדמות כשלים, כולל חביון גבוה, עומס יתר על השירות, כשלים בשירות וחלוקת הרשת למחיצות. התכונה הזו שימושית לבדיקת העמידות של שירות בפני תקלות מדומה.
מדיניות אבטחה	corsPolicy	מדיניות שיתוף משאבים בין מקורות (CORS) מטפלת בהגדרות של אכיפת בקשות CORS.

מידע נוסף על פעולות ועל אופן הפעולה שלהן זמין בדף Network Services API.

בכל כלל ניתוב אפשר לציין אחת מפעולות הניתוב הבאות:

• ניתוב תנועה לשירות יחיד (destination.serviceName)
• חלוקת התנועה בין כמה שירותים (destination.weight)
• כתובות URL להפניה אוטומטית (redirect)

בנוסף, אפשר לשלב כל אחת מפעולות המסלול שצוינו קודם עם אחת או יותר מפעולות המסלול הבאות (שנקראות פעולות נוספות במסוף Google Cloud ):

• שינוי של כותרות בקשות או תגובות (requestHeaderModifier/responseHeaderModifier)
• שיקוף תנועה (requestMirrorPolicy)
• כתיבה מחדש של המארח, הנתיב או שניהם של כתובת ה-URL (urlRewrite)
• ניסיון חוזר של בקשות שנכשלו (retryPolicy)
• הגדרת זמן קצוב לתפוגה (timeout)
• הוספת תקלות לאחוז מסוים מהתנועה (faultInjectionPolicy)
• הוספת מדיניות CORS (corsPolicy)

מכיוון שהפעולות משויכות לכללים ספציפיים, שרת ה-proxy של Envoy או אפליקציית gRPC בלי שרת Proxy יכולים להחיל פעולות שונות על סמך הבקשה שהם מטפלים בה.

הפצת תעבורה בין שרתים עורפיים של שירות

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

בתרשים שלמעלה, הכלל פושט. הכלל הוא בדרך כלל כלל מארח, התאמת נתיב וכלל נתיב או כלל מסלול אחד או יותר. שירות היעד הוא שירות(קצה עורפי). ‫Backend 1,‏ … ו-Backend n מקבלים את הבקשה ומטפלים בה. יכול להיות שהעורפים האלה יהיו, לדוגמה, מכונות וירטואליות (VM) של Compute Engine שמארחות את קוד האפליקציה בצד השרת.

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

איזון עומסים, זיקה לסשן והגנה על קצה עורפי

אפשר להגדיר את מדיניות חלוקת התנועה הבאה בכל שירות.

מדיניות	שם השדה ב-API	תיאור
מצב איזון עומסים	balancingMode	המאפיין הזה קובע איך נבחרת קבוצה של נקודות קצה ברשת (NEG) או קבוצה של מופעים מנוהלים (MIG) אחרי שנבחר שירות יעד. אפשר להגדיר את מצב איזון העומסים כך שהעומס יפוזר על סמך חיבורים מקבילים וקצב בקשות.
מדיניות איזון עומסים	localityLbPolicy	הגדרת אלגוריתם לאיזון עומסים שמשמש לחלוקת תעבורה בין קצה עורפי ב-NEG או ב-MIG. כדי לבצע אופטימיזציה של הביצועים, אפשר לבחור מתוך מגוון אלגוריתמים (למשל, סדר סיבובי או בקשה מינימלית).
זיקה לסשן (session affinity)	sessionAffinity	הוא מספק ניסיון מיטבי לשלוח בקשות מלקוח מסוים לאותו קצה עורפי כל עוד הקצה העורפי תקין ויש לו קיבולת. ‫Cloud Service Mesh תומך בארבע אפשרויות של זיקה לסשן: כתובת ה-IP של הלקוח, מבוסס-קובץ Cookie של HTTP, מבוסס-header של HTTP וזיקה לקובץ Cookie שנוצר (שנוצר על ידי Cloud Service Mesh עצמו).
גיבוב עקבי	consistentHash	מספק זיקה רכה לסשן על סמך כותרות HTTP, קובצי Cookie או מאפיינים אחרים.
מפסקים חשמליים	circuitBreakers	מגדיר מגבלות עליונות על נפח החיבורים והבקשות לכל חיבור לשירות לקצה העורפי.
זיהוי חריגות	outlierDetection	המאפיין הזה מציין את הקריטריונים ל-(1) הסרה של קצה עורפי או נקודות קצה לא תקינים מקבוצות של מכונות מנוהלות (MIG) או מקבוצות של נקודות קצה ברשת (NEG), ו-(2) הוספה מחדש של קצה עורפי או נקודת קצה כשהם נחשבים תקינים מספיק כדי לקבל שוב תנועה. בדיקת התקינות שמשויכת לשירות קובעת אם עורף או נקודת קצה נחשבים תקינים.

מידע נוסף על אפשרויות שונות של חלוקת תנועה ועל אופן הפעולה שלהן זמין במאמרים הבאים:

• בדף backendServices REST API
• סקירה כללית על שירותים לקצה העורפי

דוגמאות לתרחישי שימוש

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

דוגמאות נוספות, כולל קוד לדוגמה, זמינות במאמרים הגדרת ניהול תעבורה מתקדם באמצעות Envoy והגדרת ניהול תעבורה מתקדם באמצעות שירותי gRPC בלי שרת Proxy.

ניתוב תנועה ברמת פירוט גבוהה לצורך התאמה אישית

אפשר להפנות תנועה לשירות מסוים על סמך הפרמטרים של הבקשה. לדוגמה, יכול להיות שתשתמשו בשירות הזה כדי לספק חוויה מותאמת אישית יותר למשתמשי Android. בתרשים הבא, Cloud Service Mesh מגדיר את Service mesh כך שישלח בקשות עם הכותרת user-agent:Android לשירות Android במקום לשירות הכללי.

חלוקת תנועה לפי משקל לפריסות בטוחות יותר

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

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

שיקוף תנועת גולשים לצורך ניפוי באגים

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

איזון עומסים מדויק לשיפור הביצועים

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

בתרשים הבא, בניגוד לתרשימים הקודמים, מוצג גם שירות לקצה העורפי ליעד (Production Service) וגם הבק-אנדים של שירות לקצה העורפי הזה (Virtual Machine 1, ‏ Virtual Machine 2, ‏ Virtual Machine 3). באמצעות ניהול תעבורה מתקדם, אתם יכולים להגדיר איך שירות קצה עורפי של יעד נבחר ואיך התעבורה מתחלקת בין הקצוות העורפיים של שירות היעד הזה.

מידע נוסף על איזון עומסים באמצעות Cloud Service Mesh זמין במאמר סקירה כללית על איזון עומסים מתקדם.

המאמרים הבאים

• כדי להפנות תנועה מחוץ לרשת אל הרשת, אפשר לעיין במאמר בנושא תנועת Ingress לרשת.