אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
בקשות ה-API שמוגשות על ידי אפליקציות הלקוח עוברות דרך רכיבים שונים ב-Apigee Edge לפני שהן מגיעות לשירותי ה-Backend. רוב אפליקציות הלקוח מצפות לקבל את התגובות לבקשות האלה בזמן.
כדי להשיג תגובות בזמן, ערכי הזמן הקצוב לתפוגה של קלט/פלט מוגדרים בכל אחד מהרכיבים שדרכם עוברות בקשות ה-API. אם אחד מהרכיבים בתהליך לוקח יותר זמן מהרכיב הקודם, הרכיב הקודם מגיע לזמן קצוב לתפוגה ומחזיר שגיאות 504 Gateway Timeout.
כשמגדירים את הזמן הקצוב לתפוגה, צריך להגדיר את הערכים בכל אחד מהרכיבים בזהירות רבה, אחרת עלולות להתרחש שגיאות 504 Gateway Timeout.
במסמך הזה מפורטות שיטות מומלצות להגדרת פסק זמן לקלט/פלט ברכיבים שונים שדרכם עוברות בקשות ה-API ב-Apigee Edge.
שיטות מומלצות להגדרת פסק זמן לקלט/פלט
כדאי לפעול לפי השיטות המומלצות הבאות כשמגדירים את הזמן הקצוב לתפוגה של קלט/פלט:
- הרכיב הראשון: תמיד צריך להשתמש בערך הזמן הקצוב לתפוגה הכי גבוה ברכיב הראשון בתהליך הבקשה של ה-API, שהוא אפליקציית הלקוח ב-Apigee Edge.
- הרכיב האחרון: תמיד צריך להשתמש בערך הזמן הקצר ביותר להמתנה (timeout) ברכיב האחרון בתהליך הבקשה של ה-API, שהוא שירות ה-Backend ב-Apigee Edge.
- בין רכיבים: מוודאים שיש הפרש של לפחות 2-3 שניות בין ערך הזמן הקצוב לתפוגה שהוגדר בכל רכיב, בין הרכיב הראשון לרכיב האחרון בתהליך.
- נתב: מומלץ תמיד להגדיר (לשנות) את ערך הזמן הקצוב לתפוגה של קלט/פלט עבור מארח וירטואלי ספציפי, ולא להגדיר אותו בנתב. כך מוודאים שערך הזמן הקצוב לתפוגה החדש ישפיע רק על שרתי ה-API Proxy שמשתמשים במארח הווירטואלי הספציפי, ולא על כל שרתי ה-API Proxy שמסופקים על ידי הנתב.
מגדירים (משנים) את הזמן הקצוב לתפוגה של קלט/פלט בנתב רק כשבטוחים לחלוטין שנדרש ערך חדש של הזמן הקצוב לתפוגה של קלט/פלט או שהוא רלוונטי לכל שרתי ה-API Proxy שפועלים בנתב.
- מעבד ההודעות: תמיד מומלץ להגדיר (לשנות) את ערך הזמן הקצוב לתפוגה של קלט/פלט עבור שרת proxy ספציפי של API, ולא להגדיר אותו במעבד ההודעות. כך מוודאים שערך הזמן הקצוב לתפוגה החדש ישפיע רק על ה-proxy ל-API הספציפי ולא על כל ה-proxies ל-API שמטופלים על ידי מעבד הבקשות.
מגדירים (משנים) את הזמן הקצוב לתפוגה של קלט/פלט במעבד ההודעות רק כשבטוחים לחלוטין שערך הזמן הקצוב לתפוגה של קלט/פלט נדרש או רלוונטי לכל שרתי ה-API Proxy שפועלים במעבד ההודעות.
תרחישים לדוגמה
התרחישים שבקטע הזה יכולים לעזור לכם להבין איך להגדיר נכון את ערכי הזמן הקצוב לתפוגה של קלט/פלט.
תרחיש 1: בקשות ל-Apigee Edge מאפליקציות לקוח ישירות
בקטע הזה מתוארות שיטות מומלצות להגדרת ערכי הזמן הקצוב לתפוגה בהגדרה של Apigee Edge שבה אין רכיבי ביניים בין אפליקציית הלקוח לבין Apigee Edge, ובין Apigee Edge לבין שרת הקצה העורפי.
דוגמה להגדרה של Apigee ללא רכיבי ביניים
אם Apigee Edge מוגדר כמו שמוצג בתרשים שלמעלה, ללא רכיבי ביניים, כדאי לפעול לפי השיטות המומלצות הבאות:
- אפליקציית הלקוח היא הרכיב הראשון בתהליך. צריך להגדיר את הערך של הזמן הקצוב לתפוגה הגבוה ביותר בלקוח.
- השרת העורפי הוא הרכיב האחרון בתהליך. צריך להגדיר את הערך של הזמן הקצוב לתפוגה הנמוך ביותר בשרת הבק-אנד.
- מגדירים את ערכי הזמן הקצוב לתפוגה בכל אחד מהרכיבים בסדר הבא:
בדוגמה הבאה מוצגים ערכי הזמן הקצוב לתפוגה שמוגדרים ברכיבים השונים בהתאם להנחיות שלמעלה, כדי למנוע בעיות:
תרחיש 2: בקשות אל Apigee Edge מאפליקציות לקוח דרך רכיבי ביניים
בקטע הזה מתוארות שיטות מומלצות להגדרת ערכי הזמן הקצוב לתפוגה בהגדרת Apigee Edge שבה יש רכיב ביניים אחד או יותר בין אפליקציית הלקוח לבין Apigee Edge, וגם בין Apigee Edge לבין שרת הקצה העורפי.
הרכיבים המתווכים יכולים להיות מאזן עומסים, רשת להעברת תוכן (CDN), NGINX וכו'.
דוגמה להגדרה של Apigee עם רכיב ביניים אחד בין הלקוח ל-Apigee Edge ובין Apigee Edge לשרת הקצה העורפי
אם Apigee Edge מוגדר כמו בתרשים שלמעלה, עם רכיב ביניים אחד או יותר, כדאי לפעול לפי השיטות המומלצות הבאות:
- אפליקציית הלקוח היא הרכיב הראשון בתהליך. צריך להגדיר את ערך הזמן הקצוב לתפוגה הגבוה ביותר בלקוח.
- השרת העורפי הוא הרכיב האחרון בתהליך. צריך להגדיר את ערך הזמן הקצוב לתפוגה הנמוך ביותר בשרת העורפי.
- מגדירים את ערכי הזמן הקצוב לתפוגה בכל אחד מהרכיבים, כולל רכיבי הביניים, בסדר הבא:
בדוגמה הבאה מוצגים ערכי הזמן הקצוב לתפוגה שמוגדרים ברכיבים השונים בהתאם להנחיות שלמעלה, כדי למנוע בעיות:
