סקירה כללית של ניהול תנועה במאזן עומסים קלאסי של אפליקציות (ALB)

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

מאזן עומסים קלאסי של אפליקציות (ALB) תומך בפונקציונליות של ניהול תנועת גולשים, שמאפשרת לכם להשתמש בתכונות הבאות:

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

מגדירים את התכונות האלה באמצעות מפת URL של מאזן העומסים. מידע נוסף זמין במאמרים הבאים:

רכיבים של ניהול טראפיק

באופן כללי, מאזני עומסים חיצוניים של אפליקציות (ALB) מספקים ניהול תעבורה באמצעות מפות כתובות URL גלובליות.

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

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

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

אפשר להחיל כתיבה מחדש או הפניות לכתובת אחרת בשלוש רמות במפת URL:

ב-pathRule שבו הפעולה מתבצעת כשנתיב מתאים
ב-pathMatcher שבו הפעולה מתבצעת כשאין נתיבים שתואמים ל-pathMatcher הזה
ב-urlMap שבו הפעולה מתבצעת כשאין התאמה לאף אחד מהמארחים שצוינו באף אחד מכללי המארחים

השימוש ב-routeRules ב-pathMatcher הוא חלופה לשימוש ב-pathRules. אי אפשר להשתמש גם ב-pathRules וגם ב-routeRules באותו pathMatcher. בניגוד לpathRules, שבהם הסדר לא משנה, routeRules נבדקים לפי הסדר. routeRule יכול לבדוק את נתיב כתובת ה-URL, את כותרות ה-HTTP ואת הפרמטרים של שאילתת כתובת ה-URL.

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

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

שכתובים

הגדרה של כתיבה מחדש של כתובות URL מאפשרת להציג למשתמשים חיצוניים כתובות URL ששונות מכתובות ה-URL שבהן משתמשים השירותים שלכם.

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

התכונה 'כתיבה מחדש של כתובות URL' מבצעת את הפעולות הבאות:

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

בתרשים הבא:

משתמש ביפן שולח בקשה לכתובת ה-URL‏ www.mydomain.com/static/images/someimage.jpg.
כשהבקשה מגיעה למאזן העומסים החיצוני של אפליקציות (ALB), מאזן העומסים משתמש במידע במפת URL כדי לשכתב את כתובת ה-URL ל-www.myorigin.com/august_snapshot/images/someimage.jpg.
(אופציונלי) בדוגמה הזו, מפת ה-URL שולחת את הבקשה לבק-אנד חיצוני.

**איור 1.** שכתוב כתובות URL באמצעות מאזן עומסים קלאסי של אפליקציות (ALB).

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

הפניות אוטומטיות

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

זה כולל את היכולת:

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

אפשר להשתמש בהפניות אוטומטיות לכתובות URL כדי לבצע את הפעולות הבאות:

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

הפניות אוטומטיות מ-HTTP ל-HTTPS עוזרות לכם גם:

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

בתרשים הבא:

משתמש ביפן שולח בקשה מסוג GET http://example.com/img1.
על סמך ההפניה האוטומטית שמוגדרת במפת ה-URL, מאזן העומסים מחזיר הפניה אוטומטית מסוג HTTP/1.1 302 Found Location: https://example.com/img1, ומפנה את בקשת ה-HTTP לבקשת HTTPS.
הדפדפן של המשתמש שולח בקשת GET https://example.com/img1.

הפניה לכתובת URL באמצעות מאזן עומסים קלאסי של אפליקציות (ALB). — **איור 2.** הפניה אוטומטית של כתובת URL באמצעות מאזן עומסים קלאסי של אפליקציות (ALB).

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

קודי תגובה נתמכים

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

קוד תגובה	מספר	הערות
MOVED_PERMANENTLY_DEFAULT	301
FOUND	302
PERMANENT_REDIRECT	308	במקרה כזה, שיטת הבקשה נשמרת.
TEMPORARY_REDIRECT	307	במקרה כזה, שיטת הבקשה נשמרת.
SEE_OTHER	303

ניתוב מבוסס-כותרת וניתוב מבוסס-פרמטר

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

התכונה הזו מאפשרת לפשט את ארכיטקטורת הענן בלי לפרוס שכבות נוספות של שרתי proxy (לדוגמה, NGINX) כדי לבצע ניתוב.

אתם יכולים להשתמש במאזן עומסים חיצוני של אפליקציות (ALB) כדי:

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

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

דוגמה: הגדרת בדיקות A/B עם ניתוב שמבוסס על פרמטרים של שאילתות

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

נניח שאתם רוצים לוודא שהבקשות מטופלות באופן הבא:

כל הבקשות עם ערך פרמטר השאילתה A מועברות לשירות לקצה העורפי שנקרא BackendServiceForProcessingOptionA.
כל הבקשות עם ערך פרמטר השאילתה B מועברות לשירות לקצה העורפי שנקרא BackendServiceForProcessingOptionB.

הדרישות האלה מסוכמות בטבלה הבאה.

בקשה	שירות לקצה העורפי
`http://test.mydomain.com?ABTest=A`	`BackendServiceForProcessingOptionA`
`http://test.mydomain.com?ABTest=B`	`BackendServiceForProcessingOptionB`

כדי להגדיר את זה במיפוי כתובות ה-URL הגלובליות, אפשר ליצור את ההגדרות הבאות.

התאמה	פעולה
`pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest` `pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A`	`pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA`
`pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest` `pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B`	`pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB`

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

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

הקצה העורפי של תנועת הגולשים נקבע באמצעות גישה דו-שלבית:

מאזן העומסים בוחר שירות לקצה העורפי עם קצוות עורפיים. הקצה העורפי יכול להיות:
- מכונות וירטואליות (VM) של Compute Engine בקבוצת מופעים לא מנוהלת
- מכונות וירטואליות של Compute Engine בקבוצת מופעי מכונה מנוהלים (MIG)
- קונטיינרים באמצעות צומת Google Kubernetes Engine‏ (GKE) בקבוצת נקודות קצה ברשת (NEG) אזורית
- בקצה העורפי החיצוני מחוץ ל- Google Cloud ב-NEG באינטרנט
- ‫Cloud Storage בקטגוריות של Backend
- שירותים של App Engine, פונקציות Cloud Run או שירותי Cloud Run ב-NEG ללא שרת
מאזן העומסים בוחר שירות לקצה העורפי על סמך כללים שמוגדרים במפת URL גלובלית.
השירות לקצה העורפי בוחר שרת עורפי על סמך מדיניות שמוגדרת בשירות לקצה עורפי גלובלי.

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

בדיקה פשוטה של מארח ונתיב באמצעות pathRules
בדיקה מתקדמת של בקשות באמצעות routeRules

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

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

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

הדיאגרמה הבאה מציגה את התהליך הלוגי של כלל פשוט של אירוח ונתיב.

**איור 3.** תרשים זרימה של מפת URL עם כלל פשוט של מארח ונתיב.

ההערכה הראשונית של הבקשה מתבצעת באמצעות כללי מארח. המארח הוא הדומיין שצוין בבקשה. אם הבקשה host תואמת לאחת מהרשומות בשדה hosts, נעשה שימוש בכלי להתאמת נתיבים שמשויך לרשומה.

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

כלל פשוט אופייני של מארח ונתיב יכול להיראות כך, כאשר תנועת הווידאו מועברת אל video-backend-service, וכל תנועה אחרת מועברת אל web-backend-service.

$ gcloud compute url-maps describe ext-https-map

defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

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

כלל מתקדם של מארח, נתיב ומסלול

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

כמו בדוגמה הקודמת של כלל פשוט של מארח ונתיב, אפשר להגדיר ניהול מתקדם של תעבורת נתונים באמצעות מפת URL גלובלית, אבל במקום להשתמש ב-pathMatchers[].pathRules[], משתמשים ב-pathMatchers[].routeRules[].

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

כללים למארחים

כשבקשה מגיעה למאזן העומסים, השדה host של הבקשה מוערך בהשוואה ל-hostRules שמוגדר במפת URL. כל כלל מארח מורכב מרשימה של מארח אחד או יותר ומאמצעי התאמה יחיד לנתיב (pathMatcher). אם לא מוגדרים hostRules, הבקשה מנותבת אל defaultService.

מידע נוסף מופיע בhostRules[] ובdefaultService במאמרי העזרה של ה-API של מפת URL גלובלית.

דפוסי נתיבים

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

התאמה לנתיב מורכבת מהרכיבים הבאים:

כלל נתיב אחד או יותר (pathRules) או כללי ניתוב (routeRules).
כלל ברירת מחדל שמופעל כשאין התאמה לשירותי קצה עורפיים אחרים. לכלל יש את האפשרויות הבאות שאינן תלויות זו בזו:
- שירות ברירת מחדל מציין את שירות הקצה העורפי שאליו ינותב התעבורה אם לא נמצאו שירותי קצה עורפיים אחרים שתואמים לבקשה.
- הפניה אוטומטית שמוגדרת כברירת מחדל מציינת את כתובת ה-URL שאליה תתבצע ההפניה האוטומטית אם לא נמצאו שירותי קצה עורפיים אחרים שתואמים.

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

מידע נוסף זמין במאמרים pathMatchers[], pathMatchers[].pathRules[] ו-pathMatchers[].routeRules[] במסמכי התיעוד של API של מפת URL גלובלית.

כללי הנתיבים

כללי נתיב (pathRules) מציינים נתיב URL אחד או יותר, כמו / או /video. כללי נתיב מיועדים בדרך כלל לסוג הניתוב הפשוט שמבוסס על מארח ונתיב שתואר קודם.

מידע נוסף זמין במאמר בנושא pathRules[] במסמכי העזרה בנושא מפת URL גלובלית.

כללי ניתוב

כלל ניתוב (routeRules) מתאים למידע בבקשה נכנסת ומקבל החלטה לגבי ניתוב על סמך ההתאמה.

כללי ניתוב יכולים להכיל מגוון של כללי התאמה שונים (matchRules) ומגוון של פעולות ניתוב שונות (routeAction).

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

רשימה מפורטת של האפשרויות שנתמכות על ידי matchRules זמינה במאמר matchRules[] במסמכי התיעוד של global מפת URL API.

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

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

הקודGoogle Cloud מבצע את הפעולות הבאות:

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

לכללי ניתוב יש כמה רכיבים, כמו שמתואר בטבלה הבאה.

רכיב של כלל ניתוב (`API field name`)	תיאור
עדיפות (`priority`)	מספר מ-0 עד 2,147,483,647 (כלומר, (2^31)-1) שמוקצה לכלל ניתוב בתוך התאמת נתיבים נתונה, כדי לקבוע את סדר ההערכה של כללי הניתוב. העדיפות הכי גבוהה היא `0`. העדיפות הנמוכה ביותר היא `2147483647`. לדוגמה, כלל עם עדיפות `4` ייבדק לפני כלל עם עדיפות `25`. הכלל הראשון שתואם לבקשה יופעל. מספרי העדיפות יכולים להיות לא רציפים. אי אפשר ליצור כמה כללים עם אותה עדיפות.
תיאור (`description`)	תיאור אופציונלי באורך של עד 1,024 תווים.
שירות (`service`)	כתובת ה-URL המלאה או החלקית של משאב שירות הקצה העורפי שאליו התנועה מופנית אם הכלל הזה מתאים.
כללי התאמה (`matchRules`)	כלל אחד או יותר שמוערכים ביחס לבקשה. התנאים האלה `matchRules` יכולים להתאים לכל המאפיינים של בקשת ה-HTTP או לחלק מהם, כמו הנתיב, כותרות ה-HTTP והפרמטרים של השאילתה (GET). בתוך `matchRule`, כל הקריטריונים התואמים צריכים להתקיים כדי ש`routeActions` של `routeRule` יופעל. אם ל-`routeRule` יש כמה `matchRules`, ה-`routeActions` של `routeRule` יופעל אם בקשה תתאים לאחד מ-`matchRules` של `routeRule`.
פעולת ניתוב (`routeAction`)	מאפשרת לציין פעולת שכתוב של כתובת URL שתתבצע כשמתקיימים הקריטריונים של כלל ההתאמה.
פעולת הפניה אוטומטית (`urlRedirect`)	אפשר להגדיר פעולה שתגיב בהפניה אוטומטית של HTTP כשמתקיימים הקריטריונים של כלל ההתאמה. אי אפשר להשתמש בשדה הזה בשילוב עם פעולת ניתוב.

מידע נוסף מופיע בשדות הבאים במסמכי העזרה בנושא ממשק ה-API של מפת URL גלובלית:

routeRules[]
routeRules[].priority
routeRules[].description
routeRules[].service
routeRules[].matchRules[]
routeRules[].routeAction
routeRules[].urlRedirect

כללי התאמה

כללי התאמה (matchRules) מתאימים מאפיין אחד או יותר של בקשה ומבצעים פעולות שצוינו בכלל הניתוב. הרשימה הבאה כוללת כמה דוגמאות למאפייני בקשות שאפשר להתאים להם באמצעות כללי התאמה:

מארח: שם המארח הוא החלק של שם הדומיין בכתובת URL. לדוגמה, החלק של שם המארח בכתובת ה-URL ‏http://example.net/video/hd הוא example.net. בבקשה, שם המארח מגיע מהכותרת Host, כמו שמוצג בפקודת curl לדוגמה הזו, שבה 10.1.2.9 היא כתובת ה-IP של איזון העומסים:
```
curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
```
הנתיבים מופיעים אחרי שם המארח, לדוגמה /images. בכלל אפשר לציין אם כל הנתיב או רק החלק הראשון של הנתיב צריכים להיות זהים.
פרמטרים אחרים של בקשת HTTP, כמו כותרות HTTP, שמאפשרים התאמה של קובצי Cookie, וגם התאמה על סמך פרמטרים של שאילתה (משתני GET). שימו לב: אין תמיכה בהתאמה של ביטויים רגולריים לערכי כותרות.

רשימה מלאה של כללי ההתאמה הנתמכים מופיעה במאמר pathMatchers[].routeRules[].matchRules[] במסמכי התיעוד של ממשק ה-API של מפת URL גלובלית.

הגדרת ניהול תנועה

אתם יכולים להשתמש ב Google Cloud מסוף או ב-Cloud Load Balancing API כדי להגדיר ניהול תנועה.gcloud בסביבת ההגדרה שבחרתם, אתם מגדירים את ניהול התנועה באמצעות הגדרות YAML.

כדי לקבל עזרה בכתיבת קובצי ה-YAML האלה, אפשר להשתמש במקורות המידע הבאים:

מאמרי העזרה של ה-API של מפת URL גלובלית

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

סקירה כללית של ניהול תנועה במאזן עומסים קלאסי של אפליקציות (ALB) קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.