几个维度。
时间
1s多少次。1s。
次数
1s多少次。次数，计数器。
时间维度
时间窗口算法。
token集合维度
控制写token到集合和从集合读token的速度。
接口
单个接口，还是整个服务。
单机还是分布式
因为这个会影响到算法。
单机，就是单机限流算法。
分布式，有2种：
1.如果是针对单个服务进行限流，那么可以使用单机限流算法。这个时候，总的次数应该是单机次数*机器数量。
2.如果是针对集群，那么使用分布式限流算法。这个时候，总的次数就是中心计数器的次数。
参考
6、如何选择单机限流还是分布式限流 首先需要说明一下：这里所说的单机限流和分布式限流与之前提到的单机限流算法和分布式限流算法并不是一个概念！为了提高服务的性能和可用性，微服务都会多实例集群部署，所谓单机限流是指：独立的对集群中的每台实例进行接口限流，比如限制每台实例接口访问的频率为最大 1000 次 / 秒，单机限流一般使用单机限流算法；所谓的分布式限流是指：提供服务级的限流，限制对微服务集群的访问频率，比如限制 A 调用方每分钟最多请求 1 万次“用户服务”，分布式限流既可以使用单机限流算法也可以使用分布式限流算法。
单机限流的初衷是防止突发流量压垮服务器，所以比较适合针对并发做限制。分布式限流适合做细粒度限流或者访问配额，不同的调用方对不同的接口执行不同的限流规则，所以比较适合针对 hits per second 限流。从保证系统可用性的角度来说，单机限流更具优势，从防止某调用方过度竞争服务资源来说，分布式限流更加适合。
分布式限流与微服务之间常见的部署架构有以下几种：
-
在接入层（api-gateway）集成限流功能
这种集成方式是在微服务架构下，有 api-gateway 的前提下，最合理的架构模式。如果 api-gateway 是单实例部署，使用单机限流算法即可。如果 api-gateway 是多实例部署，为了做到服务级别的限流就必须使用分布式限流算法。 -
限流功能封装为 RPC 服务
当微服务接收到接口请求之后，会先通过限流服务暴露的 RPC 接口来查询接口请求是否超过限流阈值。这种架构模式，需要部署一个限流服务，增加了运维成本。这种部署架构，性能瓶颈会出现在微服务与限流服务之间的 RPC 通信上，即便单机限流算法可以做到 200 万 TPS，但经过 RPC 框架之后，做到 10 万 TPS 的请求限流就已经不错了。 -
限流功能集成在微服务系统内
这种架构模式不需要再独立部署服务，减少了运维成本，但限流代码会跟业务代码有一些耦合，不过，可以将限流功能集成在切面层，尽量跟业务代码解耦。如果做服务级的分布式限流，必须使用分布式限流算法，如果是针对每台微服务实例进行单机限流，使用单机限流算法就可以。
7、针对不同业务使用不同限流熔断策略 这里所讲的熔断策略，就是当接口达到限流上限之后，如何来处理接口请求的问题。前面也有提到过一些限流熔断策略了，所谓否决式限流就是超过最大允许访问频率之后就拒绝请求，比如返回 HTTP status code 429 等，所谓阻塞式限流就是超过最大允许访问频率之后就排队请求。除此之外，还有其他一些限流熔断策略，比如：记录日志，发送告警，服务降级等等。
同一个系统对于不同的调用方也有可能有不同的限流熔断策略，比如对响应时间敏感的调用方，我们可能采用直接拒绝的熔断策略，对于像后台 job 这样对响应时间不敏感的调用方，我们可能采用阻塞排队处理的熔断策略。
我们再来看下其他熔断策略的一些应用场景：比如限流功能刚刚上线，为了验证限流算法的有效性及其限流规则的合理性，确保不误杀请求，可以先采用日志记录 + 告警的限流熔断策略，通过分析日志判定限流功能正常工作后，再进一步升级为其他限流熔断策略。
不同的熔断策略对于选择限流算法也是有影响的，比如令牌桶和漏桶算法就比较适合阻塞式限流熔断场景，如果是否决式的限流熔断场景就比较适合选择基于时间窗口的限流算法。
