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。根据用户和角色做限流，这些最好不要在网关上做。虽然是可以做。但是最好不在网关上去做。
因为这些东西都涉及到业务。一旦你的业务变化，网关也要跟着变。这个是很麻烦的事

网关上的限流就讲这些。

结束