目录

1. 限流的使用场景

2. gateway限流实现

2.1 前提：

2.2 导入依赖包

2.3 在项目配置文件中配置redis

2.4 开发限流需要的Bean

2.5 为服务配置限流参数

2.6 压力测试

3. 熔断

3.1 熔断的使用场景

3.2 熔断配置

1. 限流的使用场景

1. 为什么限流
   限流就是限制流量，因为服务器能处理的请求数有限，如果请求量特别大，我们需要做限流（要么就让请求等待，要么就把请求给扔了）， 限流可以保障我们的 API 服务对所有用户的可用性，也可以防止网络攻击。在高并发的应用中，限流是一个绕不开的话题。

2）常见限流方式
一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如 nginx 的 limit_conn 模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如 Guava 的 RateLimiter、nginx 的 limit_req 模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制 MQ 的消费速率。另外还可以根据网络连接数、网络流量、CPU 或内存负载等来限流。
本文讨论在gateway集成的实现

3）限流算法：

• 漏桶算法(Leaky Bucket)
  思路: 水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:

• 令牌桶算法(Token Bucket)
  随着时间流逝，系统会按恒定 1/QPS 时间间隔（如果 QPS=100，则间隔是 10ms）往桶里加入 Token（想象和漏洞漏水相反，有个水龙头在不断的加水），如果桶已经满了就不再加了。新请求来临时，会各自拿走一个 Token，如果没有 Token 可拿了就阻塞或者拒绝服务.

2. gateway限流实现

2.1 前提：

先装好redis服务

2.2 导入依赖包

   org.springframework.cloudspring-cloud-starter-gatewaycom.alibaba.cloudspring-cloud-starter-alibaba-nacos-discoveryorg.springframework.bootspring-boot-starter-data-redis-reactivecom.alibaba.nacosnacos-clientcom.alibabafastjson1.2.73org.projectlomboklombok1.18.16providedorg.springframework.bootspring-boot-starter-testtestorg.junit.vintagejunit-vintage-engine

2.3 在项目配置文件中配置redis

---========-----

spring:application:name: service-gatewaycloud:nacos:discovery:server-addr: 127.0.0.1:8848gateway:discovery:locator:#开启服务发现功能，从注册中心获取服务列表，（nacos->服务管理->服务列表）#默认服务名称需要为大写，可以通过配置lower-case-service-id: true 改变这一规则enabled: false#配置服务名使用小写lower-case-service-id: true#配置redisredis:host: 192.168.229.128port: 6379database: 0#password: 123456

redis的在gateway限流中起到存放令牌的作用

2.4 开发限流需要的Bean

具体实现：

/*** 请求限流配置*/
@Configuration
public class RequestRateLimiterConfig {/*** 按IP来限流*/@Beanpublic KeyResolver ipAddrKeyResolver() {//JDK8的新特性——Lambda表达式return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());}///**// * 按用户限流// *///@Bean//KeyResolver userKeyResolver() {//    return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("user"));//}///**// * 按URL限流,即以每秒内请求数按URL分组统计，超出限流的url请求都将返回429状态// *// * @return// *///@Bean//@Primary//KeyResolver apiKeyResolver() {//    return exchange -> Mono.just(exchange.getRequest().getPath().toString());//}
}

2.5 为服务配置限流参数

修改网关中的路由配置文件，加入限流参数：

--======--
原配置：

[{"id": "service-consumer","predicates": [{"name": "Path","args": {"_genkey_0": "/consumer/**"}}],"filters": [{"name": "StripPrefix","args": {"_genkey_0": "1"}}],"uri": "lb://service-consumer","order": 0}
]

加入限流配置（配置示例，请按自己的实际情况配置）：

[{"id": "service-consumer","predicates": [{"name": "Path","args": {"_genkey_0": "/consumer/**"}}],"filters": [{"name": "StripPrefix","args": {"_genkey_0": "1"}},{"name": "RequestRateLimiter","args": {"key-resolver": "#{@ipAddrKeyResolver}","redis-rate-limiter.replenishRate": "10","redis-rate-limiter.burstCapacity": "20"}}],"uri": "lb://service-consumer","order": 0}
]

• filter名称必须是RequestRateLimiter
• redis-rate-limiter.replenishRate：允许用户每秒处理多少个请求
• redis-rate-limiter.burstCapacity：令牌桶的容量，允许在一秒钟内完成的最大请求数
• key-resolver：使用SpEL按名称引用bean

2.6 压力测试

1）配置postman

2）运行测试

3）在没有加入限流的情况下的测试结果

4）在加入限流之后的测试情况：

3. 熔断

3.1 熔断的使用场景

网关是所有请求的入口，如果部分后端服务延时严重，则可能导致大量请求堆积在网关上，拖垮网关进而瘫痪整个系统。这就需要对响应慢的服务做超时快速失败处理，即熔断。

常用的熔断组件：Hystrix与Sentinel，本课程以Hystrix讲述。

3.2 熔断配置

1）导入依赖

org.springframework.cloudspring-cloud-starter-netflix-hystrix

2）编写熔断时的处理类

@RestController
public class FallBackController {@GetMapping("/fallback")public String fallback() {return "服务熔断 ...... ";}}

3）为服务配置熔断

[{"id": "service-consumer","predicates": [{"name": "Path","args": {"_genkey_0": "/consumer/**"}}],"filters": [{"name": "StripPrefix","args": {"_genkey_0": "1"}},{"name": "RequestRateLimiter","args": {"key-resolver": "#{@ipAddrKeyResolver}","redis-rate-limiter.replenishRate": "10","redis-rate-limiter.burstCapacity": "20"}},{"name": "Hystrix","args": {"name": "fallback""fallbackUri": "forward:/fallback"}}],"uri": "lb://service-consumer","order": 0}
]

4） 启动服务，测试

-- == --
调用接口测试：

听到consumer服务，再次调用：

5）配置熔断后，第一次请求容器超时问题
Spring Cloud项目启动后，首次使用 FeignClient 请求往往会消耗大量时间，并有一定概率因此导致请求超时(java.net.SocketTimeoutException: Read timed out)，因而有可能会触发熔断，这是由于在调用其他微服务接口前，会去请求该微服务的相关信息(地址、端口等)，并做一些初始化操作，由于默认的懒加载特性，导致了在第一次调用时，出现超时的情况。

解决方法：

• 第一种办法是设置超时时间，具体设置成多少，因项目而异，配置如下
  #hystrix调用方法的超时时间，默认是1000毫秒
  hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=5000

不推荐，容易导致有些服务已经不可用，但不用及时有效的熔断。

• 配置ribbon立即加载
  服务之间的调用顺序为：gateway->消费者->生产者
  接下来分两部分解决这个问题，一是服务之间调用Ribbon的饥饿加载，对应上面的测试为消费者调用生产者；二是网关的饥饿加载

消费者服务：

ribbon:eager-load:enabled: true  #启用立即加载clients: service-provider  #配置立即加载的服务名

网关：

ribbon:eager-load:enabled: trueclients: service-consumer