- 为什么需要限流
- 如何限流
限流主要就是考虑这两点
为什么需要限流
之前已经介绍了熔断，降级，为什么还需要一个限流呢？是不是多此一举呢？
先来个结论：
熔断是为了防止雪崩，明哲保身；而限流则是在已有条件下，最大限制发挥系统效能
根据《熔断机制》可以知道，熔断有三种状态，[熔断关闭],[半熔断],[熔断开启]三种状态，如果系统压力过大，一个服务就会在三种状态来回切换
会出现一种情况，就像一辆开在崎岖山路上的法拉利，不管车的性能多好，都需要不停的加速减速
要想速度达到最佳，就得让车开在一条笔直的高速公路上
系统就是一条河，服务就像行驶在河里的船，岸的两边，一边是熔断，另一边就是限流；一个保障系统安全，一个保持最大限度运转，让系统达到高可用
如何限流
限流如何实施？
- 量化限流阀值
- 确定限流策略、算法
- 被限制流量的处理
限流阀值，这个其实就是通过系统压力测试来确定
这个工作其实在系统开发之初就需要有初步的估量，涉及到业务规模，增长速度，架构选择等等，根据现有资源及其服务能力，给出上限值
在《计数器算法》中已经说明了几种限流算法：固定窗口、滑动窗口、漏桶、令牌桶
有人总结为【两窗两桶】，很形象
固定窗口：临界问题，一旦流量波动，计数器提前计满，剩余时间都会被限流
滑动窗口：固定窗口的「固定周期」已经很小，那么使用滑动窗口也就没有意义，虽然大大减小临界问题，但总归需要预估一个窗口量，很难把握，过小引起性能和资源损耗
漏桶：不管进来多少量，出去的速率是恒定的，“出口”速度固定；当桶容量满时，就会被限流
令牌桶：“进口”速度固定；只要令牌的生成速度大于等于请求被处理的速度,系统就能正常处理
有了限流策略，那制定在服务端还是客户端呢？
从效果上讲，肯定是客户端，限制越靠入口，系统就越安全，可以防止不必要的无效流量进入服务端系统
你也可能想到对网络资源的浪费，但一般各个服务都是在同一IDC机房，因此这点不必考虑
但成本相对在服务端过高，放在客户端，客户端的数量与扩张速度也是动态的，无法评估，对每个端的限流阀值分配与下发都很复杂
因此一般都是在服务端进行限流
至于被限制的流量如何处理？大多数情况是直接抛弃，在系统之初，就有了对流量预判，从设计到资源准备都很充足，会有合理的限流阀值；如果有突发流量，可能配合监控及时增加机器，横向扩展
总结
限流与熔断，一个让系统保持最大活跃性，一个保障安全，两者技术手段有重叠，但意义完全不同，所以两者都是微服务中不可少的两个服务治理手段
