传统客服系统把对话、工单、知识库、用户画像全塞进一个 War 包，高峰期 2000 并发就把线程池打满；每次上线都要全量回归，一个短信模板改动就得整包重启；更糟的是，客服组想同时试用新语义模型，运维只能无奈地“等窗口”。
我们决定把这套“巨石”拆成微服务，用三个月完成从单体到云原生的改造，本文把踩过的坑、量过的数据、跑过的脚本全部摊开，给你一份能直接抄作业的落地笔记。
1. 背景：为什么一定要拆
- 扩展性瓶颈：单体混合了 IO 密集（WebSocket 长连接）与 CPU 密集（NLP 推理），无法独立扩容，导致白天客服坐席一多，后台模型推理就掉线。
- 迭代效率低：业务、算法、接口三团队共享代码库，一次发版平均 2.5 小时，回滚还要 40 分钟，客服主管吐槽“等你们发完，客户早走了”。
- 可用性脆弱：任何一段慢 SQL 都会把整站拖挂，去年大促因为一条忘记加索引的统计语句，直接丢了 30% 的对话。
2. 技术选型：Spring Cloud Alibaba vs Kubernetes 原生
在架构评审会上，两派 PK 激烈，最终用“团队技能 + 交付周期 + 后期运维”三维打分，结论如下表。
| 维度 | Spring Cloud Alibaba | Kubernetes 原生（Service Mesh） | 备注 |
|---|---|---|---|
| 学习成本 | 低（已有 Spring 背景） | 高（Istio、CRD、Helm） | 团队 8 成是 Java 出身 |
| 开发效率 | 高，注解即服务 | 中，需写 YAML 再写代码 | 首版上线时间定死 3 个月 |
| 服务治理 | Sentinel 直接集成 | Istio 流量治理更细 | 两者都支持熔断/限流 |
| 运维复杂度 | 中等（Nacos + Sentinel 控制台） | 高（多集群、多 CR） | 运维只有 2 名全职 |
| 云厂商绑定 | 弱，可迁云 | 强（EKS/ACK 差异大） | 未来可能多云 |
| 结论 | 选用 | 留作二期演进 | 先跑起来，再逐步 Mesh 化 |
一句话总结：先 Spring Cloud Alibaba 上车，半年后再把 sidecar 塞进去，业务不等人。
3. 领域拆分与服务依赖图
用领域驱动设计（DDD）把客服世界切成四大子域：
- 对话域（Chat）：负责 WebSocket 接入、消息上下行。
- 工单域（Ticket）：生成、派发、关闭工单。
- 知识域（KB）：语义检索、FAQ 匹配。
- 用户域（Uic）：客户资料、标签、权限。
依赖关系遵循“单向依赖”原则，Chat 可调用 Ticket，反之不行，避免循环耦合。PlantUML 如下：
@startuml package "对话域" { [chat-service] } package "工单域" { [ticket-service] } package "知识域" { [kb-service] } package "用户域" { [uic-service] } [chat-service] --> [ticket-service] : 创建工单 [chat-service] --> [kb-service] : 语义检索 [chat-service] --> [uic-service] : 查询客户标签 [ticket-service] --> [uic-service] : 查询坐席组 @enduml4. 核心代码落地
4.1 FeignClient + Sentinel 熔断示例
依赖先引入：
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency>Feign 接口：
@FeignClient(name = "kb-service", fallback = KbFallback.class) public interface KbClient { @GetMapping("/kb/match") List<Answer> match(@RequestParam String q); }熔断实现：
@Component public class KbFallback implements KbClient { @Override public List<Answer> match(String q) { // 返回兜底答案 return List.of(Answer.defaultAnswer()); } }Sentinel 规则可在控制台动态下发，也可代码硬编码做兜底：
# application.yml feign: sentinel: enabled: true4.2 PostgreSQL 分片策略
对话表按月分片，避免单表爆炸：
spring: shardingsphere: rules: sharding: tables: t_chat_message: actual-data-nodes: ds0.t_chat_message_$$->{2023..2025}0$$->{1..12} table-strategy: standard: sharding-column: create_time sharding-algorithm-name: month-inline sharding-algorithms: month-inline: type: INTERVAL props: datetime-pattern: yyyy-MM-dd HH:mm:ss datetime-lower: 2023-01-01 00:00:00 datetime-upper: 2025-12-31 23:59:59 sharding-suffix-pattern: yyyyMM5. 性能验证：JMeter 压测数据
环境：4C8G Pod × 10，模拟 5000 长连接，持续 15 min。
| 指标 | 单体旧系统 | 微服务新架构 |
|---|---|---|
| 峰值 QPS | 2200 | 6800 |
| 99% RT(ms) | 1200 | 280 |
| 错误率 | 3.2% | 0.15% |
| CPU 利用率 | 92% | 55% |
结论：拆完后同样硬件，吞吐提升 3 倍，长尾延迟下降 76%，客服坐席反馈“机器人反应明显快了”。
6. 避坑指南
6.1 Nacos 热更新陷阱
现象：修改sentinel-flow-rule.json后，业务 Pod 未实时生效。
根因：Nacos 的@RefreshScope只支持.properties，而 Sentinel 用 JSON 格式。
解决：把规则写进yaml并开启spring.cloud.sentinel.datasource.nacos.data-id=flow-rules.yml，同时把 JSON 转成 YAML 列表，让@ConfigurationProperties一次性刷新。
6.2 分布式日志追踪的 MDC 污染
现象：同一线程调用链上，TraceId 中途被覆盖，ELK 查不到完整链路。
根因：Hystrix 线程池隔离 + 线程复用，MDC 基于 ThreadLocal。
解决：
- 改用 Sentinel 信号量隔离，减少线程切换。
- 自定义
RunnableWrapper，在提交线程池前复制 MDC。 - 日志模板统一
%X{traceId}，并给运维加一条“日志不完整即事故”的红线。
7. 灰度发布方案（生产验证）
- 在 Dockerfile 里把版本号注进镜像 label，例如
v1.3.0-gray。 - 利用 Ingress-Nginx 的
canary-by-header=gray，让内部坐席先行体验。 - Prometheus 对比新旧版本“平均响应时间”“熔断次数”，指标劣化 >5% 自动回滚。
- 48 小时后无异常，全量切流，灰度结束。
8. 小结与开放讨论
三个月里，我们把“巨石”拆成 11 个微服务，QPS 提升 3 倍，发版从 2.5h 缩到 15 min，客服满意度上涨 18%。但新问题来了：当一次对话需要同时修改对话状态、工单优先级、知识库统计、用户标签时，跨 3 个以上微服务的事务一致性怎么保证？
TCC、Saga、还是干脆把状态收敛到独立的状态机服务？欢迎在评论区聊聊你们的实践。
当对话状态管理需要跨 3 个以上微服务时，如何保证事务一致性？
