[microservices sentinel] hotspot rules ｜ authorization rules ｜ cluster flow control ｜ machine list

Hot spot rules

Hot spots are frequently accessed data . Most of the time, we want to count the most frequently visited data in a hotspot Top K data , And restrict their access . such as ：

goods ID Is the parameter , Count the most frequently purchased items in a period of time ID And limit
user ID Is the parameter , For users who visit frequently over a period of time ID Limit
Hot spot parameter current limiting will count the hot spot parameters in the incoming parameters , And according to the configured current limiting threshold and mode , Restrict the flow of resource calls with hotspot parameters . Hot spot parameter current limiting can be regarded as a special flow control , Only valid for resource calls with hotspot parameters .

Sentinel utilize LRU Policy counts the most recently visited hotspot parameters , Combined with token bucket algorithm to carry out parameter level flow control .

at present Sentinel Self contained adapter only Dubbo The method embeds points with hot spot parameters , Other adaptation modules （ Such as Web） Hotspot rules are not supported by default , You can specify a new resource name and pass in the desired parameters by customizing the embedding point .

Note that the resource name of the user-defined embedding point should not duplicate the resource name generated by the adaptation module , Otherwise, it will cause repeated statistics .

adopt @SentinelResource The annotation makes the hotspot parameter current limiting effective .

System rules

The system protection rule is to control the inlet flow at the application level , From the whole of a single machine Load、RT、 entrance QPS And thread number four dimensions to monitor application data , Let the system run at the maximum throughput and ensure the overall stability of the system .

System protection rules apply the whole dimension , Not the resource dimension , And only effective for inlet flow . Inlet flow is the flow into the application （EntryType.IN）, such as Web Service or Dubbo The request received by the server , All belong to the inlet flow .

System rules support the following threshold types ：

• Load（ Only on Linux/Unix-like The machine works ）： When the system load1 Threshold exceeded , And the system will trigger system protection when the current number of concurrent threads exceeds the system capacity . The system capacity is determined by the maxQps * minRt calculated . The setting reference value is generally CPU cores * 2.5.
• CPU usage（1.5.0+ edition ）： When the system CPU When the utilization rate exceeds the threshold, system protection will be triggered （ Value range 0.0-1.0）.
• RT： When the average flow of all inlets on a single machine RT When the threshold value is reached, system protection is triggered , In milliseconds .
• Number of threads ： When the number of concurrent threads of all the entrances on a single machine reaches the threshold, system protection will be triggered .
  entrance QPS： When all the inlet flow on a single machine QPS When the threshold value is reached, system protection is triggered .

Authorization rules

The black and white list is based on the source of the resource request （origin） Restrict the passage of resources , If the whitelist is configured, it can only be passed if the request source is in the whitelist ; If the blacklist is configured, the request source will not pass when it is in the blacklist , The rest of the requests go through .

Caller information through ContextUtil.enter(resourceName, origin) Methods origin Parameters of the incoming .

Black and white list rules （AuthorityRule） It's simple , There are mainly the following configuration items ：

• resource： Resource name , That is, the object of the current limiting rule
• limitApp： The corresponding blacklist / White list , Different origin use , Separate , Such as appA,appB
• strategy： Limit mode ,AUTHORITY_WHITE For whitelist mode ,AUTHORITY_BLACK For blacklist mode , Default to white list mode .
  

origin The introduction of , By rewriting API Interface rewriting origin How to get , Both request parameters and request headers are allowed .

Related codes ：

Implementation class

import com.alibaba.csp.sentinel.adapter.servlet.callback.RequestOriginParser;

import javax.servlet.http.HttpServletRequest;

/** * @author issavior */
public class MyRequestOriginParser implements RequestOriginParser {
    

    @Override
    public String parseOrigin(HttpServletRequest httpServletRequest) {
    

        //  The request header key, according to key Values obtained value value , this value Values are assigned origin, Complete flow control rule verification 
        return httpServletRequest.getParameter("service-name");

    }
}

Configuration class

import com.alibaba.csp.sentinel.adapter.servlet.CommonFilter;
import com.alibaba.csp.sentinel.adapter.servlet.callback.WebCallbackManager;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.servlet.Filter;

/** * @author issavior */
@Configuration
public class SentinelConfig {
    

    @Bean
    public FilterRegistrationBean<Filter> webCallbackFilter() {
    

        FilterRegistrationBean<Filter> bean = new FilterRegistrationBean<>();
        bean.setFilter(new CommonFilter());
        bean.addUrlPatterns("/*");
        bean.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false");
        bean.setName("sentinelFilter");
        bean.setOrder(1);

        WebCallbackManager.setRequestOriginParser(new MyRequestOriginParser());
        return bean;
    }
}

Finally, every time you send a request , Take the corresponding... On the request parameter or request header key And the corresponding value That's all right. ～