背景痛点：电商大促下的“三座大山”
去年双十一，我负责的智能客服系统差点被流量冲垮。复盘时，我们把问题收敛到三个最痛的点：
- 响应延迟：高峰期 TP99 飙到 3.2 s，用户一句“怎么退款”要转半天圈，直接导致投诉率上升 37%。
- 意图识别漂移：当秒杀文案突然把“定金”改成“订金”后，模型 Top-1 准确率从 92% 跌到 74%，机器人答非所问，人工坐席瞬间被打爆。
- 会话状态丢失：由于网关无状态+负载均衡轮询，用户上一轮刚提供的“订单号”下一秒就找不到，体验如同“ Alzheimer 客服”。
痛定思痛，我们决定用 Java 生态重新打造一套“高可用 AI 智能客服回复系统”，目标只有一个：顶住 5 k QPS 的同时，让对话体验像真人。
技术选型：为什么放弃 gRPC 转向 WebFlux
先给出对比结论，再讲踩坑故事。
| 维度 | gRPC | RESTful | WebFlux |
|---|---|---|---|
| 序列化 | 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 QPS，TP99 降到 260 ms。
2. TensorFlow Serving 热更新 + 健康检查
模型每周迭代，不能停服。我们采用“版本文件夹+TF-Serving 自动发现”机制：
- 训练完毕把
saved_model/123456（时间戳当版本号）推到 NAS； - 轮询脚本
ln -sfn软链到models/intent/current； - TF-Serving 检测到新目录立即加载；
- 通过 Spring Boot Actuator 暴露
/health/tf端点，代码如下：
@RestControllerEndpoint(id = "tf") public class TfHealthEndpoint { private final RestTemplate rest = new RestTemplate(); @GetMapping("/health") public Map<String, Object> health() { String url = "http://tfserving:8501/v1/models/intent"; Map<String, 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返回 DOWN，Kubernetes 自动把 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 侧用RedisScript<Long>加载，返回的新版本号作为乐观锁依据，冲突时重试，最多 3 次，实测 5 k 并发下写冲突率低于 0.3%。
性能优化：把 TP99 压到 120 ms
1. 压测报告（JMeter 5000 并发）
- 场景：模拟“用户提问→意图识别→答案返回”全链路
- 硬件：4C8G Pod × 20
- 结果：
- TP99 120 ms
- 错误率 0.12%
- CPU 65%、堆内存 3.2 G
2. MAT 排查内存泄漏
压测 12 h 后，老年代使用率缓慢上涨。Dump 快照发现tf.Session被业务线程引用未释放。解决：
- 使用池化 + ThreadLocal，确保
Session.close()； - 升级 TensorFlow Java 0.5.0，官方已修复
Graph对象泄漏； - 加入
-XX:MaxGCPauseMillis=100，让 GC 回收更及时。
优化后，12 h 老年代增长趋近于 0。
避坑指南：上线前必须 check 的 3 件事
1. 对话超时幂等
客服回答偶尔重复推送，用户怒怼“刷屏”。根本原因是 MQ 消费超时后重新投递。解决：
- 每条消息带
messageId，Redis 记录SETNX messageId 1做去重； - 设置
TTL = 5 min，兼顾“幂等”与“内存”。
2. 敏感词过滤性能
最初用String.contains逐条匹配，CPU 直接打%。改写成 AC 自动机：
/** * AC 自动机构建 * @param words 敏感词集合 * @return 构建完成的 AC 树 */ private static AhoCorasick buildAcTree(Set<String> 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_label=canary把 5% 流量导到新模型；观察 30 min 无异常后全量。回滚只需把 label 指回stable，30 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，细节里藏着真正的可用性。希望这份笔记能帮你在自己的客服系统里少走一点弯路，也欢迎一起交流更多“Java+AI”的实战经验。
