Spring Cloud Gateway 结合配置中心限流

前言

上篇文章我讲过复杂的限流场景可以通过扩展RedisRateLimiter来实现自己的限流策略。

假设你领导给你安排了一个任务，具体需求如下：

• 针对具体的接口做限流
• 不同接口限流的力度可以不同
• 可以动态调整限流配置，实时生效

如果你接到上面的任务，你会怎么去设计+实现呢？

每个人看待问题的角度不同，自然思考出来的方案也不同，正所谓条条大路通罗马，能到达目的地的路那就是一条好路。

如何分析需求

下面我给出我的实现方式，仅供各位参考，大牛请忽略。

具体问题具体分析，针对需求点，分别去做分析。

需求一 “如何针对具体的接口做限流” 这个在上篇文章中也有讲过，只需要让KeyResolver返回的是接口的URI即可，这样限流的维度那就是对这个接口进行限流。

需求二 “不同接口限流的力度可以不同” 这个通过配置的方式明显实现不了，配置中的replenishRate和burstCapacity都是配置死的，如果要做成动态的那么必须的自己通过扩展RedisRateLimiter来实现。

前提是必须有一个配置列表，这个配置列表就是每个接口对应的限流数值。有了这个配置我们就可以通过请求的接口获取这个接口对应的限流值。

需求三“可以动态调整限流配置，实时生效” 这个的话也比较容易，无论你是存文件，存数据库，存缓存只要每次都去读取，必然是实时生效的，但是性能问题我们不得不考虑啊。

存文件，读取文件，耗IO，主要是不方便修改
存数据库，可以通过web界面去修改，也可以直接改数据库，每次都要查询，性能不行
存分布式缓存（redis）,性能比数据库有提高

对比下来肯定是缓存是最优的方案，还有更好的方案吗？
有，结合配置中心来做，我这边用自己的配置中心（https://github.com/yinjihuan/smconf）来讲解，换成其他的配置中心也是一样的思路。

配置中心的优点在于它本来就是用来存储配置的，配置在项目启动时加载完毕，当有修改时推送更新，每次读取都在本地对象中，性能好。

具体方案有了之后我们就可以开始撸代码了，但是你有想过这么多接口的限流值怎么初始化吗？手动一个个去加？

不同的服务维护的小组不同，当然也有可能是一个小组维护，从设计者的角度来思考，应该把设置的权利交给用户，交给我们的接口开发者，每个接口能够承受多少并发让用户来定，你的职责就是在网关进行限流。当然在公司中具体的限制量也不一定会由开发人员来定哈，这个得根据压测结果，做最好的调整。

话不多说-开始撸码

首先我们定义自己的RedisRateLimiter，复制源码稍微改造下即可, 这边只贴核心代码。

public class CustomRedisRateLimiter extends AbstractRateLimiter<CustomRedisRateLimiter.Config>
		implements ApplicationContextAware {

	public static final String CONFIGURATION_PROPERTY_NAME = "custom-redis-rate-limiter";
	public static final String REDIS_SCRIPT_NAME = "redisRequestRateLimiterScript";
	public static final String REMAINING_HEADER = "X-RateLimit-Remaining";
	public static final String REPLENISH_RATE_HEADER = "X-RateLimit-Replenish-Rate";
	public static final String BURST_CAPACITY_HEADER = "X-R