עיצוב נגדי: תגובות לשגיאות מטמון

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X.
מידע

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

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

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

Apigee Edge מספקת את היכולת לאחסן נתונים במטמון בזמן הריצה כדי לשמור על עקביות ומהירה יותר באחזור. תכונת השמירה במטמון זמינה דרך המדיניות PopulateCache. המדיניות LookupCache, המדיניות ValidateCache ומדיניותResponseCache.

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

המדיניות לגבי מטמון התגובה:

  • מפחית את מספר הבקשות שמגיעות לקצה העורפי
  • מפחית את רוחב הפס ברשת
  • משפר את ביצועי ה-API ואת זמני התגובה

נגד דוגמת עיצוב

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

הנה דוגמה למדיניות של מטמון התגובה עם הגדרות ברירת המחדל:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

המדיניות בנושא מטמון התגובה שומרת במטמון תגובות שגיאה כברירת המחדל הגדרה אישית. עם זאת, לא מומלץ לשמור תגובות שגיאה במטמון מחשבה רבה על ההשלכות השליליות, כי:

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

    OR

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

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

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

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

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

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

תרחיש 2: כשל בקצה עורפי/משאב קבוע או קבוע

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

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

    OR

  • השרת העורפי מוסר/לא זמין למשך 24 שעות עקב כשל פתאומי באתר, בעיות שקשורות לעומס (scaling), תחזוקה, שדרוג וכו'.

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

השפעה

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

שיטה מומלצת

  • אל תשמרו את תגובות השגיאה במטמון התגובות. עליך לוודא שהאלמנטים הרכיב <ExcludeErrorResponse> מוגדר להיות true מדיניותResponseCache שמונעת שמירה של תגובות שגיאה במטמון כפי שמוצג בקוד הבא . ב- בהגדרה הזו רק התגובות לקודי ההצלחה שמוגדרים כברירת המחדל הם 200 עד 205 (אלא אם קודי הצלחה שונו) יישמרו במטמון.
    <!-- /antipatterns/examples/1-2.xml -->
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
      <DisplayName>TargetServerResponseCache</DisplayName>
      <CacheKey>
        <KeyFragment ref="request.uri" />
      </CacheKey>
      <Scope>Exclusive</Scope>
      <ExpirySettings>
        <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
      </ExpirySettings>
      <CacheResource>targetCache</CacheResource>
      <ExcludeErrorResponse>true</ExcludeErrorResponse>
    </ResponseCache>
  • אם יש לכם דרישה לשמור את תגובות השגיאה במטמון מסיבה ספציפית, עליכם יכול לקבוע את משך הזמן המקסימלי/המדויק שבו הכשל יזוהה (אם אפשרי):
    • מגדירים את זמן התפוגה כראוי כדי לוודא שלא שומרים את תגובות השגיאה במטמון ארוך יותר מהזמן שבו ניתן לראות את הכשל.
    • יש להשתמש במדיניות ResponseCache כדי לשמור את תגובות השגיאה במטמון ללא התחילית רכיב <ExcludeErrorResponse>.

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

  • ב-Apigee לא מומלץ לשמור במטמון תשובות 5xx משרתי קצה עורפי.