As the name implies, these policies are applied at subscription level.Subscription level policies and burst control.For example, having per token quota tier of 10 req/s means that each end user of the particular application can invoke any API that’s subscribed to the application at only 10 req/m. The limit of a policy specifies the maximum number of request or bandwidth that the end user can access when considering all subscribed APIs of a single application. The user can specify per token quota policy when he/she is creating or editing an application from the store. These policies are applicable at application level.Those policies can be categorized as follow: There are several policy types that are applicable for the above levels. If a user deployed a global level throttle policy then it will be applied to any API available in the system. Global level: Policies applicable at this level will be applied to all APIs of a gateway.a user may grant 20 req/s for GET method of an API and 1 req/s for DELETE resource of an API. Users may apply policies at this level to give different throttle limits to resources, e.g. Resource level: Throttle policies defined at this level are applied based on the resources available in a particular API and its metadata.The purpose of having policies at this level is to limit the total number of requests coming to an API from any number of users from any number of applications. API level: Throttle policies defined at this level are applied based on the metadata of the API that belongs to a particular API request.These policies will limit the total number of requests that can go through from an application to a single API. Subscription level: Throttle policies defined at this level are applied based on the subscription details of an API and the application details of the application that are going to subscribe an API.The purpose of having policies at this level is to control API access by considering the end user of an application. These policies will limit API access considering the subscribed application details of an API. Application level: Throttle policies defined at this level are applied based on the application details of an API that made the subscription.Following are throttling policy applicability levels: Users may apply one or more throttling policies at different levels based on their requirement. Applicability of throttle policies depends on the data of an incoming API request and the metadata of the API that belongs to the incoming request. Each level has its own set of throttle policies. WSO2 API Manager has several types of throttling levels. Different types of throttling policies and level of applicability
Throttling decisions are made by Siddhi runtime and throttling decisions are published to the JMS topic each and every API gateway subscribed to this JMS topic throttling decisions get instantly notified to the API gateways. This implementation adds one change to a typical API manager deployment where it’s required to have an additional instance to process data of every API request and take throttling decisions based on the applicability of available throttle policies. With the new throttling implementation, we were able to overcome many of the limitations that existed in the old throttle implementation. Siddhi is a very powerful real-time event processing engine. Since it’s required to build a more complex and extensible throttling mechanism, we have decided to move forward with a Siddhi runtime-based throttling engine. The most recent implementation of the legacy throttling implementation is based on Hazelcast atomic counters that sync the local counters of each gateway to sum-up clusterwide global count. Previous versions of WSO2 API Manager used legacy throttling implementation that was subject to several drastic changes and restructure in the past few years.
0 kommentar(er)
