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

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

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

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

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

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

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

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

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

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

• מדיניות המכסה מוגדרת ל-100 בקשות בשעה.
• שני מעבדי הודעות ממלאים את הבקשות לשרת ה-proxy ל-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>