1、限流的原理：
1.1、计算器算法
计数器算法采用计数器实现限流有点简单粗暴，一般我们会限制一秒钟的能够通过的请求数，比如限流qps为100，算法的实现思路就是从第一个请求进来开始计时，在接下去的1s内，每来一个请求，就把计数加1，如果累加的数字达到了100，那么后续的请求就会被全部拒绝。等到1s结束后，把计数恢复成0，重新开始计数。具体的实现可以是这样的：对于每次服务调用，可以通过AtomicLong#incrementAndGet()方法来给计数器加1并返回最新值，通过这个最新值和阈值进行比较。这种实现方式，相信大家都知道有一个弊端：如果我在单位时间1s内的前10ms，已经通过了100个请求，那后面的990ms，只能眼巴巴的把请求拒绝，我们把这种现象称为“突刺现象”
1.2、漏桶算法
漏桶算法为了消除"突刺现象"，可以采用漏桶算法实现限流，漏桶算法这个名字就很形象，算法内部有一个容器，类似生活用到的漏斗，当请求进来时，相当于水倒入漏斗，然后从下端小口慢慢匀速的流出。不管上面流量多大，下面流出的速度始终保持不变。不管服务调用方多么不稳定，通过漏桶算法进行限流，每10毫秒处理一次请求。因为处理的速度是固定的，请求进来的速度是未知的，可能突然进来很多请求，没来得及处理的请求就先放在桶里，既然是个桶，肯定是有容量上限，如果桶满了，那么新进来的请求就丢弃。
在算法实现方面，可以准备一个队列，用来保存请求，另外通过一个线程池（ScheduledExecutorService）来定期从队列中获取请求并执行，可以一次性获取多个并发执行。
这种算法，在使用过后也存在弊端：无法应对短时间的突发流量。
1.3、令牌桶算法
从某种意义上讲，令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。
2、gateway限流实践
本文采用的是令牌桶算法，令牌桶算法的实现有，Google Guava 的RateLimiter、Bucket4j、RateLimitJ ，他们支持的 back-ends为JCache、Hazelcast、Redis ，您可以根据自己的技术栈选择相应的实现。
限流的维度 ip限流、用户限流、接口限流。
首先展示的是ip限流，采用RateLimitJ方式
2.1、添加相关依赖
2.2、application.yml中添加限流配置
限流配置的name必须是RequestRateLimiter（图中还展示了降级配置。这种配置方式，降级和限流都可以实现。如果您还没有了解gateway的降级您可以点这里gateway熔断降级）
2.3路由的限流配置根据ip方式
至此gateway的限流配置已经完毕。
接下来我们进行验证
本文采用Jmeter进行验证，创建100个线程，1秒内全部启动。（当然如果您不了解Jmeter或者还没有安装您可以点这里Jmeter下载安装及使用）
在线程组中添加http请求、添加监听测试
只有20个请求可以通过，其他被拒绝，并且这通过的20个请求执行完毕之后其他请求也可以通过。
这个图正好验证了，令牌桶中的令牌虽然被拿走，但是它也在已一定的速率往令牌桶中添加令牌。
扩展 当然也可以实现用户限流、接口限流
修改路由限流配置
至此spring cloud gateway的限流原理及实践已经完成，接下来的文章将会包括动态路由、spring cloud 的持续集成等等
