שיטות מומלצות להגדרת זמן קצוב לתפוגה של קלט/פלט

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X.
מידע

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

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

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

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

שיטות מומלצות להגדרת זמן קצוב לתפוגה של קלט/פלט

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

  • רכיב ראשון: יש להשתמש תמיד בזמן הקצוב לתפוגה הגבוה ביותר ברכיב הראשון בתהליך הבקשה של ה-API, שהוא אפליקציית הלקוח ב-Apigee Edge.
  • הרכיב האחרון: תמיד יש להשתמש בזמן הקצוב לתפוגה הנמוך ביותר ברכיב האחרון בתהליך הבקשה של ה-API, שהוא השירות לקצה העורפי ב-Apigee Edge.
  • בין רכיבים: יש לוודא שקיים הפרש של לפחות 2-3 שניות בערך הזמן הקצוב לתפוגה שהוגדר בכל רכיב בין הרכיב הראשון לרכיב האחרון בתהליך.
  • נתב: תמיד מומלץ להגדיר (לשנות) את ערך הזמן הקצוב לתפוגה של קלט/פלט אצל מארח וירטואלי ספציפי, במקום להגדיר אותו בנתב. הפעולה הזו מבטיחה שהערך החדש של הזמן הקצוב לתפוגה ישפיע רק על שרתי proxy של ה-API שמשתמשים במארח הווירטואלי הספציפי, ולא על כל שרתי ה-proxy של ה-API שמוצגים על ידי הנתב.

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

  • מעבד הודעות: תמיד מומלץ להגדיר (לשנות) את ערך הזמן הקצוב לתפוגה של קלט/פלט עבור API ספציפי של שרת proxy, במקום להגדיר אותו במעבד ההודעות. הפעולה הזו מבטיחה שהערך החדש של הזמן הקצוב ישפיע רק על שרת ה-proxy הספציפי של ה-API, ולא על כל שרתי ה-proxy של ממשק ה-API שמוצגים על ידי מעבד ההודעות.

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

תרחישים לדוגמה

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

תרחיש 1: בקשות ל-Apigee Edge ישירות מאפליקציות לקוח

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

הגדרה לדוגמה של Apigee ללא מרכיבי ביניים

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

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

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

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

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

    הגדרת הזמן הקצוב לתפוגה של לקוח ל-60 שניות, לאחר מכן לנתב כ-57 שניות ואז למעבד ההודעות כ-55 שניות, ולאחר מכן לשרת הקצה העורפי 52 שניות

תרחיש 2: בקשות ל-Apigee Edge מיישומי לקוח דרך רכיבי ביניים

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

רכיבי הביניים יכולים להיות מאזן עומסים, רשת להעברת תוכן (CDN), NGINX וכו'.

הגדרת Apigee לדוגמה עם רכיב ביניים אחד בין Client ו-Apigee Edge לבין Apigee Edge לשרת קצה עורפי

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

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

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

    מגדירים זמן קצוב לתפוגה בלקוח > רכיב ביניים 1 > נתב > מעבד הודעות > רכיב ביניים 2 - שרת לקצה העורפי

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

    הגדרת זמן קצוב לתפוגה בלקוח ב-63 שניות, לאחר מכן רכיב ביניים 1 ב-60 שניות, לאחר מכן נתב ל-57 שניות, לאחר מכן מעבד ההודעות 55 שניות, לאחר מכן רכיב ביניים 2 ב-52 שניות, ולאחר מכן שרת עורפי ב-59 שניות