架构设计
- 分层架构
- 应用层：负责接收外部请求，识别业务场景，例如通过请求头、特定URL模式或者用户身份等信息判断是促销活动还是日常业务。然后将请求转发给相应的微服务，并根据识别的业务场景传递限流相关的元数据。
- 微服务层：每个微服务内部处理具体的业务逻辑，并根据应用层传递的限流元数据进行限流处理。每个微服务都有自己独立的限流策略配置和执行模块。
- 配置中心：存储不同业务场景下各个微服务的限流策略配置，如限流阈值、限流算法参数等。配置中心支持动态更新配置，确保微服务能够及时获取最新的限流策略。
- 分布式架构
- 采用分布式限流：由于是微服务架构，单个微服务的限流可能无法满足全局需求。使用分布式限流框架，确保在整个集群范围内对流量进行有效控制。例如，可以基于Redis实现分布式限流，利用Redis的原子操作来保证限流的准确性和一致性。
技术选型
- Spring Cloud Alibaba Sentinel
- 特点：Sentinel是一个强大的流量控制框架，支持多种限流算法，如QPS（每秒查询率）限流、线程数限流等。它可以与Spring Cloud很好地集成，通过注解方式方便地在微服务中实现限流功能。
- 优势：能够实时监控流量，动态调整限流规则。支持集群限流，对于复杂的微服务架构场景非常适用。同时，它有丰富的控制台界面，可以方便地配置和管理限流策略。
- Redis
- 用途：作为分布式缓存和存储，用于存储限流相关的数据，如限流计数器、限流规则等。利用Redis的原子操作，如
INCR命令，可以高效地实现分布式限流计数器，保证在高并发场景下限流的准确性。
- 优势：具有高可用性、高性能，支持集群部署，能够满足大规模微服务系统的需求。
具体实现思路
- 业务场景识别
- 在网关层：使用Spring Cloud Gateway等网关技术，在请求进入系统时进行初步的业务场景识别。例如，通过自定义的过滤器，解析请求头中的特定字段，如
promotion - flag，如果值为true，则判断为促销活动场景。
- 在微服务内部：进一步验证和补充业务场景信息。例如，根据请求的业务参数或者用户角色等信息再次确认业务场景。如果是电商系统，某些特定商品的请求可能与促销活动相关，通过商品ID等参数判断。
- 限流策略配置
- 配置中心：使用Spring Cloud Config或者Apollo等配置中心。在配置中心创建不同业务场景下各个微服务的限流策略配置文件，例如
promotion - service - limit.yml和normal - service - limit.yml。这些文件中定义了每个微服务在不同场景下的限流阈值、限流算法等信息。
- 动态更新：配置中心支持动态推送配置更新。当业务场景发生变化时，管理员可以在配置中心修改相应的限流策略，然后通过配置中心的推送机制，将新的策略推送给各个微服务。微服务监听到配置更新后，重新加载限流策略。
- 限流实现
- 基于Sentinel：在微服务的业务方法上添加Sentinel的限流注解，如
@SentinelResource。在注解中指定限流规则的名称，该名称与配置中心中定义的限流策略相对应。例如：
@SentinelResource(value = "promotion - api - limit", blockHandler = "handlePromotionBlock")
public ResponseEntity<String> promotionApi() {
// 业务逻辑
return ResponseEntity.ok("Promotion API response");
}
- 分布式限流：结合Redis实现分布式限流。通过Redis的
INCR命令对每个微服务的请求计数器进行原子性递增。例如，在Sentinel的自定义限流规则中，利用Redis判断当前请求是否超过限流阈值。伪代码如下：
Jedis jedis = new Jedis("localhost", 6379);
String key = "promotion - service - counter";
Long count = jedis.incr(key);
if (count > 100) { // 假设促销活动场景限流阈值为100
// 触发限流逻辑
}
if (count == 1) {
jedis.expire(key, 60); // 设置过期时间为60秒
}
