目前社区版本的集群限流方案是单点的，嵌入模式还有可能影响业务自身。独立模式因为是单点的，性能有瓶颈，出现故障无法转移。生产环境使用会存在问题。

在很多业务场景下，集群限流有很大的使用价值，比如对不同业务进行资源分配，防止单个业务占用大量资源，保护性能较弱的下游服务等。

针对以上整理部分不成熟解决方案如下：
方案1：
引入redis等中间件实现限流。这在很多系统设计中有使用。
存在问题：redis会存在网络抖动，对redis资源要求较高，感觉不推荐。

方案2：

将集群限流转换成单机限流。设置总限流参数，通过nacos等注册中心获得当前示例数。单机限流设置成 总限流数/示例数

存在问题：
（1）注册中心上下线存在延时，导致单机限流参数不能及时调整，会引起问题
（2）方案是预设集群流量均匀分配的，大部分情况下流量不均匀。会导致限流不准。
（3）原先集群限流能降级到单机限流，需要重新设计降级策略

方案3 ：

基于目前社区版本集群限流进行完善，修改成分布式模式。支持集群部署。

方向1 ：对应用进行分组，将一组应用限流请求路由到token server集群中的某台机器，分摊流量。集群中某台机器出现故障可以转移到其他机器。
存在问题：
（1）单台机器有瓶颈，如果单个应用流量较大，不知是否存在性能不足的问题。重新回到高并发的问题。
（2）故障转移策略可能较为复杂，需要详细设计。

方向2 ：在方向1的基础性，一组应用使用多台机器。这一组机器保持数据同步。
存在问题：
（1）该方案比方向1更加复杂。同步出现延迟导致限流不准。

针对以上问题，欢迎参与讨论，希望有机会和各位大佬交流一下，看看是否有更好的解决方案。或者有成熟的替代方案。也希望了解下社区对这一块的考虑，没有提供类似功能是因为相关需求不多还是有其他架构上的思考。