Apigee节流方案

我们的组织正在向Apigee迁移

我们想要实现的是以下场景。你能告诉我怎么做吗？ 可能同时使用SpikeResponse、Quota和ConcurrentRatelimit

我想询问代理的实际配置示例，作为如何链接策略以实现预期结果的指南。

我已经阅读了这些文档，它有些粗略，在分发什么、不分发什么等方面存在差距

http://apigee.com/docs/api-services/content/shield-apis-using-spikearrest
http://apigee.com/docs/api-services/content/rate-limit-api-traffic-using-quota#identifying-apps
http://apigee.com/docs/api-services/content/throttle-backend-connections-using-concurrentratelimit

一个例子缺口是我之前关于SpikeArrest的问题，由于配置SpikeArrest而没有获得预期的行为，这引发了一个问题，因为在文档中没有指定SpikeArrest没有分发：

这些人也被同样的情况抓住了：

场景和预期结果：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ConcurrentRatelimit async="true" continueOnError="false" enabled="true" name="Concurrent-Rate-Limit-1">
    <DisplayName>Concurrent Rate Limit 1</DisplayName>
    <AllowConnections count="1" ttl="5"/>
    <Distributed>true</Distributed>
    <TargetIdentifier name="default"></TargetIdentifier>
</ConcurrentRatelimit>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="true" continueOnError="false" enabled="true" name="Spike-Arrest-2">
    <DisplayName>Spike Arrest 2</DisplayName>
    <FaultRules/>
    <Properties/>
    <Identifier ref="request.header.some-header-name"/>
    <MessageWeight ref="request.header.weight"/>
    <Rate>30ps</Rate>
</SpikeArrest>

在我们的组织中，我们有6个消息处理器（MP），我认为他们严格按照循环方式工作

我们有以下后端Api-Api-1

Api-1拥有来自我们组织内部的消费者以及Apigee消费者。 我们希望防止Api-1受到重击和坠落。 假设它已经过负载测试，每秒最多接受50个请求。 我们已经计算出，通过Apigee，我们希望限制每秒最多30个请求，因为其他20个请求/秒容量是为来自我们组织内部（主要是我们自己的其他产品）但未通过Apigee的用户提供的

从通过Apigee消费Api-1的DeveloperApps数量来看，我们已经确定了4个应用程序/客户端，它们的消费峰值最高。 在分配给Apigee的30ps费率中，我们希望能够为每个4个高消费Devapp/客户分配5ps，并让其他Devapp/客户共享剩余的10ps费率

我在TargetEndpoint一直遇到的主要问题就是这里描述的问题，因为SpikeRestart策略没有分布在MessageProcessors之间：

我们如何绕过它并实现所需场景？

以下是我曾尝试过的，并使其达到预期行为的示例：

代理的TargetEndpoint:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ConcurrentRatelimit async="true" continueOnError="false" enabled="true" name="Concurrent-Rate-Limit-1">
    <DisplayName>Concurrent Rate Limit 1</DisplayName>
    <AllowConnections count="1" ttl="5"/>
    <Distributed>true</Distributed>
    <TargetIdentifier name="default"></TargetIdentifier>
</ConcurrentRatelimit>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="true" continueOnError="false" enabled="true" name="Spike-Arrest-2">
    <DisplayName>Spike Arrest 2</DisplayName>
    <FaultRules/>
    <Properties/>
    <Identifier ref="request.header.some-header-name"/>
    <MessageWeight ref="request.header.weight"/>
    <Rate>30ps</Rate>
</SpikeArrest>

ConcurrentRatelimit:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ConcurrentRatelimit async="true" continueOnError="false" enabled="true" name="Concurrent-Rate-Limit-1">
    <DisplayName>Concurrent Rate Limit 1</DisplayName>
    <AllowConnections count="1" ttl="5"/>
    <Distributed>true</Distributed>
    <TargetIdentifier name="default"></TargetIdentifier>
</ConcurrentRatelimit>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="true" continueOnError="false" enabled="true" name="Spike-Arrest-2">
    <DisplayName>Spike Arrest 2</DisplayName>
    <FaultRules/>
    <Properties/>
    <Identifier ref="request.header.some-header-name"/>
    <MessageWeight ref="request.header.weight"/>
    <Rate>30ps</Rate>
</SpikeArrest>

同时利率限制1
真的

Spike逮捕：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ConcurrentRatelimit async="true" continueOnError="false" enabled="true" name="Concurrent-Rate-Limit-1">
    <DisplayName>Concurrent Rate Limit 1</DisplayName>
    <AllowConnections count="1" ttl="5"/>
    <Distributed>true</Distributed>
    <TargetIdentifier name="default"></TargetIdentifier>
</ConcurrentRatelimit>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="true" continueOnError="false" enabled="true" name="Spike-Arrest-2">
    <DisplayName>Spike Arrest 2</DisplayName>
    <FaultRules/>
    <Properties/>
    <Identifier ref="request.header.some-header-name"/>
    <MessageWeight ref="request.header.weight"/>
    <Rate>30ps</Rate>
</SpikeArrest>

扣杀2
30便士

还有，如果组织在我不知情的情况下增加或删除议员，会发生什么，这将完全扰乱节流

非常感谢

---

谢谢

跨MP同步尖峰停止的问题是，您已经处于严重负载下（理论上），并且在高负载下在MP之间产生额外的颤振可能会影响您用于保护免受高负载影响的工具

---

因此，在每秒限制中，您唯一的选择是进行数学运算并除以MP。在分钟及以上的时间内，您可以在没有标识符的情况下执行配额策略，并启用分布式和同步。

您是否尝试过将其除以已知消息处理器的数量？也就是说，如果你有，这是我目前的解决方案。目前，我将尖峰停止设置为5ps（30ps/6mp=5ps）。我正在寻找一个更好的解决方案，似乎出于任何原因，数字需要降到非常低的水平，据我所知，你不能将0.5便士这样的利率作为峰值逮捕率。我也实施了配额政策。ConcurrentRateLimit在上述场景中是否仍有帮助？它是如何工作的？它到底做什么？文档中写道：“ConcurrentRatelimit策略使您能够限制从Apigee Edge上运行的API代理到后端服务的入站连接。在分布式环境中，应用流量可能由许多复制的API代理管理。”此外，配额策略似乎分布在消息处理器之间，它似乎不会“在MP之间产生额外的聊天”，所以我不明白为什么不以相同的方式同步配额策略？如果出于任何原因，MPs的数量在我不知情的情况下发生变化，这将打乱节流，并使我正试图保护的API不受这种情况的影响。防止DOS攻击和节流是我的团队最关心的问题，如果这不起作用，那么Apigee对我们来说就毫无用处了。