背景痛点电商大促下的“三座大山”去年双十一我负责的智能客服系统差点被流量冲垮。复盘时我们把问题收敛到三个最痛的点响应延迟高峰期 TP99 飙到 3.2 s用户一句“怎么退款”要转半天圈直接导致投诉率上升 37%。意图识别漂移当秒杀文案突然把“定金”改成“订金”后模型 Top-1 准确率从 92% 跌到 74%机器人答非所问人工坐席瞬间被打爆。会话状态丢失由于网关无状态负载均衡轮询用户上一轮刚提供的“订单号”下一秒就找不到体验如同“ Alzheimer 客服”。痛定思痛我们决定用 Java 生态重新打造一套“高可用 AI 智能客服回复系统”目标只有一个顶住 5 k QPS 的同时让对话体验像真人。技术选型为什么放弃 gRPC 转向 WebFlux先给出对比结论再讲踩坑故事。维度gRPCRESTfulWebFlux序列化Protobuf / 二进制JSON / 文本JSON / 文本线程模型Netty epoll 阻塞线程池Tomcat 阻塞线程池Reactor Netty 事件循环背压支持原生 Flow-control无Reactive Streams调试难度高需抓包解码低低与 Spring Cloud 亲和度一般好极好我们曾用 gRPC 调 TensorFlow Serving吞吐确实高但二进制报文排查问题太痛苦再加公司内部网关只认 HTTP最后折中采用 Spring WebFlux——既保持异步非阻塞又能直接复用现有 OAuth2 网关节省 40% 接入时间。核心实现1. RabbitMQ 削峰填谷 Channel 池化业务高峰时先把用户提问扔进队列后端按消费能力拉取避免直接把模型推理层打挂。配置类符合 Alibaba 规范关键字段带 JavaDoc/** * MQ 自动配置 * p提供削峰队列与线程池化 channel/p */ Configuration EnableConfigurationProperties(MqProperties.class) public class MqConfig { Bean(destroyMethod close) public ConnectionFactory connectionFactory(MqProperties prop) { CachingConnectionFactory factory new CachingConnectionFactory(); factory.setHost(prop.getHost()); factory.setPort(prop.getPort()); factory.setVirtualHost(prop.getVhost()); factory.setUsername(prop.getUser()); factory.setPassword(prop.getPassword()); // 关键每个连接最多缓存 25 个 channel factory.setChannelCacheSize(25); factory.setConnectionLimit(10); return factory; } Bean public RabbitTemplate rabbitTemplate(ConnectionFactory factory) { RabbitTemplate template new RabbitTemplate(factory); template.setMandatory(true); // 消息序列化用 JSON方便排查 template.setMessageConverter(new Jackson2JsonMessageConverter()); return template; } }生产者封装/** * 发送客服请求到削峰队列 * param sessionId 会话 ID * param question 原始问题 */ public void ask(String sessionId, String question) { AskEvent event new AskEvent(sessionId, question, Instant.now()); // 使用 send-and-forget 模式降低 RT rabbitTemplate.convertAndSend(ask.exchange, ask.route, event); }消费者端用RabbitListener做线程池隔离单机 8 并发即可把峰值 5 k QPS 平滑成 800 QPSTP99 降到 260 ms。2. TensorFlow Serving 热更新 健康检查模型每周迭代不能停服。我们采用“版本文件夹TF-Serving 自动发现”机制训练完毕把saved_model/123456时间戳当版本号推到 NAS轮询脚本ln -sfn软链到models/intent/currentTF-Serving 检测到新目录立即加载通过 Spring Boot Actuator 暴露/health/tf端点代码如下RestControllerEndpoint(id tf) public class TfHealthEndpoint { private final RestTemplate rest new RestTemplate(); GetMapping(/health) public MapString, Object health() { String url http://tfserving:8501/v1/models/intent; MapString, Object resp rest.getForObject(url, Map.class); // 简单判断最新版本是否 available boolean ready resp.get(model_version_status) ! null; return Map.of(status, ready ? UP : DOWN, timestamp, Instant.now()); } }当/actuator/tf/health返回 DOWNKubernetes 自动把 Pod 摘掉实现零中断回滚。3. 多轮状态机 Redis Lua 保证并发安全分布式环境下状态机必须“外置”。我们用 Redis Hash 存储sessionId - DialogContext核心字段intent上轮意图slots已提取槽位ttl过期时间高并发下两个线程同时写会互相覆盖于是写了一段 Lua 脚本保证“读-改-写”原子-- KEYS[1] sessionKey -- ARGV[1] newContextJson -- ARGV[2] ttlinSec local ctx redis.call(HMGET, KEYS[1], version) local ver tonumber(ctx[1]) or 0 local newVer ver 1 local ok redis.call(HMSET, KEYS[1], ARGV[1], version, newVer) redis.call(EXPIRE, KEYS[1], ARGV[2]) return newVerJava 侧用RedisScriptLong加载返回的新版本号作为乐观锁依据冲突时重试最多 3 次实测 5 k 并发下写冲突率低于 0.3%。性能优化把 TP99 压到 120 ms1. 压测报告JMeter 5000 并发场景模拟“用户提问→意图识别→答案返回”全链路硬件4C8G Pod × 20结果TP99 120 ms错误率 0.12%CPU 65%、堆内存 3.2 G2. MAT 排查内存泄漏压测 12 h 后老年代使用率缓慢上涨。Dump 快照发现tf.Session被业务线程引用未释放。解决使用池化 ThreadLocal确保Session.close()升级 TensorFlow Java 0.5.0官方已修复Graph对象泄漏加入-XX:MaxGCPauseMillis100让 GC 回收更及时。优化后12 h 老年代增长趋近于 0。避坑指南上线前必须 check 的 3 件事1. 对话超时幂等客服回答偶尔重复推送用户怒怼“刷屏”。根本原因是 MQ 消费超时后重新投递。解决每条消息带messageIdRedis 记录SETNX messageId 1做去重设置TTL 5 min兼顾“幂等”与“内存”。2. 敏感词过滤性能最初用String.contains逐条匹配CPU 直接打%。改写成 AC 自动机/** * AC 自动机构建 * param words 敏感词集合 * return 构建完成的 AC 树 */ private static AhoCorasick buildAcTree(SetString words) { AhoCorasick ac new AhoCorasick(); words.forEach(ac::addKeyword); ac.prepare(); return ac; }匹配耗时从 12 ms 降到 0.8 ms吞吐量提升 15 倍。3. 模型灰度回滚TF-Serving 支持version_labels我们在 URL 加?version_labelcanary把 5% 流量导到新模型观察 30 min 无异常后全量。回滚只需把 label 指回stable30 s 内完成。代码规范小结全项目通过p3c-pmd扫描 0 警告对外 API 必须写 JavaDoc方法内部复杂逻辑用// 1. 2. 3.分步注释日志使用占位符严禁log.info(result result)拼接防止 GC 压力。互动提问方言识别怎么做弹性降级目前我们只支持普通话但华南用户粤语提问占比 18%。如果直接上粤语模型GPU 成本翻倍。一个开放性问题留给大家如何在同一套 Java 微服务里设计“方言识别→优先走粤语模型置信度低时回落普通话”的弹性降级方案同时保证 RT 增加不超过 10%欢迎留言聊聊你的思路也许下一篇实践就来自你的建议。踩坑无数、填坑亦无数总算把系统稳定在 5 k QPS。总结一句话高并发场景下别让任何一块短板成为“情绪崩溃”的导火索——无论是 Redis 的 Lua还是 TF-Serving 的 label细节里藏着真正的可用性。希望这份笔记能帮你在自己的客服系统里少走一点弯路也欢迎一起交流更多“JavaAI”的实战经验。