序言
在微服务时代中，有一个凤凰架构的概念。凤凰特点是可重生，那么对于微服务而言，各部分服务就相当于凤凰身上的部位，我们在开发过程中针对于某部分服务不满意需要进行升级的时候必须保证升级前后整体服务的正常运转。也就是我们将凤凰从毛翅膀变为为钢铁翅膀，凤凰还是活的并且飞行功能一样。这就类似社交网络电源中扎克伯格升级服务器时没通知爱得华多，在爱德华多冻结账户之后扎克伯格生气的保证Facebook永不宕机一样——这就引入了熔断限流的概念
一、服务控制相关概念
1.1）服务雪崩
左图比如服务C假死，进程还在就是卡住没反应导致上游都卡死；右图比如Service D负载压到80%反应慢导致多条链路上服务都卡死
1.2）服务限流
1.3）服务熔断
保险丝，在Open状态自旋定时到HalfOpen检测是否正常
1.4）服务降级
1.5）熔断降级的几种常见方案
二、常见的四种限流算法
2.1）计数器算法
第二张图假设（0~2秒）（4~6秒）没有请求，那么2秒进入300个请求也能满足指定周期内不触发熔断器，所以计数器算法的指定周期无法解决临界问题。优点是实现简单可以应对匀速请求
2.2）滑动窗口算法
滑动窗口可以解决（2~3秒）和（3~4秒）分别进入150个请求的问题，当窗口滑动到（1~4秒）的时候，会对（3~4秒）的150个请求进行拒绝，（3~4秒）被拒绝所以归零，之后（2~5秒）和（3~6秒）的滑动窗口都不会触发限流
2.3）令牌桶限流算法
以时间为X轴，请求量为Y轴；网络流量整形指不会超过Y轴的某个点；速率限制指不超过斜率的某个点
Ps：限制发令牌速度不限制取令牌速度
2.4）漏桶限流算法
平滑网络上的突发流量指突然多出十几个水龙头也不怕，桶满了就丢
Ps：限制了Consumer的速度，请求打到Consumer始终以恒定速率处理可防止Consumer崩溃
三、Sentinel简介
官网
3.1）Sentinel概述
3.2）Sentinel的主要特征
绿色为核心库
3.3）Sentinel的开源生态
3.4）部署Sentinel Dashboard
用户优先配置在启动之前指定参数可以改变properties文件中的配置
四、Sentinel实战
4.1）使用SphU或SphO进行限流
唯一区别是SphU直接抛异常，而SphO返回ture/false
setStrategy一般都是直接拒绝，关联就是相关联的请求也拒绝，链路是同一执行链的拒绝
基本和Sentinel Board界面一致——WARN_UP是控制斜率，RATE_LIMIT控制Y轴最大值
SphO
有执行业务方法的，也有执行限流的
查看执行结果
Windows日志地址：C:\Users\Administrator\logs\csp
SphU
4.2）使用@SentinelResource进行限流
限流规则依然是QPS。一秒超过20次限流
五、Sentinel集成
5.1）集成SpringCloud
编码方式
SPI机制
快速请求
Dashboard方式
请求过的接口才会Dashboard才会进行管理
自定义URL限流异常
通过实现UrlBlockHandler接口，来重写blocked方法
URL资源清洗
将开头为urlCleaner/全部改为urlCleaner/*
5.2）集成Nacos
grade值为1代表使用QPS
Sentinel流控规则刷新，阈值也变为10
