半年 470 万次调用，10 个坑 我们的客服 Agent 是 2025 年 9 月上线的，到今天跑了半年多一点。数据：累计 470 万次对话，日均 2.6 万次，峰值 4.1 万次/天，P99 延迟 3.2 秒，月均 token 成本 7.8 万。 半年前上线的时候，我在周报里写「技术方案已验证，
分代 ZGC 在我们的网关上跑了一年 去年十月，我们把 API 网关从 G1 换成了分代 ZGC，到这个月正好一年。这篇是完整的数据总结，包括参数、遇到的四个问题、以及我现在的看法。 先说结论：换成 ZGC 是我们这一年最值的一次技术决策，但它不是银弹，而且代价被大多数人低估了。 背景：为什么要换
数据量涨到 2300 万，向量检索 P99 从 60ms 崩到 1.8 秒 我们的商品语义搜索，7 月份上线时是 420 万条向量，P99 稳定在 60 毫秒。到 10 月底商品库扩到 2300 万条，接口 P99 涨到 1820 毫秒，同时 Milvus 集群的内存水位长期在 91%，隔三差五触发
背景：大促前的压测暴露了长尾 八月底大促压测，核心的下单查询接口平均 RT 只有 120ms，看着挺好，但 P99 飙到 800ms，监控里偶发还有 1.5 秒的尖刺。平均好看掩盖了长尾，而用户体验恰恰被那 1% 的慢请求毁掉。我接了这活，目标是把 P99 压到 150ms 以内。 全链路耗时分析：
把线程池换成虚拟线程 我们有个网关聚合服务，每请求要并发调 5 个下游，原来用 200 个平台线程的池子，峰值打满就排队。用户多的时候，线程池耗尽，请求在队列里干等，RT 从 200ms 飙到 2 秒。听说 JDK 19 的虚拟线程能把"一个任务一个线程"做到近乎免费，就拿来做了对照实验，想看看是不
那个 3000 行的 Service 接手交易核心模块时，OrderService.java 有 3128 行，下了 47 个 @Autowired 的 DAO 和远程 client。任何一处改动我都得屏住呼吸。上周一个改下单幂等的小需求，回归测试就跑了三轮，改动 8 行、提心吊胆一整天。更糟的是，
重构支付模块时，我把 600 行 if-else 拆成了四个模式 上个月接手支付模块重构。打开 PaymentService.pay() 那一刻我有点懵：一个方法 600 多行，开头十几个 if (channel == WECHAT) ... else if (channel == ALIPAY)
商品详情页 P99 1.8 秒，五个 RPC 串行调用 12 月中旬，前端同学甩过来一张截图：商品详情页首屏白屏 2 秒多，用户投诉"点商品没反应"。我去看 SkyWalking 的拓扑，这个接口平均 690 ms，P99 1.8 s，P999 3.2 s。 接口干的事很简单，串着调了 5 个下游：
运营说：这个报表等到花儿都谢了 十一月底，运营同学提了个工单："销售明细报表要等 8 秒以上，导出的时候更是直接超时。" 我看了下 slow log，那条查询平均 8.4 秒，最慢的一次 21 秒： # Time: 2020-11-24T14:22:31.882113+08:00 # User@Ho
