问题
When I add a spike arrest policy as pasted below, to my Apigee APIs, does it count all the API calls from that client IP to Apigee to calculate whether the limit was exceeded? Or does it maintain a count per API individually and apply the policy per API/ API bundle?
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest enabled="true" continueOnError="true" async="false" name="SpikeArrestCheck">
<DisplayName>Spike Arrest Policy</DisplayName>
<FaultRules/>
<Properties/>
<Identifier ref="proxy.client.ip"/>
<Rate>100ps</Rate>
</SpikeArrest>
回答1:
When I add a spike arrest policy as pasted below, to my Apigee APIs, does it count all the API calls from that client IP to Apigee to calculate whether the limit was exceeded? Or does it maintain a count per API individually and apply the policy per API/ API bundle?
Count is maintained per API bundle, per policy name (org and env is a given). Even if you use the same Identifier across bundles, there is no way to tie different API bundle spike arrests together.
I have tested this using SpikeArrest policy and observing the value of ratelimit.<spike arrest policy name>.used.count as tested across 2 different API bundles, both policies with the same name and same Identifier. The 2 buckets/counters are treated independently
回答2:
You can set a spike arrest identifier like this:
<SpikeArrest name="SpikeArrest">
<Rate>10ps</Rate>
<Identifier ref="someVariable" />
</SpikeArrest>
The scope of the spike arrest policy above is limited to the current organization, environment, bundle, and policy name. No traffic traveling through a different policy, bundle, environment, or organization will affect the spike arresting of the above policy. In addition, since an identifier is specified, only traffic that has the same value stored in "someVariable" will be "counted" together. If the policy had no identifier specified, all traffic for the same policy, bundle, environment and organization would be counted together.
Note that spike arrests are tracked separately per message processor. They are also currently implemented as rate limiting, not a count. If you specify 100 per second, it means that your requests can only come in one per 10 ms (1/100 sec). A second request within 10 ms on the same message processor will be rejected. A small number is generally not recommended. Even with a large number, if two requests come in nearly simultaneously to the same message processor, one will be rejected.
回答3:
Some observations for best practice:
Ideally you should track traffic access to your API based on a key that is static regardless the source. Using an IP address leaves room to consumer Apps to be too broad, so Spike Arrest policies never trigger because each mobile device will have a different IP address assigned to it. So, as a best practice either retrieve consumer key through OAuthV2 Policy after validating the token or directly when key is provided in the request. Exceptions to the rule is that API is not publicly accessible to consumer Apps, in which case access is provided to App servers only, which anyway you may want to manage traffic implementing Key Verification.
回答4:
The counter "bucket" is determined by how you use Identifier. If you don't specify Identifier, then the bucket is the entire API Proxy. Or you can use Identifier Ref to make a more granular bucket. For example, if you wanted to make the bucket be per-developer (assuming you previously did a VerifyApiKey or VerifyAccessToken), you would do this:
<Identifier ref="client_id" />.
And if you wanted to, you could set the bucket to be based on ip address by doing this:
<Identifier ref="client.ip"/>
So the way you did it, it would be per-client ip.
来源：https://stackoverflow.com/questions/21614059/apigee-spike-arrest-applies-to-each-api-bundle-or-all-api-bundles