Hotspot-Regeln
Hotspots sind Daten, auf die häufig zugegriffen wird. In vielen Fällen möchten wir die Top-K-Daten mit der höchsten Zugriffshäufigkeit in bestimmten Hotspot-Daten zählen und deren Zugriff einschränken. zum Beispiel:
Waren-ID ist ein Parameter, der die am häufigsten gekauften Waren-IDs in einem Zeitraum zählt und einschränkt. Benutzer-ID ist ein
Parameter
, der die Benutzer-IDs einschränkt, auf die in einem Zeitraum am häufigsten zugegriffen wird.
Die Hotspot-Parameter-Strombegrenzung kann als eine besondere Art der Flusskontrolle angesehen werden, die nur für Ressourcenaufrufe wirksam wird, die Hotspot-Parameter enthalten.
Sentinel verwendet die LRU-Strategie, um die Hotspot-Parameter zu zählen, auf die zuletzt zugegriffen wurde, und kombiniert den Token-Bucket-Algorithmus, um eine Flusssteuerung auf Parameterebene durchzuführen.
Derzeit verfügt der mit Sentinel gelieferte Adapter nur über Hotspot-Parameter für die Dubbo-Methode. Andere Adaptermodule (z. B. Web) unterstützen standardmäßig keine Hotspot-Regeln. Sie können einen neuen Ressourcennamen angeben und die gewünschten Parameter übergeben, indem Sie die Einbettung anpassen Methode.
Beachten Sie, dass der Ressourcenname des benutzerdefinierten eingebetteten Punkts nicht mit dem vom Anpassungsmodul generierten Ressourcennamen identisch sein sollte, da dies sonst zu wiederholten Statistiken führt.
Die Strombegrenzung des Hotspot-Parameters wird durch die Annotation @SentinelResource wirksam.
Systemregeln
Die Systemschutzregeln werden über den eingehenden Datenverkehr auf Anwendungsebene gesteuert, und die Anwendungsdaten werden anhand der vier Dimensionen Gesamtlast, RT, Eingangs-QPS und Anzahl der Threads eines einzelnen Computers überwacht, damit das System ausgeführt werden kann den maximalen Durchsatz so hoch wie möglich zu halten und gleichzeitig die Integrität des Gesamtsystems zu gewährleisten.
Systemschutzregeln gelten für die Gesamtdimension, nicht für die Ressourcendimension, und wirken sich nur auf eingehenden Datenverkehr aus. Eingehender Datenverkehr bezieht sich auf den Datenverkehr, der in die Anwendung eintritt (EntryType.IN), z. B. Anfragen, die von Webdiensten oder Dubbo-Servern empfangen werden, die alle eingehender Datenverkehr sind.
Systemregeln unterstützen die folgenden Schwellenwerttypen:
-
Last (nur gültig für Linux/Unix-ähnliche Maschinen): Der Systemschutz wird ausgelöst, wenn die Systemlast1 den Schwellenwert überschreitet und die aktuelle Anzahl gleichzeitiger Threads im System die Systemkapazität übersteigt. Die Systemkapazität wird aus maxQps * minRt des Systems berechnet. Der Einstellungsreferenzwert ist im Allgemeinen CPU-Kerne * 2,5. -
CPU-Auslastung (Version 1.5.0+): Wenn die System-CPU-Auslastung den Schwellenwert überschreitet, wird der Systemschutz ausgelöst (Wertebereich 0,0-1,0). -
RT: Der Systemschutz wird ausgelöst, wenn die durchschnittliche RT des gesamten eingehenden Datenverkehrs auf einem einzelnen Computer den Schwellenwert in Millisekunden erreicht. -
Anzahl der Threads: Wenn die Anzahl der gleichzeitigen Threads des gesamten eingehenden Datenverkehrs auf einem einzelnen Computer den Schwellenwert erreicht, wird der Systemschutz ausgelöst. Ingress QPS: Wenn die QPS des gesamten eingehenden Datenverkehrs auf einem einzelnen Computer den Schwellenwert erreicht, wird der Systemschutz ausgelöst.
Autorisierungsregeln
Die schwarze und weiße Liste schränkt ein, ob die Ressource gemäß der Anforderungsquelle der Ressource weitergeleitet wird. Wenn die weiße Liste konfiguriert ist, kann nur die Anforderungsquelle in der weißen Liste passieren, wenn die schwarze Liste konfiguriert ist, die Anforderungsquelle in der schwarzen Liste werden nicht bestanden, und der Rest der Anfragen wird bestanden.
Aufruferinformationen werden über den Ursprungsparameter in der ContextUtil.enter(resourceName, origin)-Methode übergeben.
Die Black- und Whitelist-Regeln (AuthorityRule) sind sehr einfach und umfassen hauptsächlich die folgenden Konfigurationselemente:
-
Ressource: Ressourcenname, dh das Objekt der aktuellen Begrenzungsregel -
limitApp: die entsprechende Blacklist/Whitelist, getrennt durch , für verschiedene Ursprünge, z. B. appA, appB -
Strategie: Einschränkungsmodus, AUTHORITY_WHITE ist Whitelist-Modus, AUTHORITY_BLACK ist Blacklist-Modus, der Standard ist Whitelist-Modus. 
Für den eingehenden Ursprung können Sie die Ursprungserfassungsmethode umschreiben, indem Sie die API-Schnittstelle umschreiben, und es können sowohl Anforderungsparameter als auch Anforderungsheader verwendet werden.
Relevanter Code:
Implementierungsklasse
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) {
// 请求头的key，根据key值获取value值，此value值会赋予origin，完成流控规则校验
return httpServletRequest.getParameter("service-name");
}
}
Konfigurationsklasse
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;
}
}
Schließlich können Sie jedes Mal, wenn Sie eine Anfrage senden, den entsprechenden Schlüssel und den entsprechenden Wert in die Anfrageparameter oder den Anfrageheader bringen~