מדיניות של SpikeArst

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

המדיניות Spike Arrest (מניעת עליות פתאומיות בתנועה) מגנה מפני עליות פתאומיות בתנועה באמצעות הרכיב <Rate>. האלמנט הזה מגביל את מספר הבקשות שמעובדות על ידי שרת proxy של API ונשלחות אל ה-backend, וכך מגן מפני עיכובים בביצועים והשבתה.

רכיב <SpikeArrest>

הגדרה של מדיניות Spike Arrest.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <DisplayName>display_name</DisplayName>
  <Properties/>
  <Identifier ref="flow_variable"/>
  <MessageWeight ref="flow_variable"/>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
  <DisplayName>Spike Arrest-1</DisplayName>
  <Properties/>
  <Identifier ref="request.header.some-header-name"/>
  <MessageWeight ref="request.header.weight"/>
  <Rate>30ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

This element has the following attributes that are common to all policies:

דוגמאות

בדוגמאות הבאות אפשר לראות כמה מהדרכים שבהן אפשר להשתמש במדיניות Spike Arrest:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate ref="request.header.runtime_rate" />
</SpikeArrest>

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

הפניה לרכיב צאצא

בקטע הזה מתוארים רכיבי הבן של <SpikeArrest>.

<DisplayName>

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

הרכיב <DisplayName> משותף לכל סוגי המדיניות.

התחביר של רכיב <DisplayName> הוא:

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

לרכיב <DisplayName> אין מאפיינים או רכיבי צאצא.

<Identifier>

מאפשרת לבחור איך לקבץ את הבקשות כדי שאפשר יהיה להחיל את המדיניות של Spike Arrest על סמך הלקוח. לדוגמה, אפשר לקבץ בקשות לפי מזהה מפתח. במקרה כזה, הבקשות של כל מפתח ייספרו במסגרת שיעור מניעת העלייה הפתאומית של המפתח עצמו, ולא כל הבקשות לשרת ה-proxy.

אפשר להשתמש בו בשילוב עם הרכיב <MessageWeight> כדי לקבל שליטה מדויקת יותר על הגבלת קצב הבקשות.

אם משאירים את הרכיב <Identifier> ריק, מגבלת קצב אחת נאכפת על כל הבקשות ל-API proxy הזה.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Identifier ref="flow_variable"/>
</SpikeArrest>
        

<SpikeArrest name="Spike-Arrest-1">
  <Identifier ref="developer.id"/>
  <Rate>42pm</Rate/>
</SpikeArrest>

בטבלה הבאה מתוארים המאפיינים של <Identifier>:

הנושא הזה מוסבר גם בפוסט הבא בקהילת Apigee: Quota Identifier Across Different Policies.

<MessageWeight>

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

אפשר להשתמש בו בשילוב עם <Identifier> כדי לווסת עוד יותר את הבקשות לפי לקוחות או אפליקציות ספציפיים.

לדוגמה, אם הערך של Spike Arrest <Rate> הוא 10pm, ואפליקציה שולחת בקשות עם משקל של 2, אז מותר לשלוח מהלקוח הזה רק חמש הודעות בדקה, כי כל בקשה נחשבת כ-2.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <MessageWeight ref="flow_variable"/>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

בטבלה הבאה מתוארים המאפיינים של <MessageWeight>:

<Rate>

מציין את הקצב שבו מגבילים עליות חדות בתעבורת נתונים (או פרצי תעבורה) על ידי הגדרת מספר הבקשות שמותרות במרווחי זמן של דקה או שנייה. אפשר גם להשתמש ברכיב הזה בשילוב עם <Identifier> ועם <MessageWeight> כדי להגביל את התנועה בצורה חלקה בזמן הריצה על ידי קבלת ערכים מהלקוח.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

בטבלה הבאה מתוארים המאפיינים של <Rate>:

<Rate ref="request.header.custom_rate">1pm</Rate>

<UseEffectiveCount>

מפיץ את הספירות של Spike Arrest בין מעבדי ההודעות (MP) כשמשתמשים בקבוצות של שינוי גודל אוטומטי.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest name='Spike-Arrest-1'>
  <Rate>40ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

הרכיב <UseEffectiveCount> הוא אופציונלי. ערך ברירת המחדל הוא false אם לא מציינים את הרכיב במדיניות Spike Arrest.

בטבלה הבאה מתוארים המאפיינים של רכיב <UseEffectiveCount>:

ההשפעה של <UseEffectiveCount> תלויה בערך שלו:

• ‫true: מגבלת שיעור העלייה של MP היא <Rate> חלקי המספר הנוכחי של MP באותו פוד. המגבלה המצטברת היא הערך של <Rate>. כשחברי פרלמנט מתווספים (או מוסרים) באופן דינמי, מגבלות הקצב של העלייה החדה שלהם גדלות (או קטנות), אבל המגבלה הכוללת נשארת זהה.
• ‫false (ברירת מחדל אם לא צוין): מגבלת קצב העלייה של כל MP היא פשוט הערך של <Rate>. המגבלה הכוללת היא סכום השיעורים של כל המודעות המותאמות. כשמוסיפים (או מסירים) חברי פרלמנט, מגבלות הקצב של העלייה החדה של כל אחד מהם יישארו זהות, אבל המגבלה הכוללת תגדל (או תקטן).

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

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

• שיעורים לדקה מוחלקים לבקשות מלאות שמותרות במרווחי זמן של שניות.
  

  לדוגמה, אם מגדירים 30pm, המערכת תבצע החלקה באופן הבא:
  60 שניות (דקה אחת) חלקי 30pm = מרווחי זמן של 2 שניות, או בקשה אחת מותרת כל 2 שניות. בקשה שנייה בתוך 2 שניות תיכשל. בנוסף, בקשה 31 בתוך דקה תיכשל.

• השיעורים לשנייה מוחלקים לבקשות מלאות שמותרות במרווחים של אלפיות השנייה.

  לדוגמה, אם המגבלה היא 10ps, המערכת תבצע החלקה באופן הבא:
  ‫1,000 מילישניות (שנייה אחת) חלקי 10ps = מרווחים של 100 מילישניות, או בקשה אחת מותרת כל 100 מילישניות. בקשה שנייה שנשלחת תוך 100 אלפיות השנייה תיכשל. בנוסף, בקשה 11 בתוך שנייה תיכשל.

בטבלה הבאה מוצגת ההשפעה של <UseEffectiveCount> על המגבלה של הגבלת הקצב של יצירת הבקשות של כל MP:

בדוגמה הזו, שימו לב שכאשר מספר המגה-פיקסלים יורד מ-4 ל-2, והערך של <UseEffectiveCount> הוא false, השיעור האפקטיבי לכל מגה-פיקסל נשאר זהה (10). אבל אם הערך של <UseEffectiveCount> הוא true, הריבית האפקטיבית לכל נקודה משתנה מ-10 ל-20 כשהמספר של הנקודות יורד מ-4 ל-2.

משתני תהליך

כשמדיניות Spike Arrest מופעלת, משתנה הזרימה הבא מאוכלס:

מידע נוסף זמין במאמר בנושא משתני זרימה.

הפניה לשגיאה

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

Example error response

Shown below is an example error response:

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.SpikeArrestViolation"
      },
      "faultstring":"Spike arrest violation. Allowed rate : 10ps"
   }
}

Example fault rule

Shown below is an example fault rule to handle a SpikeArrestViolation fault:

<FaultRules>
    <FaultRule name="Spike Arrest Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
        </Step>
        <Condition>ratelimit.Spike-Arrest-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

קוד הסטטוס הנוכחי של HTTP לחריגה ממגבלת קצב שהוגדרה על ידי מדיניות מכסה או מדיניות למניעת עליות פתאומיות הוא 429 (יותר מדי בקשות). כדי לשנות את קוד הסטטוס של HTTP ל-500 (שגיאה פנימית בשרת), צריך להגדיר את המאפיין features.isHTTPStatusTooManyRequestEnabled ל-false באמצעות ה-API‏ Update organization properties.

לדוגמה:

curl -u email:password -X POST -H "Content-type:application/xml" http://api.enterprise.apigee.com/v1/organizations/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
        . . .
    </Properties>
</Organization>"

סכימות

כל סוג מדיניות מוגדר על ידי סכימת XML ‏ (.xsd). סכימות מדיניות זמינות ב-GitHub.

נושאים קשורים

• מדיניות בנושא מכסות: מדיניות בנושא מכסות, להגבלת התנועה בלקוחות ספציפיים
• הגבלת קצב של יצירת בקשות – סקירה כללית
• השוואה בין מכסה לבין מדיניות של SpikeArrest
• דוגמאות עובדות של שרתי proxy ל-API