הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של Apigee Edge
Apigee מאפשר להגדיר את מספר הבקשות המותרות ל-API Proxy לתקופה מסוימת באמצעות מדיניות המכסות.
תבנית אנטי
בקשת proxy ל-API יכולה להיות מטופלת על ידי רכיב אחד או יותר של Apigee שמופצים ונקראים מעבדי הודעות. אם מוגדרים כמה מעבדי הודעות להצגת בקשות 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 Proxy מוגשות על ידי שני מעבדי הודעות.
- לכל מעבד הודעות יש משתנה משלו לספירת המכסה,
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>