אנטי-תבנית: הגדרת מכסה לא מבוזר

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

תבנית אנטי

בקשה ל-proxy ל-API יכולה להיות מטופלת על ידי רכיב Edge מבוזר אחד או יותר שנקרא Message Processor. אם מוגדרים כמה מעבדי הודעות להצגת בקשות 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>