sentinel简介随着微服务的普及，服务与服务之间的稳定性变得越来越重要。Sentinel是分布式服务架构的流量控制组件。主要以流量为切入点，从流量控制、断路器降级、系统自适应保护等多个维度帮助您保障微服务的稳定性。Sentinel的历史2012年，Sentinel诞生，主要功能是ingress流量控制。2013年到2017年，Sentinel在阿里巴巴集团内部快速发展，成为覆盖所有核心场景的基础技术模块。也因此，Sentinel积累了大量的流量整合场景和生产实践。2018年，Sentinel开源并继续发展。2019年，Sentinel继续探索多语言扩展方向，推出了C++原生版本。同时还针对ServiceMesh场景推出Envoy集群流控支持，解决ServiceMesh架构下多语言限流问题。2020年推出SentinelGo版本，继续向云原生方向演进。2021年，Sentinel向2.0云原生高可用决策中心组件演进；同时，推出原生版本的SentinelRust。Sentinel基本概念1.Resources资源是Sentinel的核心概念。它可以是Java应用程序中的任何东西，例如应用程序提供的服务，或者应用程序调用的另一个应用程序提供的服务，甚至是一段代码。在接下来的文档中，我们将使用资源来描述代码块。只要SentinelAPI定义的代码是资源，就可以被Sentinel保护。在大多数情况下，您可以使用方法签名、URL甚至服务名称作为资源名称来标识资源。2.规则围绕资源实时状态设置的规则可以包括流量控制规则、熔断降级规则和系统保护规则。所有规则都可以实时动态调整。流控有以下几个角度：资源调用关系，比如资源调用链接，资源与资源之间的关系；运行指标，如QPS、线程池、系统负载等；控制效果，如直接限流、冷启动、排队等。Sentinel的设计理念是让你自由选择控制角度，灵活组合，达到想要的效果。<你>1。流控规则首先我们来看一下流控规则。我们打开sentinel面板：启动我们的微服务（可以用上一章的分支代码）看到相关界面，我们设置一下，点击开启流量控制，可以看到QPS设置为1，刷新了不断地。可以看到如果限流的话也可以设置同样的并发线程数。如果演示的不是很好，我就不演示了。也可以达到限流的效果。点击高级选项可以看到直接、关联、链接等很多设置。流量控制效果包括：快速失败、预热和排队等候。直接（默认）：当接口达到限流条件时，启用限流。Association：当关联的资源达到限流条件时，启用限流（适合应用让步）。Link：当来自接口的资源满足限流条件时，开启限流。直接流控模式直接流控模式是最简单的模式，当指定接口达到限流条件时，开启限流。前面两种情况都是默认的直接流控。关联流控模式关联流控模式是指当与指定接口关联的接口达到限流条件时，使能指定接口限流。链接流控方式链接流控方式是指当前接口调用服务中的一个方法，另一个接口也调用服务中的一个方法。当接口达到QPS时，限流。这是什么意思？让我们在实践中做到这一点。首先我们在Servic中添加一个消息方法。并添加如下注解@SentinelResource("messsage")//名称可以自定义，然后在yml配置中添加收敛，然后在设置中添加流量控制，然后不断刷新/order/message就可以看到错误了。这是具体的链路流量控制规则。坑通知，如果不使用该系列版本，低版本配置可能不生效，先配置@ConfigurationpublicclassFilterContextConfigSentinel{/***@NOTE在spring-cloud-alibabav2.1.1.RELEASE及之前,sentinel1.7.0及之后的版本，关闭URLPATH聚合需要通过这种方式完成。spring-cloud-alibabav2.1.1.RELEASE后，可以通过配置关闭：spring.cloud.sentinel.web-context-unify=false*手动注入Sentinel过滤filter，关闭Sentinel注入CommonFilter实例，修改spring.cloud。配置文件中的sentinel.filter.enabled=false*Ingress资源聚合问题：https://github.com/alibaba/Sentinel/issues/1024或https://github.com/alibaba/Sentinel/issues/1213*入口资源聚合问题解决：https://github.com/alibaba/Sentinel/pull/1111*/@BeanpublicFilterRegistrationBeansentinelFilterRegistration(){FilterRegistrationBeanregistration=newFilterRegistrationBean();registration.setFilter(newCommonFilter());registration.addUrlPatterns("/*");//入口资源关闭聚合registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY,"false");注册.setName("sentinelFilter");registration.setOrder(1);returnregistration;}}然后配置yml配置，这样全部显示配置流控效果Fastfailure（默认）：直接Fail，抛出异常，什么都不做additionalProcessing是最简单的effectWarmUp：从开始阈值到最大QPS阈值会有一个缓冲阶段，初始阈值为最大QPS阈值的1/3，然后慢慢增加，直到最大阈值，合适对于突然增加的流量，转化为缓慢增长的场景排队：让请求匀速通过，单机阈值是每秒通过的次数，其余都排队；还可以设置超时时间period，当请求超过超时时间还没有处理完，就会被丢弃，前面的例子都是给当前请求服务添加流控规则，在流控模式下关联可以让其他请求服务到达阈值，并且此服务执行流量控制。<你>2。熔断降级什么是熔断降级？除了流量控制，减少调用链路中的不稳定资源也是Sentinel的使命之一。由于调用关系的复杂性，如果一个调用链路资源不稳定，最终会导致请求堆积。这个问题和Hystrix中描述的问题是一样的。Sentinel和Hystrix的原理是一样的：当调用环节某个资源不稳定，比如性能Timeout，异常比例增加时，限制对该资源的调用，让请求快速失败，避免影响其他资源，最终产生雪崩效应。熔断降级的设计理念是在限制的手段上，Sentinel和Hystrix采取的是完全不同的做法。Hystrix通过线程池隔离依赖（对应我们概念中的资源）。这样做的好处是资源之间是最彻底的隔离。缺点除了增加线程切换的成本外，还需要为每个资源预先分配线程池的大小。Sentinel针对这个问题采用了两种方法：限制并发线程数和隔离资源池的方法不同。并发线程数，减少不稳定资源对其他资源的影响。这样就没有线程切换的损失，也不需要预先分配线程池的大小。当资源不稳定时，比如响应时间变长，对资源的直接影响就是线程数会逐渐积累。在特定资源上的线程数量累积到一定数量后，将拒绝对该资源的新请求。累积的线程在完成任务后继续接收请求。通过响应时间降级资源除了控制并发线程数，Sentinel还可以通过响应时间快速降级不稳定的资源。当依赖资源的响应时间过长时，将直接拒绝对该资源的所有访问，并在指定的时间窗口过后才恢复。系统负载保护Sentinel还提供了系统维度的自适应保护能力。防止雪崩是系统保护的重要组成部分。当系统负载较高时，如果请求不断进入，可能会导致系统崩溃，无法响应。在集群环境下，网络负载均衡会将本应由本机承载的流量转发给其他机器。如果此时其他机器也处于边缘状态，增加的流量会导致这台机器崩溃，最终导致整个集群不可用。针对这种情况，Sentinel提供了相应的保护机制，在系统的入口流量和系统的负载之间取得平衡，保证系统在能力范围内处理最多的请求。让我们开始测试吧。首先我们在界面上设置RT为1，时间为5s进行疯狂刷新，然后可以看到限流，然后等待5s正常访问。异常比例和异常数量都是根据当前抛出的异常数量来限制的，这里就不演示了。<你>3。热点规则热点规则其实就是对参数层面进行控制。让我们开始我们的测试，让我们创建一个带参数的新测试。（这里有一个彩蛋，有一个小错误，更正到sentinel中查看相关资源，请注意~）进行访问测试，多次刷新sentinel中的热点规则配置，查看当前限制。同样，我们疯狂刷新age端也没有限流。单击高级选项。我们可以限制特定参数的电流。这意味着限流只会在151000QPS之后被限制。比如143QPS会限流然后刷新不同年龄的测试。就是这样。<你>4。授权规则其实就是限制不同来源调用微服务的链接的流量。点击授权就是黑白名单选择。白名单：授权后才能访问。黑名单：黑名单中的不能访问。流量控制应用程序是我们的微服务调用。下面开始实战：首先，我们开始创建这样一个类RequestOriginParserDefinition，实现RequestOriginParser接口，并集成相关类StringserviceName=httpParmeRequest(".getParmeRequest"serviceName");if(StringUtils.isEmpty(serviceName)){thrownewRuntimeException("服务为空");}returnserviceName;}}然后将pc访问接口加入白名单携带pc，没有问题，如果携带其他参数会提示问题，这是授权规则。4.系统规则系统保护规则从应用级入口流量控制，从单机整体Load、RT、ingressQPS、CPU使用率、线程数五个维度监控应用数据，在保证系统整体稳定性的同时，尽可能让系统运行在最大吞吐量。系统保护规则是在应用层面控制入口流量，从单机整体Load、RT、入口QPS、CPU使用率、线程数五个维度对应用数据进行监控，使系统运行在尽可能的最大吞吐量。保证系统的整体稳定性。系统保护规则是基于应用整体维度，而非资源维度，只对ingresstraffic（进入应用的流量）生效。·Load（只对Linux/Unix-like机器有效）：当系统load1超过阈值，系统当前并发线程数超过系统容量时，会触发系统保护。系统容量根据系统的maxQpsminRt计算得出。设置参考值一般是CPUcores2.5。·RT：当单机所有流星入口的平均RT达到阈值时，触发系统保护，单位为毫秒。线程数：当单机所有入口流量的并发线程数达到阈值时，触发系统保护。IngressQPS：当单机所有Ingress流量的QPS达到阈值时，触发系统保护。.CPU占用率：当单机所有入口流量的CPU占用率达到阈值时，触发系统保护。<你>4。自定义异常返回之前我们看到的异常返回是通过自己的系统返回的，现在怎么自定义呢？那我们开始吧。首先新建一个继承UrlBlockHandler的异常处理类，然后设置流控QPS的值。然后我们疯狂刷新就可以看到自定义的异常页面了。设置保险丝，同上操作。然后就是@SentinelResource设置流控的相关介绍BlockException和Throwable都是抛出的异常，后者范围更大，如果去掉BlockException，只会进入Throwable！image.png为什么要区分两者呢？其实就是区分是哨兵异常还是系统代码异常。最后是持久化，默认保存在内存中，微服务重启，哨兵规则不存在了，所以需要持久化。对nacos的持久化和持久化可以参考https://blog.csdn.net/weixin_...至此，我们这一章的哨兵实战就完成了，后面会继续添加到这个项目中。喜欢就点start吧~项目源码参考分支220212_xgc_useSentinelGitee:https://gitee.com/coderxgc/sp...GitHub:https://github.com/coderxgc/s...
