有四种解决方案：超时处理，线程隔离，降级熔断，限流
前三种为补救措施，而第四种限流为预防措施
在SpringCloud当中支持多种服务保护技术：
早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里的Sentinel框架，这里我们做下对比：
由图可以看出Sentinel的功能广泛，本文就以流量控制，熔断降级为主要内容进行讲述。
通俗来讲就是限流的意思啦，那流量控制的原理是什么呢？
答：
流量控制可以在一定程度上保护服务免受过载和崩溃的影响，但并不能解决所有问题，
比如：当一个服务发生故障或异常时，尽管流量控制限制了对该服务的请求，但其他依赖该服务的服务仍然可能受到影响。故障的服务可能会导致其他服务无法正常工作，从而影响整个系统的稳定性。
所以熔断降级就登场啦。
熔断降级的主要过程：
sentinel的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。那么该如何实现持久化呢？
答：规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：
pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。
push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。
本文使用push模式，将sentinel与nacos结合，nacos写限流配置，同步到sentinel控制台。
那么有人可能会问，sentinel编辑限流配置，会同步到nacos吗？
答：SentinelDashboard默认不支持nacos的持久化，需要修改源码。改写源码有可能会出现一些bug，所以在这里就不多展示了，有兴趣可以去了解一下。这里讲nacos写限流配置，同步到sentinel控制台。
看这个图可以看见Sentinel的网关流控支持对SpringCloudGateway、Zuul等主流的APIGataway进行限流。
本案例用的是springGateway。
流控分为网关流控和普通流控。
所谓网关流控就是应用于网关服务的。而普通流控应用于任何一个服务。
区别：
既然有网关流控了，那还要普通流控干什么？
答：首先网关服务关联的其它服务都可以通过网关流控来进行限流，但是，其它服务之间可能也有相互调用的情况出现，那么它们之间的调用不走网关服务，那么网关流控就没办法咯，这时候就需要普通流控了。
gw-flow为网关流控，flow为普通流控。
网关流控跟普通流控面板是不一样的，下面左图为网关流控面板，右图为普通流控面板。
Sentinel默认流控面板是普通流控面板，那如何开启网关流控面板呢？
答：只需在网关服务添加JVM启动参数
具体用哪个按需求来选择。
具体其它规则查看：
假设系统服务的获取用户分页列表只能承受的QPS为5
设置线程数为10，模拟一秒发起十次请求。
可以看见49分16秒QPS应该是6，拒绝了5，实现限流了。
这个错误信息是自定义的，接下来我们来看看如何自定义异常。
{"code":429,"message":"BlockedbySentinel:ParamFlowException"}总有
先看一张图
Feign客户端远程调用目标服务失败后，就会走降级逻辑。Feign本身能够实现降级功能，因为内部集成了Hystrix
#2.feign配置feign:#微服务保护组件熔断器hystrix:enabled:true开启后便能有降级功能，hystrix也有熔断不过要做其它步骤，通过前面对比hystrix和Sentinel，果断选择后者，所以下面讲述通过Sentinel集合Fegin实现熔断降级。
只给出重要部分，其它跟流控配置差不多
对比一下这个图就明白了，最小请求数和统计时长的值都是用的默认的。
具体规则看这里
为了展示效果，主动弄了个异常。因为设置的异常数阈值为1个，所以不需要Jmeter来测试，凭借我个人的手速来实现测试┗|｀O′|┛嗷~~
通过上图可以看见11秒的时候通过了1个请求，其它4秒都是0通过，因为熔断时长为5s，可以看控制台的信息
很明显看到，当发生一个异常后，5s内的请求都走了降级处理。这就是熔断降级功能。
关于只是Sentinel实现的熔断降级：只需使用@SentinelResource注解方可实现，这里就不展示啦。
QueriesPerSecond,每秒查询数，也叫每秒请求数，即是每秒能够响应的请求次数，注意这里的查询是指用户发出请求到服务器做出响应成功的次数,简单理解可以认为查询=请求request。
TransactionsPerSecond，每秒处理的事务数，指系统在每秒钟内能够成功处理的事务数量。