Shulou(Shulou.com)06/02 Report--

Sentinel is a flow control component open source by Alibaba and oriented to distributed service architecture. It mainly takes traffic as a starting point to help developers ensure the stability of micro-services from many dimensions, such as current limit, traffic shaping, circuit breaker degradation, system adaptive protection and so on. Sentinel inherits the core scenarios of Alibaba's Singles Day traffic promotion over the past 10 years, such as second kill, cold start, message peak cutting and valley filling, cluster flow control, real-time circuit breaker downstream unavailable services, etc., is a sharp weapon to ensure the high availability of micro services, natively supports multiple languages such as Java/Go/C++, and provides Istio/Envoy/SOFA MOSN global flow control support to provide high availability protection for Service Mesh.

Recently, Sentinel Go 0.4.0 was officially released, bringing hot parameter flow control characteristics, which can automatically identify the "hot spot" parameter values in the statistical input parameters and carry out flow control respectively, which is very useful for scenarios such as brush protection and hot commodity access frequency control, and is an important part of high availability traffic protection. Let's take a look at the scenarios and principles of hot parameter flow control.

Introduction to Hot spot Traffic Protection

Traffic is random and unpredictable. In order to avoid being overwhelmed by heavy traffic, we usually configure current-limiting rules on core interfaces, but it is not enough to configure common traffic control rules in some scenarios. Let's take a look at such a scene-when there is a big boost to the peak, there will always be a lot of "hot" goods, and the instantaneous traffic of these hot goods is very high. In general, we can predict a wave of hot items in advance and cache "warm-up" the product information so that we can quickly return to the DB when there are a large number of visits. But every promotion will emerge some "dark horse" goods, these "dark horse" goods are we can not predict in advance, has not been preheated. When there is a surge in visits to these "dark horses" goods, a large number of requests will break through the cache and go directly to the DB layer, resulting in slow DB access, crowding out the resource pool of normal commodity requests, and may eventually cause the system to hang up. At this time, using the hot parameter flow control ability of Sentinel, we can automatically identify hot spot parameters and control the access QPS or concurrency of each hot point value, which can effectively prevent overheated parameter access from crowding out normal calling resources.

For example, in some scenarios where we want to limit the frequency of each user calling a certain API, it is obviously not appropriate to use the API name + userId as the buried resource name. At this time, we can use WithArgs (xxx) to pass userId as a parameter to the API embedding point, and then configure hotspot rules to limit the call frequency for each user. At the same time, Sentinel also supports configuring current limit values for specific values for fine traffic control.

Example of hotspot parameters / rules:

/ / buried example e, b: = sentinel.Entry ("my-api", sentinel.WithArgs (rand.Uint32 ()% 3000, "sentinel", uuid.New (). String ()) / / Rule example _, err = hotspot.LoadRules ([] * hotspot.Rule {{Resource: "my-api", MetricType: hotspot.QPS, / / request quantity mode ControlBehavior: hotspot.Reject ParamIndex: 0, / / Parameter index 0 is the first parameter Threshold: 50, / / the threshold value for each hot spot parameter BurstCount: 0, DurationInSec: 1, / / the statistical window duration. Here it is 1s SpecificItems: map [hotspot. SpecificValue] int64 {/ / support configuring current limit value separately for a specific value. For example, here we limit the number of requests for the value 9 = 0 (not allowed) {ValKind: hotspot.KindInt, ValStr: "9"}: 0,})

Like other rules, hot spot flow control rules also support dynamic configuration through dynamic data sources.

The RPC framework integration modules provided by Sentinel Go (such as Dubbo and gRPC) automatically attach the parameter list called by RPC to the buried point, and users can configure hot spot flow control rules directly according to the corresponding parameter location. Currently, hotspot rules only support basic types and string types, which will be further improved by the subsequent community to support more types.

The hot spot flow control of Sentinel Go is based on cache elimination mechanism and token bucket mechanism. Sentinel identifies hotspot parameters through elimination mechanisms (such as LRU, LFU, ARC strategy, etc.), and controls the number of visits to each hotspot parameter through token bucket mechanism. At present, version 0.4.0 uses LRU policy to count hot spot parameters, and in subsequent versions, the community will introduce more cache elimination mechanisms to adapt to different scenarios.

Best practices for High availability Traffic Protection

In the Service Provider scenario, we need to protect the provider from being overwhelmed by traffic peaks. We usually control traffic according to the service capabilities of the service provider, or impose restrictions on specific service callers. In order to protect the service provider from being dragged down by the surge in traffic, we can combine the previous capacity assessment and configure the flow control rules of QPS mode through Sentinel. When the number of requests per second exceeds the set threshold, redundant requests will be automatically rejected. At the same time, it can be combined with hot spot parameter flow control for fine-grained traffic protection.

In the Service Consumer scenario, we need to protect the service caller from being dragged down by unstable dependent services. With the help of Sentinel's semaphore isolation policy (concurrency flow control rule), the concurrency of a service call is limited to prevent a large number of slow calls from crowding out normal requested resources; at the same time, with the rule of circuit breaker degradation, automatic circuit breaker will be called when the exception ratio or business slow invocation ratio exceeds a certain threshold, and the recovery will be attempted after a certain period of time. We can provide default processing logic (fallback) during the circuit breaker, and calls during the circuit breaker will return the result of fallback instead of trying an already unstable service. It is important to note that even if the service caller introduces the circuit breaker degradation mechanism, we still need to configure the request timeout on the HTTP or RPC client to protect it.

In some scenarios that request spikes, such as when the MQ client consumes messages, we may not want to reject (reinvest) redundant messages directly, but queue up these excessive messages to be processed step by step. This is the scene of "cutting peaks and filling valleys". We can use the "uniform speed + queue waiting" control effect in Sentinel flow control rules to deal with this scenario, allowing requests to pass at fixed intervals, and queuing for requests that exceed the preset amount. This method is suitable for requests to come in a spike, when we do not want to pass all the requests at once, which may crush the system; at the same time, we also expect the system to process these requests step by step at a steady speed to achieve the effect of "cutting peaks and filling valleys" instead of directly rejecting all redundant requests.

At the same time, Sentinel Go also provides the adaptive protection capability of the system in the global dimension. Combined with the monitoring indicators of several dimensions, such as the Load and CPU utilization of the system, and the entry QPS, response time and concurrency of the service, through adaptive flow control strategy, the ingress traffic of the system and the load of the system can reach a balance, allowing the system to run as far as possible in the maximum throughput while ensuring the overall stability of the system. System rules can be used as a protection strategy for the whole service to ensure that the service does not hang up.

Let's start hacking!

The Sentinel Go version is evolving rapidly, and we welcome interested developers to contribute to lead the evolution of future versions. The evolution of the Sentinel Go version cannot be achieved without the contribution of the community. If you are willing to participate in the contribution, you are welcome to contact us to join the Sentinel contribution Group to grow (Sentinel open source discussion nail group: 30150716). We regularly send small gifts to active contributors, and core contributors can be nominated as committer to lead the evolution of the community. At the same time, you are welcome to quickly experience the power of Sentinel through the AHAS Sentinel console. Now let's start hacking!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.