目前社区版本的集群限流方案是单点的,嵌入模式还有可能影响业务自身。独立模式因为是单点的,性能有瓶颈,出现故障无法转移。生产环境使用会存在问题。
在很多业务场景下,集群限流有很大的使用价值,比如对不同业务进行资源分配,防止单个业务占用大量资源,保护性能较弱的下游服务等。
针对以上整理部分不成熟解决方案如下:
方案1:
引入redis等中间件实现限流。这在很多系统设计中有使用。
存在问题:redis会存在网络抖动,对redis资源要求较高,感觉不推荐。
方案2:
将集群限流转换成单机限流。设置总限流参数,通过nacos等注册中心获得当前示例数。单机限流设置成 总限流数/示例数
存在问题:
(1)注册中心上下线存在延时,导致单机限流参数不能及时调整,会引起问题
(2)方案是预设集群流量均匀分配的,大部分情况下流量不均匀。会导致限流不准。
(3)原先集群限流能降级到单机限流,需要重新设计降级策略
方案3 :
基于目前社区版本集群限流进行完善,修改成分布式模式。支持集群部署。
方向1 :对应用进行分组,将一组应用限流请求路由到token server集群中的某台机器,分摊流量。集群中某台机器出现故障可以转移到其他机器。
存在问题:
(1)单台机器有瓶颈,如果单个应用流量较大,不知是否存在性能不足的问题。重新回到高并发的问题。
(2)故障转移策略可能较为复杂,需要详细设计。
方向2 :在方向1的基础性,一组应用使用多台机器。这一组机器保持数据同步。
存在问题:
(1)该方案比方向1更加复杂。同步出现延迟导致限流不准。
针对以上问题,欢迎参与讨论,希望有机会和各位大佬交流一下,看看是否有更好的解决方案。或者有成熟的替代方案。也希望了解下社区对这一块的考虑,没有提供类似功能是因为相关需求不多还是有其他架构上的思考。
1条答案
按热度按时间fdx2calv1#
在问题列表中发现已有大佬提出过相关issues
#1219
#2029
相关问题并没有得到解决。
@zhonghuwu@biankang@jasonjoo2010@a1vin-tian@JxFor@furaul@Viyond@maxiaolong@quhaiyang@xunpengliu
欢迎各位大佬继续参与讨论,一起推动相关问题解决。