思路来源：bilibili 河北王校长

---

在我们的项目中，我们采用了三层限流设计，以应对高并发场景，同时确保系统的可用性、稳定性，并防止恶意的流量攻击。
首先，第一层限流是在Nginx层面，称为IP限流。我们使用Nginx的http_limit_req_module模块，根据用户IP进行限流。这是第一道防线，主要对抗恶意IP的DDoS攻击，防止大量的非法请求进入到我们系统的深层。
第二层为gateway 对用户层级进行限流。我们根据用户的唯一标识，如user_id，控制每个用户在单位时间内能发送的请求数量。这可以确保公平性，防止单一用户占用过多资源，影响其他用户的使用体验。
第三层为微服务限流。在每个微服务中，我们使用如Google的Guava RateLimiter等技术进行限流。这可以防止某个服务的过载，从而影响整个系统的稳定性。每个服务独立设定限流阈值，根据其自身的处理能力和业务需求调整。
整体来说，这个三层限流的设计，从网络层面到服务层面，层层筛选，有效地把需要处理的请求“漏洞”下来，既保护了系统资源，也保证了高请求量条件下的用户体验和服务的高可用性。

面试官可能会问

你能详细介绍一下Nginx的http_limit_req_module模块吗？

Nginx中的 http_limit_req_module 模块，可以用于限制处理请求的速率，在许多场合非常有用，特别是当您打算保护系统免受任何可能的DDoS攻击时。
这个模块的工作原理是定义一个叫做"速率"的值，这个值是对单位时间内请求的数量进行限制的。比如，你可以设置每分钟只处理100个请求。当某个客户端的请求速率超过这个限制时，Nginx将会把这个请求放入一个队列中，等待处理。如果队列中的请求太多，或者等待的时间太长，那么这个请求就会被丢弃。 在配置文件中，你需要使用limit_req_zone指令来定义这个限制。在这个指令中，你需要指定用于限制速率的关键字，通常情况下，我们会使用客户端的IP地址。然后，你需要设定速率值。 然后，你需要在服务器块或者位置块中，使用limit_req指令来应用这个限制。你也可以通过设置 limit_req 的参数来调整队列的大小或者等待的时间。 通过精心的配置，这个模块可以显著地帮助你提高系统的稳定性和安全性。

你能解释一下如何在Nginx中配置http_limit_req_module模块吗？

使用Nginx的 http_limit_req_module 模块进行限流，需要进行以下步骤配置：
首先，在http块中定义限制速率的区域。这通常使用limit_req_zone指令完成。例如，如果要对IP进行限制，并让每个IP每秒只能有10个请求，可以这样配置：

http {limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;...
}

这里$binary_remote_addr是客户端IP，zone=perip:10m定义了一个名为 perip 的存储区，大小为 10M，用于存储每个IP的状态，rate=10r/s则表示限制速率为每秒10个请求。
然后，在需要应用这个限制的server块或location块中，使用limit_req指令来应用这个限制。例如：

server {location /api/ {limit_req zone=perip burst=5;...}
}

这里zone=perip表示应用我们之前定义的perip区域，burst=5表示允许在短时间内超过定义的速率，最多累积5个请求等待处理。
以上便是Nginx的http_limit_req_module模块的基础配置。

你知道如何调整Nginx的http_limit_req_module模块以适应不同的业务需求吗？

Nginx 的 http_limit_req_module 模块通过一些配置参数提供了一些调整限流策略的灵活性，以适应不同的业务需求。

1. rate: 这个参数定义了请求的速率限制，例如rate=10r/s表示每秒钟只允许10个请求。根据业务的需求和服务器的运行能力，你可以灵活调整这个数值。
2. burst: 这个参数可以允许请求在短时间内超过速率限制，对应的数值即允许突发的请求数量。这个参数可以帮助你在不影响用户体验的前提下进行限流。
3. nodelay: 通常与burst参数一起使用。如果没有设置nodelay，那么在突发流量到来时，超出rate但在burst范围内的请求会被等待处理，而不是立即处理。如果设置了nodelay，那么超出rate但在burst范围内的请求会立即被处理。

举个例子，假设你的业务主要面向个人用户，且大部分时间请求量稳定，但在某些高峰期会有大量请求，这时候你可能需要设定一个适中的rate，并允许一定量的burst，以提供良好的用户体验。

什么情况下需要使用burst参数来允许突发的请求数量？

在某些情况下，可能会出现短时间内请求突然增多的情况，比如说在某个活动开始的前几秒钟，或者在一个新的服务刚刚上线时。这种突然增多的请求如果超出了之前设置的rate并且没有设置 burst，会被直接丢弃，这可能会导致用户体验下降或者服务可用性降低。 在这种情况下，如果预见到了这样的突然增多的请求，就可以设置 burst 参数来允许一定的突发流量。burst 参数设置的是允许突发请求的数量。这样在短时间内的大量请求就可以被缓冲下来，进入等待队列，而不是被直接丢弃。
例如，如果设置了limit_req zone=mylimit burst=20;，那么在超出rate限制的情况下，还可以允许有20个请求进入等待队列。这样就可以在保证服务稳定性的同时，也不会因为直接丢弃大量请求而影响了用户体验。 所以，当你预见到会有短时间内的突发流量，并且希望这些请求能够得到处理，而不是被直接丢弃，就应该使用 burst 参数来允许一定数量的突发请求。

请详细说说 gateway 层面的限流

项目 demo

如果你是在Spring Cloud Gateway中进行限流的话，你可以使用Spring提供的RequestRateLimiter网关过滤器来实现。
首先，你需要在配置文件中定义你的限流规则。限流规则可以基于不同的key来定义，比如说user_id。以下是一个针对user_id进行限流的配置示例：

spring:cloud:gateway:routes:- id: user_routeuri: http://mybackend.compredicates:- Path=/api/**filters:- name: RequestRateLimiterargs:redis-rate-limiter.replenishRate: 10redis-rate-limiter.burstCapacity: 20key-resolver: "#{@userIdResolver}"

在这个例子中，replenishRate定义了每秒可以处理的请求数量，burstCapacity定义了可以接受的突发请求数。key-resolver用于定义如何从请求中获取user_id。
然后，你需要实现一个KeyResolver接口，该接口实现了如何提取user_id。以下的Java代码演示了如何从请求中获取user_id：

import org.springframework.cloud.gateway.filter.ratelimit.KeyResolver;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;@Service
public class UserIdKeyResolver implements KeyResolver {@Overridepublic Mono<String> resolve(ServerWebExchange exchange) {return Mono.just(exchange.getRequest().getQueryParams().getFirst("user_id"));}
}

在这个例子中，user_id从请求的query param中获取。如果user_id在header或者在cookie中，你可能需要修改这部分代码。
这样，Spring Cloud Gateway就会为每个user_id进行限流了。

回答

在我的系统中，我特意设计了一个名为API网关的组件，这就像是系统的入口，所有请求必须通过这个"大门"。为了保证系统在高流量环境下依然稳定运行，我设置了"限流"机制。 在实现限流时，我的做法是首先在网关的配置文件里定义限流规则。我设定了每个用户每秒能发送的请求数量，以及在短时间内允许的最大请求数量。 然后，我需要一种办法来识别每个用户，这就是我提到的"user_id"。通过请求中的一些特定信息，比如查询参数、头信息等，我就可以获取到这个"user_id"。 有了这个设计，我就可以有效地对系统中每个用户的请求进行控制，确保没有任何用户会对系统构成威胁。再者，通过在网关层面实现这个限流机制，我能够为所有应用程序提供统一的限流服务，极大地简化了工作流程和管理。

在网关层面实现限流机制有哪些好处？

实现网关层面的限流机制有很多好处。比如：

1. 统一管理：通过在网关层级实现限流，我能够在一个集中的地方来管理所有服务的流量控制，而无需在每个服务中单独配置。
2. 防止系统过载：限流可以防止任何一个服务因为过大的流量而崩溃，这样可以增加系统的稳定性。
3. 公平性：限流能够确保所有的用户都得到合理的请求量，防止某些用户占用大量的资源。
4. 服务保护：如果有服务出现问题或者异常，限流机制可以防止这个服务的问题扩散到整个系统，起到了一定的隔离效果。
5. 方便的应对突发流量：如果我有预期到的高流量请求，我可以快速地在网关层面做出调整来应对。

所以，实现网关层面的限流对于保证系统的稳定性和公平性，以及方便的系统管理都有着重要的作用。

为什么用了 nginx 还要用 spring cloud gateway 呢

当然, 面试官问的问题非常好。在我的项目中，尽管我可以使用Nginx进行负载均衡、反向代理和限流等操作，但我仍选择了Spring Cloud Gateway作为我的微服务的API网关，有以下几个原因。
首先，我的项目主要基于Spring Boot和Spring Cloud进行开发，Spring Cloud Gateway能够无缝地与这些工具集成，能够节省我处理额外兼容性问题的时间。
其次，Spring Cloud Gateway 支持非阻塞的方式处理请求，这是Nginx无法做到的。
再者，Spring Cloud Gateway支持动态地通过编程定义路由规则，而不像Nginx那样需要进行静态配置，这意味着我可以更加灵活地处理复杂的路由逻辑。
最后，Spring Cloud Gateway集成了Spring Cloud的服务发现功能，以及与Spring Cloud集群配合的所有断路、降级、限流机制，强化了我的微服务架构的健壮性。
所以，虽然 Nginx 已经非常强大，但在我的架构中，Spring Cloud Gateway 更加适应我项目的需求。