‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

סקירה כללית על מפות של כתובות URL

Google Cloud במאזני עומסים של אפליקציות וב-Cloud Service Mesh משתמשים במשאב הגדרה שנקרא מפת כתובות URL כדי לנתב בקשות HTTP(S) לשירותים לקצה העורפי או לקטגוריות של קצה עורפי. Google Cloud

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

בקשות ל-https://example.com/video מועברות לשירות אחד לקצה העורפי.
בקשות ל-https://example.com/audio מועברות לשירות קצה עורפי אחר.

בקשות ל-https://example.com/images מועברות לקטגוריית קצה עורפי של Cloud Storage.

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

מפות URL משמשות במוצרים הבאים של Google Cloud :

מאזן עומסים חיצוני של אפליקציות (ALB) (במצבים גלובלי, אזורי וקלאסי)
מאזן עומסים פנימי של אפליקציות (ALB) (במצבים אזוריים וחוצי-אזורים)
‫Cloud Service Mesh, כש-Cloud Service Mesh נפרס עם ממשקי ה-API של איזון העומסים

יש שני סוגים של משאבים של מפות URL: גלובליים ואזוריים.

urlMaps גלובליים משמשים במאזני עומסים חיצוניים גלובליים של אפליקציות, במאזני עומסים קלאסיים של אפליקציות, במאזני עומסים פנימיים של אפליקציות חוצי-אזורים וב-Cloud Service Mesh.
regionUrlMaps משמשים במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), במאזני עומסים פנימיים אזוריים של אפליקציות (ALB) וב-Cloud Service Mesh.

סוג המשאב שבו משתמשים תלוי בסכימת איזון העומסים של המוצר.

מוצר	סכמת איזון עומסים	סוג המשאב של מפת URL	יעדים נתמכים
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	`EXTERNAL_MANAGED`	עולמי	שירותים לקצה העורפי, קטגוריות לקצה העורפי
מאזן עומסים קלאסי של אפליקציות (ALB)	`EXTERNAL`	עולמי	שירותים לקצה העורפי, קטגוריות לקצה העורפי
מאזן עומסים חיצוני אזורי של אפליקציות (ALB)	`EXTERNAL_MANAGED`	אזורי	שירותים לקצה העורפי, קטגוריות לקצה העורפי
מאזן עומסים פנימי של אפליקציות (ALB) באזורים שונים	`INTERNAL_MANAGED`	עולמי	שירותים לקצה העורפי, קטגוריות לקצה העורפי
מאזן עומסים פנימי אזורי של אפליקציות (ALB)	`INTERNAL_MANAGED`	אזורי	שירותים לקצה העורפי, קטגוריות לקצה העורפי
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	עולמי	שירותים לקצה העורפי
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	אזורי	שירותים לקצה העורפי

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

איך פועלות מפות URL

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

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

אלה היעדים האפשריים ב-Cloud Service Mesh:

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

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

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

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

כתובת IP אחת:
- כל הבקשות לארגון מגיעות לאותה כתובת IP ולאותו מאזן עומסים.
- תנועת הנתונים מופנית לשירותים שונים לקצה העורפי על סמך כתובת ה-URL של הבקשה.
שני דומיינים:
- ‫example.net מארח סרטוני הדרכה.
- ‫example.org מארח את האתר של הארגון שלכם.
ארבע קבוצות של שרתים:
- אחד מארח את האתר של הארגון (שירות לקצה העורפי: org-site).
- אחד מארח את האתר הכולל של סרטוני ההדרכה (שירות לקצה העורפי: video-site).
- אחד מארח סרטוני הדרכה באיכות גבוהה (HD) (שירות לקצה העורפי: video-hd).
- אחד מארח סרטוני הדרכה באיכות רגילה (SD) (שירות לקצה העורפי: video-sd).

אתם רוצים שהדברים הבאים יקרו:

בקשות ל-example.org (או לכל דומיין אחר מלבד example.net) לעבור לשירות לקצה העורפי org-site.
בקשות ל-example.net שלא תואמות לנתיבים ספציפיים יותר, כדי לעבור לשירות לקצה העורפי video-site.
בקשות אל example.net/video/hd/* כדי לעבור לשירות הקצה העורפי של video-hd.
בקשות אל example.net/video/sd/* כדי לעבור לשירות הקצה העורפי של video-sd.

--path-rule עבור /video/* תואם למזהי URI כמו /video/test1 ו-/video/test2. עם זאת, כלל הנתיב הזה לא תואם לנתיב /video.

אם מאזן העומסים מקבל בקשה עם /../ בכתובת ה-URL, הוא משנה את כתובת ה-URL על ידי הסרת קטע הנתיב שלפני .., ומגיב עם כתובת ה-URL ששונתה. לדוגמה, כשנשלחת בקשה ל-http://example.net/video/../abc, מאזן העומסים מגיב בהפניה אוטומטית מסוג 302 ל-http://example.net/abc. רוב הלקוחות מגיבים בשליחת בקשה לכתובת ה-URL שמאזן העומסים החזיר (במקרה הזה, http://example.net/abc). ההפניה האוטומטית מסוג 302 לא מתועדת ב-Cloud Logging.

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

דוגמה להגדרת שירות לקצה העורפי. — דוגמה להגדרה של שירות לקצה העורפי (לחצו כדי להגדיל).

מתן שמות למאזני עומסים

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

Google Cloud מסוף. אם יוצרים מאזן עומסים של אפליקציות באמצעות מסוףGoogle Cloud , למפת URL מוקצה באופן אוטומטי אותו שם שהזנתם למאזן העומסים.
Google Cloud CLI או API. אם אתם יוצרים מאזן עומסים של אפליקציות באמצעות ה-CLI של gcloud או ה-API, אתם צריכים להזין שם לבחירתכם בזמן יצירת מפת URL. השם של מפת URL מופיע במסוףGoogle Cloud כשם של מאזן העומסים.

במאמר סקירה כללית על שירותי קצה עורפי: מתן שמות למאזני עומסים מוסבר איך פועל מתן השמות למאזני עומסי רשת של שרתי proxy ולמאזני עומסי רשת מסוג Passthrough.

רכיבים של מפת URL

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

שם מארח הוא החלק של שם הדומיין בכתובת URL. לדוגמה, החלק של שם המארח בכתובת ה-URL‏ http://example.net/video/hd הוא example.net.
נתיב הוא החלק בכתובת ה-URL שמופיע אחרי שם המארח ומספר היציאה האופציונלי. לדוגמה, החלק של הנתיב בכתובת ה-URL‏ http://example.net/video/hd הוא /video/hd.

הגדרת מאזן עומסים עם מפת URL בסיסית. — הגדרת מאזן עומסים עם מפת URL בסיסית (לחצו כדי להגדיל).

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

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

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

הערה: קטגוריות קצה עורפי לא נתמכות ב-Cloud Service Mesh.
כלל מארח (hostRules). כלל מארח מפנה בקשות שנשלחות לשם מארח משויך אחד או יותר אל מאתר נתיבים יחיד (pathMatchers). החלק של שם המארח בכתובת URL תואם בדיוק או תואם באמצעות ביטויים רגולריים לקבוצת שמות המארחים שהוגדרו בכלל המארח. בכלל של מארח ונתיב במפת URL, אם משמיטים את המארח, הכלל תואם לכל מארח מבוקש. כדי להפנות בקשות של http://example.net/video/hd למתאם נתיבים, צריך כלל מארח אחד שכולל לפחות את שם המארח example.net. אותו כלל מארח יכול גם לטפל בבקשות לשמות מארחים אחרים, אבל הוא יפנה אותם לאותו מתאם נתיבים.

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

אפשר להתאים את כל שמות המארחים על ידי ציון התו הכללי לחיפוש * בכלל המארח. לדוגמה, אם כתובות ה-URL הן http://example.org,‏ http://example.net/video/hd ו-http://example.com/audio, אפשר להתאים את שלושת שמות המארחים example.org,‏ example.net ו-example.com על ידי ציון * בכלל המארח. אפשר גם להתאים שם מארח חלקי על ידי ציון התו הכללי לחיפוש *. לדוגמה, כלל המארח *.example.net תואם לשני שמות המארחים news.example.net ו-finance.example.net.

מספר היציאה. מאזני עומסים קלאסיים של אפליקציות (ALB) מטפלים במספרי יציאות באופן שונה ממאזני עומסים אחרים של אפליקציות. במאזן עומסים קלאסי של אפליקציות (ALB), רק שם המארח בכתובת ה-URL נלקח בחשבון כשמתאימים כלל מארח. לדוגמה, בקשות example.net ליציאה 8080 וליציאה 80 תואמות לכלל המארח example.net. בכל שאר מאזני העומסים של האפליקציות, אפשר להשתמש בפרמטר Host rule כדי לציין מספר יציאה. לדוגמה, כדי להפנות בקשות של example.net ליציאה 8080, מגדירים את כלל המארח ל-example.net:8080.

הערה: מאזן העומסים לא מאמת את הערך של שם המארח בכתובת ה-URL. הלקוחות יכולים להגדיר ערכים שרירותיים לשם המארח, למשל על ידי הגדרת הכותרת Host. אל תשתמשו בשדה שם המארח כדי להטמיע בקרת גישה לאפליקציה.
התאמת נתיב (pathMatchers). התאמת נתיב היא פרמטר ההגדרה שאליו מפנה כלל המארח. היא מגדירה את הקשר בין החלק של הנתיב בכתובת ה-URL לבין השירות לקצה העורפי או קטגוריית הקצה העורפי שאמורים לטפל בבקשה. התאמת נתיב מורכבת משני רכיבים:
- שירות קצה עורפי ברירת מחדל של כלי להתאמת נתיבים או קטגוריית קצה עורפי ברירת מחדל של כלי להתאמת נתיבים. לכל התאמת נתיב צריך לציין לפחות שירות לקצה העורפי של ברירת מחדל או קטגוריית קצה עורפי של ברירת מחדל, אבל לא את שניהם. ברירת המחדל הזו מייצגת את שירות הקצה העורפי או את קטגוריית הקצה העורפי שאליהםGoogle Cloud מפנה בקשות לכתובות URL ששמות המארחים שלהן תואמים לכלל מארח שמשויך למתאם הנתיבים, ושנתיבי כתובות ה-URL שלהן לא תואמים לאף כלל נתיב במתאם הנתיבים.
- כללי נתיבים. לכל התאמת נתיב אפשר לציין כלל נתיב אחד או יותר, שהם צמדי מפתח/ערך שממפים נתיב כתובת ה-URL לשירות לקצה העורפי אחד או לקטגוריית קצה עורפי אחת.
  
  אופרטורים גמישים להתאמת דפוסים מאפשרים להתאים כמה חלקים של נתיב כתובת ה-URL, כולל כתובות URL חלקיות וסיומות (סיומות קבצים), באמצעות תחביר של תווים כלליים לחיפוש. האופרטורים האלה יכולים לעזור כשצריך לנתב תנועה ולבצע שכתובים על סמך נתיבים מורכבים של כתובות URL. אפשר גם לשייך רכיב נתיב אחד או יותר למשתנים בעלי שם, ואז להתייחס למשתנים האלה כשמשכתבים את כתובת ה-URL. בעזרת משתנים בעלי שם, אתם יכולים לשנות את הסדר של רכיבי כתובת ה-URL ולהסיר אותם לפני שהבקשה נשלחת למקור. פרטים נוספים זמינים במאמר תווים כלליים לחיפוש, ביטויים רגולריים וכתובות URL דינמיות בכללי נתיב.
  
  אם אתם צריכים יכולות ניתוב מתקדמות יותר, למשל אם אתם רוצים להפנות תנועה של כתובת URL ייחודית לכמה שירותים, אתם יכולים להשתמש בכללי ניתוב במקום בכללי נתיב.
- כללי מסלול. אפשר להשתמש בכללי מסלול כחלופה לכללי נתיב כשצריך יכולות מתקדמות של ניתוב תנועה, כמו ניתוב תנועה על סמך נתיב כתובת ה-URL, כותרות HTTP ופרמטרים של שאילתה.
  
  אפשר להגדיר כללי מסלול עם אופרטורים גמישים להתאמת דפוסים ומשתנים בעלי שם. האופרטורים האלה יכולים לעזור כשצריך לנתב תנועה ולבצע שכתובים על סמך נתיבים מורכבים של כתובות URL. פרטים נוספים זמינים במאמר תווים כלליים לחיפוש ואופרטורים של התאמה לתבנית בתבניות נתיב לכללי מסלול.
  
  אפשר גם להגדיר כללי מסלול שיושוו לביטויים רגולריים שתואמים לנתיב, לפרמטרים של השאילתה או לכותרות בבקשה הנכנסת. פרטים נוספים זמינים במאמר ביטויים רגולריים בכללי מסלול.
  
  למידע נוסף על אפשרויות ההגדרה של כללי ניתוב, ראו כללים מתקדמים למארחים, לנתיבים ולניתוב.

הקשר בין שם המארח לכלל המארח

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

הקשר בין כלל המארח לבין התאמת הנתיב

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

הקשר בין כתובת ה-URL לבק-אנד

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

‫Google Cloud משתמש בחלק של שם המארח בכתובת ה-URL כדי לבחור כלל מארח יחיד ואת התאמת הנתיב שאליה הוא מפנה.
כשמשתמשים בכללי נתיבים במתאם נתיבים, אי אפשר ליצור יותר מכלל נתיב אחד לאותו נתיב. לדוגמה, אי אפשר להפנות בקשות ל-/videos/hd ליותר משירות אחד לקצה העורפי או ליותר מקטגוריית קצה עורפי אחת. לשירותי קצה עורפי יכולות להיות קבוצות של מכונות קצה עורפי או קבוצות של נקודות קצה ברשת (NEG) בקצה העורפי, באזורים שונים. אתם יכולים ליצור קטגוריות של קצה עורפי שמשתמשות בסוגי אחסון בכמה אזורים.

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

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

מפות URL ופרוטוקולים

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

מפת ה-URL הפשוטה ביותר

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

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

מפת URL ללא כללים, מלבד כלל ברירת המחדל. — מפת URL ללא כללים, מלבד ברירת המחדל (לחצו כדי להגדיל).

סדר הפעולות

עבור שם מארח ונתיב נתונים בכתובת URL מבוקשת, Google Cloud משתמש בהליך הבא כדי להפנות את הבקשה לשירות לקצה העורפי או לקטגוריית הקצה העורפי הנכונים, בהתאם להגדרות במפת URL:

אם מפת כתובות ה-URL לא מכילה כלל מארח לשם המארח של כתובת ה-URL, ‏Google Cloud מפנה את הבקשות לשירות ברירת המחדל לקצה העורפי או לקטגוריית ברירת המחדל לקצה העורפי של מפת כתובות ה-URL, בהתאם למה שהגדרתם.
אם מפת URL מכילה כלל מארח שכולל את שם המארח של כתובת ה-URL, המערכת בודקת את התאמת הנתיב שאליה מפנה כלל המארח:
- אם למתאם הנתיבים יש כלל נתיב שתואם בדיוק לנתיב של כתובת ה-URL,‏ Google Cloud מפנה את הבקשות לשירות לקצה העורפי או לקטגוריית הקצה העורפי של כלל הנתיב הזה.
- אם למתאם הנתיבים אין כלל נתיב שתואם בדיוק לנתיב של כתובת ה-URL, אבל יש לו כלל נתיב שמסתיים ב-/* והקידומת שלו תואמת לקטע הארוך ביותר של הנתיב של כתובת ה-URL, אז Google Cloudמפנה את הבקשות לשירות לקצה העורפי או לקטגוריית הקצה העורפי של כלל הנתיב הזה. לדוגמה, במפת URL שמכילה שני כללים להתאמת נתיבים, /video/hd/movie1 ו-/video/hd/*, אם כתובת ה-URL מכילה את הנתיב המדויק /video/hd/movie1, היא תותאם לכלל הנתיב הזה.
- אם אף אחד מהתנאים הקודמים לא מתקיים, Google Cloud מפנה את הבקשות לשירות הקצה העורפי המוגדר כברירת מחדל או לקטגוריית הקצה העורפי המוגדרת כברירת מחדל של התאמת הנתיבים, בהתאם למה שהגדרתם.

אילוצים בהגדרת מפת כתובות ה-URL

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

התאמות של ביטויים רגולריים בכללי מארח וכללי מסלול

כללי מארח מאפשרים להתאים את החלק של שם המארח בכתובת URL לקבוצת שמות המארחים שהוגדרו בכלל המארח. בשדה hostRules[].hosts[] אפשר להשתמש בשם מארח ספציפי או בתו כללי לחיפוש * כדי להתאים לשם המארח בבקשה הנכנסת.

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

‫pathMatchers[].routeRules[].matchRules[].regexMatch: ביטוי רגולרי שמשמש להתאמה לנתיב של הבקשה הנכנסת.
‫pathMatchers[].routeRules[].matchRules[].headerMatches[].regexMatch: ביטוי רגולרי שמכיל פרדיקט שתואם לכותרת של הבקשה הנכנסת.
‫pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].regexMatch: ביטוי רגולרי שמכיל פרדיקט שתואם לפרמטר של שאילתה בבקשה הנכנסת.

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

הערות נוספות לגבי השימוש:

יש תמיכה בביטויים רגולריים רק במוצרים הבאים:
- מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
- מאזני עומסים פנימיים של אפליקציות (ALB) באזורים שונים
- מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
- מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)
מאזני עומסים קלאסיים של אפליקציות (ALB) לא תומכים בביטויים רגולריים.
צריך להשתמש בתחביר RE2 כדי ליצור את הביטויים הרגולריים. לרשימה המלאה של המגבלות והאופרטורים שמותרים במפות URL, קראו את מפרטי RE2 למפות URL.
התאמה של ביטויים רגולריים היא פעולה יקרה מבחינת צריכת הזיכרון וזמן האחזור של עיבוד הבקשות. אם אתם בוחרים להשתמש בהתאמה של ביטויים רגולריים, אתם צריכים להביא בחשבון את הפגיעה בביצועים כשאתם מתכננים את הפריסה. לדוגמה, אם יש לכם מפת URL עם ביטוי רגולרי אחד, זמן האחזור של מאזן העומסים צפוי לגדול ב-100 מיקרו-שניות לכל בקשה. אם במפת URL יש 5 ביטויים רגולריים להתאמה, זמן הטעינה צפוי לגדול ב-200 מיקרו-שניות לכל בקשה.

דוגמה 1: שימוש בביטוי רגולרי להתאמת נתיב

הנתיב נחשב לתואם אם הוא תואם לביטוי הרגולרי שצוין על ידי regexMatch אחרי הסרת כל הפרמטרים של השאילתה והעוגנים שסופקו עם כתובת ה-URL המקורית. לדוגמה, במפות ה-URL לדוגמה הבאות, הביטוי הרגולרי של כלל המסלול, /videos/hd.*, יחול על כתובת URL עם הנתיב /videos/hd-abcd?key=245.

defaultService: projects/example-project/global/backendServices/org-site
name: rule-match-url-map
hostRules:
- hosts:
  - '*' # Match any host
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
pathMatchers:
- name: video-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/global/backendServices/video-site
  routeRules:
  - priority: 100000
    matchRules:
    - regexMatch: /videos/hd.*
    routeAction:
      weightedBackendServices:
      - backendService: projects/example-project/global/backendServices/video-hd
        weight: 100

הסבר על כל שדה במפת URL לדוגמה:

‫defaultService: מציין את שירות ברירת המחדל לקצה העורפי שבו צריך להשתמש אם אין כללים אחרים במפת כתובות ה-URL שתואמים לבקשה הנכנסת.
name: מקצה את השם rule-match-url-map להגדרת מפת URL זו.
‫hostRules: הגדרת רשימת כללים להתאמה של כותרת המארח של בקשות נכנסות. הכלל הראשון תואם לכל מארח (*) ומפנה תנועה אל pathMatcher בשם video-matcher. הכלל השני תואם ספציפית למארח example.net וגם מפנה תנועה למתאם הנתיבים שנקרא video-matcher.
‫pathMatchers: מגדיר רשימה של התאמות נתיבים עם שם.
‫name: מגדיר התאמת נתיב בשם video-matcher.
‫defaultService: הגדרת שירות ברירת המחדל למתאם הנתיבים הזה. השירות הזה משמש אם בקשה תואמת לכללי המארח שמפנים אל video-matcher, אבל לא תואמת לאף אחד מכללי ה-routeRules שבתוכו.
routeRules: מכיל רשימה של כללים להתאמה לנתיב כתובת ה-URL.
‫priority: הגדרת העדיפות של הכלל הזה ל-100000. הכללים נבדקים לפי סדר העדיפות, מהמספר הנמוך ביותר למספר הגבוה ביותר.
‫matchRules: מכיל את התנאים להתאמה של כלל המסלול הזה.
regexMatch: התנאי הזה בודק אם נתיב כתובת ה-URL תואם לביטוי הרגולרי /videos/hd.* (לדוגמה, "‎/videos/hd" ו-"‎/videos/hd-caching").
‫routeAction: מציין את הפעולה שתתבצע אם כל התנאים ב-matchRules מתקיימים.
‫weightedBackendServices: חלוקת התנועה בין רשימה של שירותים לקצה העורפי על סמך משקלים.
‫backendService: מציין את שירות הקצה העורפי שאליו תנותב התנועה.
‫weight: מקצה משקל של 100 לשירות לקצה העורפי הזה. מכיוון שזה השירות היחיד ברשימה, הוא יקבל 100% מהתנועה שתואמת ל-routeRule הזה.

במפת URL הבאה מוצגת דוגמה דומה בלי להשתמש ב-routeAction.

defaultService: projects/example-project/global/backendServices/video-site
name: path-matcher-videos
routeRules:
  matchRules:
  - regexMatch: /videos/hd.*
  priority: 100000
  service: projects/example-project/global/backendServices/video-hd

דוגמה 2: שימוש בביטוי רגולרי להתאמת כותרות

הכותרת נחשבת כתואמת אם הערך של הכותרת תואם לביטוי הרגולרי שצוין על ידי regexMatch. לדוגמה, במפת כתובות ה-URL הבאה, הביטוי הרגולרי של שם הכותרת, .*Android.*-hd, יחול על בקשה עם הכותרת User-Agent:123Androidabc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
name: header-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: header-matcher
pathMatchers:
- name: header-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
  routeRules:
  - priority: 1
    matchRules:
    - headerMatches:
      - headerName: User-Agent
        regexMatch: .*Android.*-hd
    # This prefix match applies to the path part of the URL
    - prefixMatch: /video/
    # service: can be used instead of routeAction if no other actions are needed
    service: projects/example-project/regions/us-central1/backendServices/video-backend-service
    # Alternatively, use routeAction to specify the service:
    # routeAction:
    #   weightedBackendServices:
    #   - backendService: projects/example-project/regions/us-central1/backendServices/video-backend-service
    #     weight: 100

הסבר על כל שדה במפת URL לדוגמה:

‫defaultService: מציין את שירות ברירת המחדל לקצה העורפי שבו צריך להשתמש אם אין כללים אחרים במפת כתובות ה-URL שתואמים לבקשה הנכנסת.
‫name: מקצה את השם header-match-url-map להגדרת מפת URL זו.
‫hostRules: מגדיר רשימה של כללים להתאמה של כותרת המארח של בקשות נכנסות. הכלל תואם לכל מארח ('*') ומפנה את התנועה אל הכותרת התואמת בשם pathMatcher.
‫pathMatchers: מגדיר רשימה של התאמות נתיבים עם שם.
‫name: מגדיר כלי להתאמת נתיבים בשם header-matcher.
‫defaultService: הגדרת שירות ברירת המחדל להתאמת הנתיב הזו. השירות הזה משמש אם בקשה תואמת לכלל המארח אבל לא תואמת לאף אחד מה-routeRules בתוך התאמת הנתיב הזו.
‫routeRules: מכיל רשימה של כללים להתאמת בקשות נכנסות על סמך כותרות ונתיבים.
‫priority: הגדרת העדיפות של הכלל הזה ל-1. הכללים נבדקים לפי הסדר, ממספר העדיפות הנמוך ביותר לגבוה ביותר.
‫matchRules: מכיל רשימה של תנאים שכולם צריכים להתקיים כדי שהכלל יתאים.
‫headerMatches: מציין תנאים שמבוססים על כותרות של בקשות.
‫headerName: חיפוש של הכותרת User-Agent.
‫regexMatch: בודק אם הערך של הכותרת User-Agent תואם לביטוי הרגולרי .*Android.*-hd. הביטוי הזה יתאים לסוכני משתמש שמציינים מכשיר Android, עם מחרוזת שמכילה את התווים "‎-hd".
prefixMatch: כשהתנאי מוגדר לערך /video/, הוא בודק אם נתיב כתובת ה-URL מתחיל ב-"‎/video/‎".
‫service: אם כל התנאים של matchRules מתקיימים, תעבורת נתונים מופנית לשירות לקצה העורפי הזה.
הקטע routeAction שסומן כהערה מציג דרך חלופית לציין את השירות לקצה העורפי, שנדרשת אם צריך להגדיר פעולות אחרות של מסלולים, כמו שכתוב של כתובות URL, טרנספורמציות של כותרות או שירותים משוקללים לקצה העורפי.

דוגמה 3: שימוש בביטוי רגולרי כדי להתאים פרמטרים של שאילתה

פרמטר השאילתה נחשב להתאמה אם הערך של הנתיב עם פרמטרים של שאילתה תואם לביטוי הרגולרי שצוין על ידי regexMatch. לדוגמה, במפת כתובות ה-URL הבאה, הביטוי הרגולרי של פרמטר השאילתה, /im.*/.*.html, יחול על כתובת URL עם פרמטרים של שאילתה כמו /images/random_page.html?param1=param_value_123abc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
name: query-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: query-matcher
pathMatchers:
- name: query-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
  routeRules:
  - priority: 1
    matchRules:
    - queryParameterMatches:
      - name: param1   #parameter name in query
        regexMatch: param_value_.*-hd
    # This regexMatch applies to the path part of the URL
    - regexMatch: /im.*/.*.html
    # Directs traffic to this service if all conditions in matchRules are met
    service: projects/example-project/regions/us-central1/backendServices/sample-images-bs

הסבר על כל שדה במפת URL לדוגמה:

‫hostRules: מוסיף כלל להתאמה לכל המארחים (*) ומפנה את התנועה אל pathMatcher בשם query-matcher.
‫pathMatchers: מגדיר כלי להתאמת נתיבים בשם query-matcher.
‫routeRules: הצבת הבלוק routeRules שסופק בתוך query-matcher.
‫priority: הגדרת העדיפות של הכלל הזה ל-1. הכללים נבדקים לפי הסדר, ממספר העדיפות הנמוך ביותר למספר העדיפות הגבוה ביותר.
‫matchRules: מכיל את התנאים של routeRules.
queryParameterMatches: בודק אם הפרמטר של השאילתה שנקרא "param1" תואם לביטוי הרגולרי param_value_.*-hd.
‫regexMatch: הביטוי הרגולרי /im.*/.*.html חל על הנתיב של כתובת ה-URL (לדוגמה, ‎/images/random_page.html), לפני מחרוזת השאילתה.
‫service: מציין את השירות לקצה העורפי שבו צריך להשתמש אם כל התנאים ב-matchRules מתקיימים.

שכתוב כתובות URL באמצעות ביטויים רגולריים לכללי מסלול

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

אפשר לציין ביטויים רגולריים באמצעות השדות הבאים:

‫pathMatchers[].routeRules[].routeAction.urlRewrite.regexRewrite.pathPattern: ביטוי רגולרי בתחביר RE2 שמשמש להתאמה ולתיעוד של חלקים מהנתיב של הבקשה הנכנסת.
‫pathMatchers[].routeRules[].routeAction.urlRewrite.regexRewrite.pathSubstitution: מחרוזת שמשמשת לשחזור הנתיב לפני שליחת הבקשה לשירות לקצה העורפי. אפשר להפנות לקבוצות לחילוץ מ-pathPattern באמצעות תחביר עם שם \g<name> (לקבוצות עם שם כמו (?<name>re)) או תחביר עם מספר כמו \1 או \2.

איך פועלות קבוצות לחילוץ ב-RE2

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

קבוצות החילוץ מוגדרות בשדה pathPattern באמצעות הפורמט (?<name>re) או (?P<name>re), כאשר name הוא שם המשתנה שהוקצה לקטע שחולץ בנתיב כתובת ה-URL שיוחלף, ו-re הוא תבנית הביטוי הרגולרי שמשמשת להתאמה לקטע הזה. לאחר מכן, קבוצות החילוץ מוחלפות בשדה pathSubstitution באמצעות הפורמט \g<name>.

לדוגמה:

נתיב כתובת ה-URL של בקשת הלקוח הנכנסת: /api/users/21334/profile.json
pathPattern: /api/users/(?<id>\d+)/(?<path>[a-z]+\.json)
pathSubstitution: /users/\g<id>/\g<path>
הנתיב שנשלח לקצה העורפי: /users/21334/profile.json

שימו לב שקבוצות לחילוץ שכתובות בפורמט (?<name>re) הן גם ממוספרות וגם בעלות שם. אפשר להתייחס אליהם לפי השם, \g<name>, או לפי המספר, \1.

הערות נוספות לגבי השימוש:

אפשר לשכתב כתובות URL באמצעות ביטויים רגולריים רק במוצרים הבאים:
- מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
- מאזני עומסים פנימיים של אפליקציות (ALB) באזורים שונים
- מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
- מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)
במאזני עומסים קלאסיים של אפליקציות (ALB) אין תמיכה בביטויים רגולריים.
כדי ליצור ביטויים רגולריים, צריך להשתמש בתחביר RE2. הרשימה המלאה של המגבלות והאופרטורים שמותרים במפות URL מופיעה במפרט RE2 למפות URL.
אפשר לציין רק פעולה אחת של שכתוב כתובת URL לכל כלל מסלול. אי אפשר להשתמש ב-regexRewrite יחד עם pathPrefixRewrite או pathTemplateRewrite.
בשדה pathSubstitution אפשר להגדיר עד שמונה קבוצות לחילוץ, שצריך להגדיר בשדה pathPattern.
השדות pathPattern ו-pathSubstitution מוגבלים ל-250 תווים לכל היותר.

דוגמה: שכתוב של כתובת URL באמצעות קבוצות לחילוץ של ביטויים רגולריים

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

בדוגמה הזו, כתובות URL של בקשות נכנסות כמו /region/us-central1/bucket/my-bucket/stage/dev/object.pdf נכתבות מחדש ל-/us-central1/my-bucket-dev/object.pdf לפני שהן מועברות דרך שרת proxy לשירות לקצה העורפי.

defaultService: projects/example-project/regions/us-central1/backendServices/default-bs
name: regex-rewrite-url-map
pathMatchers:
- name: region-matcher
  defaultService: projects/example-project/regions/us-central1/backendServices/default-bs
  routeRules:
  - matchRules:
    - prefixMatch: /region/
    priority: 1
    service: projects/example-project/regions/us-central1/backendServices/rewrite-bs
    routeAction:
      urlRewrite:
        regexRewrite:
          pathPattern: "/region/(?<reg>[a-z0-9-]+)/bucket/(?<bkt>[a-z0-9-]+)/stage/(?<stg>[a-z0-9-]+)/object\\.pdf"
          pathSubstitution: "/\\g<reg>/\\g<bkt>-\\g<stg>/object.pdf"

הסבר על השדות שמופיעים בדוגמה של מפת URL:

‫defaultService: מציין את שירות ברירת המחדל לקצה העורפי שאליו ינותבו הבקשות אם אין routeRules אחר שתואם לבקשה הנכנסת.
‫name: שם שהמשתמש מגדיר למפת URL זו.
‫routeRules: רשימת כללים שמגדירים איך התנועה מותאמת ומנותבת. הכללים נבדקים לפי סדר העדיפות שלהם.
‫matchRules: מערך של תנאים שצריכים להתקיים כדי שהכלל הזה יחול.
‫prefixMatch: התאמה לתחילת הנתיב של כתובת ה-URL. בדוגמה המתוקנת, הוא מבטיח שהכלל יחול רק על נתיבים שמתחילים ב-/region/.
‫priority: מספר שלם שקובע את הסדר שבו הכללים נבדקים. מספרים נמוכים יותר מייצגים עדיפות גבוהה יותר.
‫service: השירות לקצה העורפי שאליו תועבר התנועה אם מתקיימים התנאים של matchRules בכלל הזה ופעולת הניתוב מבוצעת.
‫routeAction: הפעולה שצריך לבצע כשבקשה תואמת ל-matchRules.
‫urlRewrite: מגדיר איך לשנות את כתובת ה-URL לפני שהיא מועברת דרך שרת proxy לשירות לקצה העורפי.
‫regexRewrite: הגדרת שכתוב של כתובות URL באמצעות ביטויים רגולריים.
‫pathPattern: הביטוי הרגולרי (באמצעות תחביר Google RE2) שמשמש להתאמה לנתיב כתובת ה-URL הנכנסת. קבוצות לחילוץ עם שם בפורמט (?<name>re) משמשות לחילוץ חלקים מהנתיב. בדוגמה, "/region/(?<reg>[a-z0-9-]+)/bucket/(?<bkt>[a-z0-9-]+)/stage/(?<stg>[a-z0-9-]+)/object\\.pdf" מתעד את האזור (reg), את שם הקטגוריה (bkt) ואת שם השלב (stg).
‫pathSubstitution: המחרוזת שמשמשת לשחזור הנתיב. הוא מפנה לקבוצות לחילוץ עם השמות מהתבנית באמצעות התחביר \g<name>. בדוגמה, "/\\g<reg>/\\g<bkt>-\\g<stg>/object.pdf" משתמש בערכים reg, bkt ו-stg שנלכדו כדי ליצור את הנתיב החדש: /us-central1/my-bucket-dev/object.pdf.

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

כלל נתיב (pathMatchers[].pathRules[]) יכול לכלול תו כללי לחיפוש (*) רק אחרי תו לוכסן (/). לדוגמה, /videos/* ו-/videos/hd/* הם כללי נתיב תקינים, אבל /videos* ו-/videos/hd* לא תקינים.
כללי הנתיב לא משתמשים בביטויים רגולריים או בהתאמה למחרוזת משנה. ב-PathTemplateMatch אפשר להשתמש באופרטורים פשוטים להתאמת נתיבים. לדוגמה, כללי נתיב של /videos/hd או /videos/hd/* לא חלים על כתובת URL עם הנתיב /video/hd-abcd. עם זאת, כלל נתיב ל-/video/* חל על הנתיב הזה.
בהתאמה לפי קידומת (pathMatchers[].routeRules[].matchRules[].prefixMatch), התו * לא נחשב לתו כללי לחיפוש, אלא לתו מילולי.
במגדירי התאמות לנתיבים (ובמפות URL באופן כללי) אין תכונות שפועלות כמו ההוראה <LocationMatch> של Apache. אם יש לכם אפליקציה שיוצרת נתיבי כתובות URL דינמיים עם קידומת משותפת, כמו /videos/hd-abcd ו-/videos/hd-pqrs, ואתם צריכים לשלוח בקשות שבוצעו לנתיבים האלה לשירותים שונים לקצה העורפי, יכול להיות שלא תוכלו לעשות זאת באמצעות מפת כתובות URL. במקרים שבהם יש רק כמה כתובות URL דינמיות אפשריות, אולי תוכלו ליצור התאמת נתיב עם קבוצה מוגבלת של כללי נתיב. במקרים מורכבים יותר, צריך לבצע התאמה של ביטויים רגולריים מבוססי-נתיב בקצוות העורפיים.

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

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

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

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

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

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

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

  pathMatchers:
    - name: cart-matcher
      routeRules:
        - description: CartService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
          service: cart-backend
          priority: 1
          routeAction:
            urlRewrite:
              pathTemplateRewrite: '/{username}-{cartid}/'
    - name: user-matcher
      routeRules:
        - description: UserService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
          service: user-backend
          priority: 1

זה מה שקורה כשלקוח מבקש את /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB, שמכיל גם פרטי משתמש וגם פרטי עגלת קניות:

נתיב הבקשה תואם ל-pathTemplateMatch בתוך ה-pathMatcher‏ cart-matcher. המשתנה {username=*} תואם ל-abc@xyz.com והמשתנה {cartid=**} תואם ל-FL0001090004/entries/SJFI38u3401nms.
הפרמטרים של השאילתה מופרדים מהנתיב, הנתיב נכתב מחדש על סמך pathTemplateRewrite והפרמטרים של השאילתה מצורפים לנתיב שנכתב מחדש. אנחנו צריכים להשתמש רק באותם משתנים שבהם השתמשנו כדי להגדיר את pathTemplateMatch ב-pathTemplateRewrite.
הבקשה שנכתבה מחדש נשלחת אל cart-backend עם נתיב כתובת ה-URL שנכתב מחדש: /abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB.

אם הלקוח מבקש במקום זאת את /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234, שכולל רק פרטי משתמש וחשבון, קורה הדבר הבא:

נתיב הבקשה תואם ל-pathTemplateMatch בתוך pathMatcher של user-matcher. הערך הראשון של * תואם ל-abc%40xyz.com והערך השני של * תואם ל-abc-1234.
הבקשה נשלחת אל user-backend.

בטבלה הבאה מפורט התחביר של תבניות הנתיבים.

אופרטור	התאמות
*``**	קטע נתיב יחיד, לא כולל תווי ההפרדה `/` של הנתיב שמסביב.
``**	התאמה לאפס תווים או יותר, כולל כל תו מפריד נתיבים `/` בין כמה קטעי נתיב. אם משתמשים באופרטורים אחרים, האופרטור `**` חייב להיות האופרטור האחרון.
*`{name}` או `{name=}`**	משתנה בעל שם שתואם לפלח נתיב אחד. התאמה לקטע נתיב יחיד, לא כולל תווי ההפרדה `/` של הנתיב שמסביב.
*`{name=news/}`**	משתנה בעל שם שתואם במפורש לשני קטעי נתיב: `news` וקטע של תו כללי לחיפוש `*`.
*`{name=/news/}`*	משתנה בעל שם שתואם לשלושה מקטעי נתיב.
`{name=}`**	משתנה בעל שם שתואם לאפס תווים או יותר. אם הוא קיים, הוא חייב להיות האופרטור האחרון.

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

אפשר לשלב כמה אופרטורים בתבנית אחת.
הפרמטרים של השאילתה מופרדים מהנתיב, הנתיב נכתב מחדש על סמך pathTemplateRewrite והפרמטרים של השאילתה מצורפים לנתיב שנכתב מחדש.
הבקשות לא עוברות נורמליזציה של קידוד באחוזים. לדוגמה, כתובת URL עם תו לוכסן בקידוד אחוזים (%2F) לא מפוענחת לצורה הלא מקודדת.
כל שם של משתנה, כמו {segment} או {region}, יכול להופיע רק פעם אחת באותה תבנית. אם יש כמה משתנים עם אותו שם, הם לא תקינים והמערכת דוחה אותם.
שמות המשתנים הם תלויי אותיות רישיות (case-sensitive) וצריכים להיות מזהים תקינים. כדי לבדוק אם שם המשתנה תקין, צריך לוודא שהוא תואם לביטוי הרגולרי ^[a-zA-Z][a-zA-Z0-9_]*$.
- ‫{API},‏ {api} ו-{api_v1} הם כולם מזהים תקינים. הם מזהים שלושה משתנים נפרדים.
- ‫{1}, ‏{_api} ו-{10alpha} הם לא מזהים תקינים.
אפשר להוסיף עד חמישה אופרטורים לכל תבנית.

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

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

כשמשכתבים כתובת URL, אפשר להשמיט משתנים אם הם לא נדרשים כחלק מכתובת ה-URL המשוכתבת.
לפני כל שכתוב, אתם יכולים לזהות את כתובת ה-URL שנשלחה על ידי הלקוח במקור שלכם על ידי בדיקת כותרות התגובה. כתובת ה-URL המקורית של הלקוח מאוכלסת בכותרת x-client-request-url ובכותרת x-envoy-original-path.

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

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

מידע נוסף על יצירה והגדרה של מפות URL עם כללי מארח וכללי התאמה לנתיב זמין במסמכי התיעוד של gcloud compute url-maps create.

יוצרים מפת URL למאזן העומסים ומציינים שירות לקצה העורפי כברירת מחדל. בדוגמה הזו נוצרת מפת URL בשם video-org-url-map שמפנה לשירות קצה עורפי קיים בשם org-site.
```
gcloud compute url-maps create video-org-url-map \
    --default-service=org-site
```
יוצרים התאמת נתיב בשם video-matcher עם המאפיינים הבאים:
- שירות ברירת המחדל לקצה העורפי הוא video-site, שירות קיים לקצה העורפי.
- מוסיפים כללי נתיב שמפנים בקשות לנתיב המדויק של כתובת ה-URL‏ /video/hd או לתחילית של נתיב כתובת ה-URL‏ /video/hd/* לשירות קיים לקצה העורפי בשם video-hd.
- מוסיפים כללי נתיב שמפנים בקשות לנתיב המדויק של כתובת ה-URL‏ /video/sd או לתחילית של נתיב כתובת ה-URL‏ /video/sd/* לשירות קיים לקצה העורפי בשם video-sd.
```
gcloud compute url-maps add-path-matcher video-org-url-map \
    --path-matcher-name=video-matcher \
    --default-service=video-site \
    --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
```

יוצרים כלל מארח לשם המארח example.net שמפנה למתאם הנתיבים video-matcher.

gcloud compute url-maps add-host-rule video-org-url-map \
    --hosts=example.net \
    --path-matcher-name=video-matcher

מפת URL של video-org-url-map אמורה להיראות כך:

gcloud compute url-maps describe video-org-url-map

creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

מפת URL של video-org-url-map מפנה את כתובות ה-URL המבוקשות לקצוות עורפיים באופן הבא.

מפת URL עם כלל נתיב, התאמות נתיב וכלל מארח. — מפת כתובות URL עם כלל נתיב, התאמות נתיבים וכלל מארח (לחצו כדי להגדיל).

בטבלה הבאה מוסבר עיבוד הבקשה שמוצג בתרשים שלמעלה.

שם המארח	נתיבים של כתובות URL	השירות שנבחר לקצה העורפי	הסיבה לבחירה
שם המארח: `example.org` וכל שמות המארחים האחרים שונים מ- `example.net`	כל הנתיבים	`org-site`	שם המארח לא נמצא באף כלל מארח של מפת URL, ולכן הבקשה מופנית לשירות לקצה העורפי של מפת URL.
שם המארח: `example.net`	`/video` `/video/examples`	`video-site`	הבקשה מועברת לשירות ברירת המחדל לקצה העורפי כי אין כלל נתיב ל-`/video/` או ל-`/video/*`. כלל המארח של `example.net` מפנה למתאם נתיבים, אבל למתאם הנתיבים הזה אין כללי נתיבים שיחולו על הנתיבים האלה.
שם המארח: `example.net`	`/video/hd` `/video/hd/movie1` `/video/hd/movies/movie2` כתובות URL אחרות שמתחילות ב-`/video/hd/*`	`video-hd`	כלל מארח של `example.net` מפנה למתאם נתיבים שכללי הנתיב שלו מפנים בקשות לנתיבי כתובות URL שתואמים בדיוק ל-`/video/hd` או שמתחילים ב-`/video/hd/*` לשירות לקצה העורפי `video-hd`.
שם המארח: `example.net`	`/video/sd` `/video/sd/show1` `/video/sd/shows/show2` כתובות URL אחרות שמתחילות ב-`/video/sd/*`	`video-sd`	כלל מארח של `example.net` מפנה למתאם נתיבים שכללי הנתיב שלו מפנים בקשות לנתיבי כתובות URL שתואמים בדיוק ל-`/video/sd` או שמתחילים ב-`/video/sd/*` לשירות לקצה העורפי `video-sd`.

הפניות לכתובות URL אחרות

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

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

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

‏Method	הגדרות אישיות
הפניה אוטומטית לכתובת ה-URL שמוגדרת כברירת המחדל של מפת ה-URL	`defaultUrlRedirect` ברמה העליונה
הפניה אוטומטית לכתובת URL שמוגדרת כברירת מחדל של התאמת נתיב	`pathMatchers[].defaultUrlRedirect[]`
הפניה לכתובת URL של כלל נתיב של התאמת נתיב	`pathMatchers[].pathRules[].urlRedirect`
הפניה לכתובת URL של כלל מסלול של התאמת נתיב	`pathMatchers[].routeRules[].urlRedirect`

בתוך defaultUrlRedirect או urlRedirect, pathRedirect תמיד פועל באופן הבא:

כל נתיב הבקשה מוחלף בנתיב שאתם מציינים.

בתוך defaultUrlRedirect או urlRedirect, אופן הפעולה של prefixRedirect תלוי באופן השימוש:

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

דוגמאות להפניות אוטומטיות

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

אתם רוצים	ההפניה מתבצעת באמצעות הפניה אוטומטית לכתובת URL שמוגדרת כברירת מחדל
הפניה אוטומטית מ-HTTP ל-HTTPS הפניה אוטומטית מ-http://host.name/path אל https://host.name/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True
הפניה אוטומטית מ-HTTP ל-HTTPS + הפניה אוטומטית של מארח הפניה אוטומטית מ-http://any-host-name/path אל https://www.example.com/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com"
‫HTTP ל-HTTPS + הפניה אוטומטית של מארח + הפניה אוטומטית של נתיב מלא הפניה אוטומטית מ-http://any-host-name/path אל https://www.example.com/newPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath"
‫HTTP ל-HTTPS + הפניה אוטומטית של מארח + הפניה אוטומטית של קידומת הפניה אוטומטית מ-http://any-host-name/originalPath אל https://www.example.com/newPrefix/originalPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix"

בקטע הקוד החלקי הבא יש הערות לכל משאב API:

defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
   ...

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

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

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

איך פועלות מפות URL

מתן שמות למאזני עומסים

רכיבים של מפת URL

הקשר בין שם המארח לכלל המארח

הקשר בין כלל המארח לבין התאמת הנתיב

הקשר בין כתובת ה-URL לבק-אנד

מפות URL ופרוטוקולים

מפת ה-URL הפשוטה ביותר

סדר הפעולות

אילוצים בהגדרת מפת כתובות ה-URL

התאמות של ביטויים רגולריים בכללי מארח וכללי מסלול

דוגמה 1: שימוש בביטוי רגולרי להתאמת נתיב

דוגמה 2: שימוש בביטוי רגולרי להתאמת כותרות

דוגמה 3: שימוש בביטוי רגולרי כדי להתאים פרמטרים של שאילתה

שכתוב כתובות URL באמצעות ביטויים רגולריים לכללי מסלול

איך פועלות קבוצות לחילוץ ב-RE2

דוגמה: שכתוב של כתובת URL באמצעות קבוצות לחילוץ של ביטויים רגולריים

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

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

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

הפניות לכתובות URL אחרות

דוגמאות להפניות אוטומטיות

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

סקירה כללית על מפות של כתובות URL