Spring cloud微服务安全实战-4-11Zuul网关安全开发（四）
限流，有个现成的开源项目可以帮助我们来做网关上的限流
用最新的这个版本
在pom.xml加入引用。
在限流的过程中需要存一些信息，可以存在数据库里 也可以存在redis里。这里我们演示存到数据库里
比如说配置1分钟内只能有100个请求。那么当前已经有多少个请求过去了 ，这个是需要记下来的，下一个请求来了 ，把保存的信息再拿出来，然后再去看当前这个请求能不能过。所以需要有存储。在生产上还是用redis。redis的并发能力比数据库要高很多。
这里为了看到数据用数据库
数据库相关的配置复制过来。
改下名字
下面来做限流相关的配置。
这里也可以缓冲层redis
配置的时候，可以针对这些服务来限流，例如针对token服务，或者针对order服务。
这里是针对所有的请求的默认策略
plicy-list就是针对 某个服务去单独的限流。
下面配置了针对token的限流规则
order没有配置，所以按照默认的规则
每个规则下都有四个属性
refresh-interval:规定时间的窗口，写1 就是1秒之内可以过多少请求。
limit就是可以过的请求数
quota：这些请求加在一起消耗的时间是多少
下面这样配置起来就是 1秒之内只能有2个请求。然后这两个请求的处理时间加起来不能超过1秒。
虽然你请求的次数没超限，但是你的服务压力大导致你的服务处理慢的时候，他也会给你把流量限制住。就是这样一个策略
z
type是根据什么去控制流量。
最简单的就是根据-url来控制流量
例如 发两个请求，a的话 1秒内只能有两个请求，b也是1秒内只能有2个请求。就是这个意思。
如果发一个/user的请求 同样的路径，get和post请求意思是不一样的，get是查询，post是创建。
这样就需要这个type：-httpmethod来判断了。这样就会把这两个参数的值混在一起。
同样是/a的请求 get和post是分别流控。单独记1秒内过了多少请求。
还有其他的type 例如 -user根据用户来流控，需要security的支持，一般情况下 不会用。为什么不用，后面再说。
origin，根据ip。每个ip在一秒钟只能只能发2个请求。这些是可以组合起来交叉用的 。
最终会根据配置生成一个key放到数据库中。只需要做配置就可以完成流控，大部分情况下不用写代码
最终我们用这个默认的
之前在授权的时候50%的几率不过，这里改成true 每次都过
重新启动网关
连续多点击几次。
429就是请求太多了。我们配置的限流是3秒内只能有2个。
扩展点
数据库内多了个rate的表
rate_key按照一定规则来生成的。
gateway是网关的名字
order是策略的名字
/orders：POST是请求的路径和方法
特殊的场景，和业务业管的 可能满足不了 需求。
例如 优惠券的服务，在使用优惠券的时候，有优惠券的类型。券a的业务处理逻辑比较简单 一秒钟可以处理100个。券b的业务逻辑复杂每秒只能处理10个。这时候在同一个服务里面 也就是这个 优惠券的服务里面
需要通过优惠券的类型来决定怎么限流。这个时候上面那种原始的限流就满足不了 需求了。
限流归根揭底是你那个key怎么生成的
下面例如 这里配置的是url和mehtod来限流，那么生成的就是根据url和method的生成的key
自己来定义生成的规则，让这个key生成的时候，可以按照请求中的某一个参数来生成这个key
它的构造函数有两个参数，我们在子类里面写上构造函数 也是需要两个参数，并在构造函数内调用父类的构造函数。super()
覆盖掉它的key方法。request是请求，route是zuul的路由，policy就是配置的策略。
有了这三个参数，就可以在这里 写自己的生成key的逻辑，自己来做限流
另外一个可扩展
就是错误的处理。默认情况下只要限流生效。就是返回429并返回一些错误信息。
在有些情况下 我们需要去做一些记录。有可能被人攻击了。如果什么都不做 后面就查不到谁攻击的
继承DefaultRateLimitErrorHandler
里面有三个方法。上面两个是跟限流的数据存取相关。限流的数据要存到数据库里。然后每个请求进来的时候，拿出来根据规则看这个请求能不能过。
handleSaveError就是往存储里面去存这个限流的当前信息的时候如果报错怎么处理。
handleFetch就是从数据库里面读出来的时候报错怎么处理。一般情况下 上面两个方法 不会去覆盖它
主要就是handleError这个方法。这个是限流过程中发生了错误都会到之类来处理。
可以覆盖这个方法 自己写日志等处理
注意
在网关上做限流是有一些问题的
第一：就是耦合的问题，例如优惠券类型的问题，如果后面服务的业务逻辑变了。那么网关的规则也也要改变。网关就要重新部署。例如优惠券的类型 多了一个类型。
应该做到 业务逻辑怎么变，网关不能跟着变，
限流的重量问题。限流只处理从网关进来的请求，不处理微服务之间的请求。
所以在网关这里不要做很细粒度的限流。网关这块做的是争对硬件设备的限流。
限流这里的配置类型 有user和role。根据用户和角色做限流，这些最好不要在网关上做。虽然是可以做。但是最好不在网关上去做。
因为这些东西都涉及到业务。一旦你的业务变化，网关也要跟着变。这个是很麻烦的事
网关上的限流就讲这些。
