Yes, precisely. The API Gateway itself is clustered. It services a large volume of inbound traffic which it reverse-proxies to appropriate back-end APIs after applying policies such as security, rate limiting, caching, etc.
-Eric On 3/18/2016 2:32 AM, Bela Ban wrote: > Stupid question: whay do you need a distributed counter for this? Is the > service you're monitoring replicated in a cluster? > > On 17/03/16 18:06, Eric Wittmann wrote: >> Greetings. Apologies for coming in a bit late on this conversation. >> Tristan pointed me to it a couple of days ago and unfortunately I'm just >> now getting time to reply. >> >> I can try to quickly give an overview of apiman's (JBoss API Management >> Gateway) requirements. >> >> What we're trying to do is implement support for Limiting policies: >> >> * Rate Limiting/Throttling (e.g. limit of 100 requests per second) >> * Quotas (e.g. limit of 100,000,000 requests per month) >> * Transfer Quotas (e.g. limit of 2.5GB of data downloaded per day) >> >> We will need to support multiple backing implementations of the Rate >> Limiter, and we're trying to get Infinispan to be one of those >> implementations. >> >> In no particular order, we would need the following characteristics: >> >> - Can be "squishy" for quotas and transfer quotas: If you >> get 100,001,017 requests that's OK >> - Strict would be cool as an option: Hard-fail when the >> counter reaches the limit - no chance it will go over. >> - Lots of individual counters: users may publish 100s of >> APIs to the Gateway, and each API may be consumed by >> 100s or 1000s of users/client. Depending on configuration >> of the policy, *each* user/client has a separate limit. >> - Counters need to be created dynamically: users can >> add APIs via the Management UI, configure them to add >> policies (e.g. a Quota policy) and then publish them to >> a running Gateway, at which point end users can invoke >> the API through the Gateway, which will use a counter >> to enforce the Quota. >> - Counter values reset at the end of a time boundary: for >> example, at the end of the month the counter value for >> the example quota above would reset to 0. >> - Don't care (right now) what the counter value is: at the >> moment we simply need to know if some counter max value >> has been reached. In the future we would like to know >> when a max value is being "approached" (e.g. to notify a >> user) >> - Should be persistent: it would not be ideal for e.g. per- >> month quota values to be lost on server restart. >> >> That's all the high level requirements I can think of off the top of my >> head, and after reading all of the current messages in this thread. :) >> >> -Eric >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
