对于通配的请求，压测时产生过多的实际path，会导致熔断计数器过大

[andrewshan]

SDK中，为了进行熔断计数，对于每个接口会在map中保存调用计数。所以当产生了过多的API时，会导致内存过多。

产生的API有2个原因：

• API接口数过多
• 用户使用了通配接口，实际根据通配接口匹配出很多的API

[ligj321]

环境主要依赖包及版本信息：

org.springframework.boot
spring-boot-starter-parent
2.3.4.RELEASE



org.springframework.cloud
spring-cloud-dependencies
Finchley.RELEASE


org.springframework.cloud
spring-cloud-starter-netflix-zuul


org.springframework.cloud
spring-cloud-starter-openfeign


com.tencent.cloud
spring-cloud-tencent-dependencies
1.13.3-Hoxton.SR12

调用路径：
1.通过zuul转发service[web入口流量均通过clb负载首先进入zuul进行filter校验，转发到下游服务进行]
如：zuul.routes.user.path=/u/**
zuul.routes.user.serviceId=base

2.服务间通过feign调用service

调用url示例：
1.常规固定url，post请求，更改body内容进行请求发起
2.非固定url，get请求，参数附加地址栏进行请求发起
3.通配请求url，参数示例/d/customers/base/${customerId}

熔断实现核心需求：
1.以zuul为应用最上游发起，允许转发路径控制服务提供者，接口级熔断、节点熔断、服务集群熔断。
2.服务间feign调用，允许接口级熔断、节点熔断、服务集群熔断。

使用建议优化：
1.polaris熔断 zuul filter记录对象PolarisCircuitBreakerConfigBuilder过多，建议优化对象内存中储存粒度和周期。
2.上报对象过多，展示粒度过细对于控制台压力过大，建议明确核心匹配需求，限流和熔断相关展示，明细需求建议在apm中完成。

[ligj321]

补充apm监控收集展示。

[andrewshan]

1.polaris熔断 zuul filter记录对象PolarisCircuitBreakerConfigBuilder过多，建议优化对象内存中储存粒度和周期。

解决方案：
这部分主要是因为H版本spring-cloud-circuitbreaker中，org.springframework.cloud.client.circuitbreaker.AbstractCircuitBreakerFactory会缓存所有的熔断配置，在网关场景下会进行保存这个数据。实际上这个缓存没有任何作用，北极星的实现中不依赖该缓存，所以北极星实现可以优化成不提交该缓存。

[ligj321]

感谢提供支持，您的实现能满足我们的需求。如果条件允许的话，请在版本测试过程对依赖环境下，在采集上报过程中，对未发现内存占用或者场景进行优化，我们的核心需求就是在使用北极星限流熔断服务的同时尽可能减少应用额外增加的负担，祝生活工作愉快~