Antipattern: הגדרת מכסה שלא מבוזרת

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

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

דוגמת עיצוב

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

נסביר זאת בעזרת דוגמה. כדאי להשתמש במדיניות המכסה הבאה לגבי שרת proxy ל-API:

<!-- /antipatterns/examples/1-6.xml -->
<Quota name="CheckTrafficQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="100"/>
</Quota>

ההגדרות שלמעלה אמורות לאפשר סך כולל של 100 בקשות לשעה.

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

באיור שלמעלה:

• מדיניות המכסה מוגדרת לאפשר 100 בקשות בשעה.
• הבקשות לשרת ה-API של ה-API מטופלות על ידי שני מעבדי הודעות.
• לכל מעבד הודעות יש משתנה ספירת מכסות משלו, quota_count_mp1 ו-quota_count_mp2, כדי לעקוב אחר מספר הבקשות שהם מעבדים.
• לכן, כל אחד ממעבדי ההודעות יאפשר 100 בקשות API בנפרד. ההשפעה נטו היא הטיפול ב-200 בקשות, במקום ב-100 בקשות.

השפעה

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

שרתי הקצה העורפי יכולים:

• להילחץ בגלל עומס תנועה גדול מהצפוי
• ביטול תגובה לבקשות API חדשות יותר שמובילות לשגיאות 503

שיטה מומלצת

כדאי לשקול להגדיר את הרכיב <Distributed> לערך true במדיניות המכסה כדי לוודא שנעשה שימוש במונה משותף למעקב אחרי בקשות ה-API בכל מעבדי ההודעות. אפשר להגדיר את הרכיב <Distributed> כפי שמוצג בקטע הקוד הבא:

<!-- /antipatterns/examples/1-7.xml -->
<Quota name="CheckTrafficQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Distributed>true</Distributed>
  <Allow count="100"/>
</Quota>