谈谈微服务中的限流、熔断和降级

1、限流

1.1 为什么需要限流

对外的API服务

• 用户增长过快
• 因为某个热点事件（微博热搜）
• 竞争对象爬虫
• 恶意的刷单
• 开学季（可预知）

这些情况都是无法预知的，不知道什么时候会有10倍甚至20倍的流量打进来，如果真碰上这种情况，扩容是根本来不及的（弹性扩容都是虚谈，一秒钟能扩容完成吗？）

对内的RPC服务

一个服务A的接口可能被BCDE多个服务进行调用，在B服务发生突发流量时，直接把A服务给调用挂了，导致A服务对CDE也无法提供服务。
1、每个调用方采用线程池进行资源隔离
2、使用限流手段对每个调用方进行限流

1.2 常见的限流算法

常见的限流算法有：计数器、漏桶、令牌桶。

计数器算法

• 实现：采用计数器实现限流有点简单粗暴，一般我们会限制一秒钟的能够通过的请求数，比如限流qps为100，算法的实现思路就是从第一个请求进来开始计时，在接下去的1s内，每来一个请求，就把计数加1，如果累加的数字达到了100，那么后续的请求就会被全部拒绝。等到1s结束后，把计数恢复成0，重新开始计数。
• 弊端：如果我在单位时间1s内的前10ms，已经通过了100个请求，后面的990ms，只能眼巴巴的把请求拒绝，这种现象称为“突刺现象”，不平滑