微服务之间的限流和降级应该如何规约？

微服务架构下缓存、降级和限流是保护微服务系统运行稳定性的三大利器。
缓存的目的是提升系统访问速度和增大系统能处理的容量，而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开，而有些场景并不能用缓存和降级来解决，比如稀缺资源、数据库的写操作、频繁的复杂查询，因此需有一种手段来限制这些场景的请求量，即限流。
比如当我们设计了一个函数，准备上线，这时候这个函数会消耗一些资源，处理上限是1秒服务3000个QPS，但如果实际情况遇到高于3000的QPS该如何解决呢？
所以限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率就可以拒绝服务、等待、降级。
如何去实现一个分布式限流框架，首先，我们需要去了解最基本的两种限流算法 ：
1、 漏桶算法思路很简单，水（也就是请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，然后就拒绝请求，可以看出漏桶算法能强行限制数据的传输速率。
2、 令牌桶算法和漏桶算法效果一样但方向相反的算法，更加容易理解。随着时间流逝，系统会按恒定1/QPS时间间隔（如果QPS=100，则间隔是10ms）往桶里加入令牌（想象和漏洞漏水相反，有个水龙头在不断的加水），如果桶已经满了就不再加了。新请求来临时，会各自拿走一个令牌，如果没有令牌可拿了就阻塞或者拒绝服务。

这个问题很好，也很有代表性，首先谈限流：
限流：限流的策略分很多种，基于IP的限流，基于用户的限量，还是基于接口的限流
降级：降级是双端都需要做，服务提供方需要做，调用方也需要做，单只降级的前提一定有限流，否则降级也会被打垮
熔断：熔断的前提是非核心业务的熔断，如果核心业务都挂了，那么需要人工处理了，而不是做降级处理。
最后不管是熔断，降级都需要做告警处理，系统在什么时候熔断了，什么时候降级