总在不轻易间就留了个频繁GC的坑

今天分享一个在实践过程中遇到的问题，也许你也遇到过。

针对 RPC 服务做埋点的时候，想知道下面这些指标：

• QPS
• 响应时间
• 被哪个服务调用了
• 被哪个接口调用了

会有下面的代码进行指标的暴露：

Counter.builder("dubbo.request.total").description("请求数量")
        .tags(Tags.of(apiTag, typeTag, originApplicationTag, originApiTag))
        .register(meterRegistry).increment();

apiTag：比说 OrderService.createOrder

typeTag：success, error, timeout 等

originApplicationTag: 来源的服务名称，比如 goods-service

originApiTag：来源的 API 信息，比如 GET:goods/1001

在程序中会通过/actuator/prometheus 进行数据的暴露，格式如下：

dubbo_request_total{api="GoodsRemoteService.get(int)",originApplication="order-service",originApi="order/1001",type="success",} 59.0

dubbo_request_total 这个指标会产生 N 条，N 的决定因素就是 dubbo_request_total 中这些 tag 值的重复度，也就是完全一样的数据只有一条，如果有一个 tag 不一样，就会新产生一条数据。

上线后没多久，就收到了频繁 GC 的告警。然后排查下来发现指标数据已经堆积了很多。根本原因在 originApi，因为接口是 Restful 风格的资源形式，所以一个接口会产生 N 条数据，比如 order/1001, order/1002 等。

时间越来越长，被访问的数据范围也就越大，内存中堆积的数据也就越多，然后就出问题了。

Restful 风格的资源形式在其他的场景中也经常会遇到，比如用 Sentinel 限流的时候也是一样，在后台也是会显示很多资源，也得做格式化才行。

关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud 微服务-全栈技术与案例解析》, 《Spring Cloud 微服务 入门 实战与进阶》作者, 公众号猿天地发起人。

- END -