微服务基础——厉害了！API网关

对于经常出现流量突增的系统，比如618，双11大促、微博出现重大新闻事件等，我们很难及时的评估流量，做好应对预案，最终导致服务整个不可用。因此做好限流就十分有必要了，当流量突增超过限流阈值时，通过限流降级策略保护核心业务的正常运转。选择限流方案，主要考虑使用什么样的限流算法，单击限流还是分布式限流。

1、 限流算法

简单计数法、令牌桶、漏桶等是常见的限流算法，简单计数法的特点是统计某一段时间内的请求个数，以此判断是否拒绝请求，这种简单粗暴的限流方式无法应对突发流量；令牌桶算法的特点是，以固定速率往桶里添加令牌，通过桶里是否有令牌判断是否拒绝请求，桶的大小决定了突发流量的大小。漏桶的思想和令牌桶相反，以固定的速率分发请求，实现流量的平滑处理。因此，当我们完全不关心流量突发的情况，选择简单计数法即可，当我们无法容忍流量突发，则选择漏桶算法，当我们允许一定程度的流量突发，选择令牌桶算法。

2、 单机限流

单击限流，调用数存储在本地，无需频繁的和远端节点交互，性能比较高。

3、 分布式限流

分布式限流，调用数存储在远端节点，如redis。每次需要和远端节点交互，性能较低。那为啥还要使用分布式限流呢？因为有些场景下（特别是API网关），限流值是用户配置的，需要保证限流的准确性。我们有个折中的方案，先在本机存储少量的调用数，然后同步到远端节点，这样就成倍的减少了调用远端的次数，虽然准确性有所降低，但是在可接受的范围。