工单系统重构实战：绞杀者模式与灰度上线的五个月复盘

3月3日0点04分，我站在会议室里盯着投影上的监控大屏。切流后第一张真实工单进来了，创建耗时1.2秒——老系统平均只需450毫秒。监控群里连着弹出三条告警，测试同事发来一个问号。那一刻我脑子里的念头是：要不要马上回滚？紧接着第二个念头是：再等等，第一张工单是冷启动，数据说明不了任何问题。

回头想，这个项目从2025年10月立项，到2026年3月3日凌晨正式全量上线，前后正好五个月。中间跨了一个春节，压缩了至少三周有效开发时间。上线后两周，工单平均处理时长从老系统的8.6小时降到4.1小时，SLA达标率99.2%，系统可用性99.98%。但过程远没有这些数字看上去那么顺利。

这篇总结不是给自己表功的。我把这五个月里真正花掉精力的事情、上线当晚踩到的三个坑、以及事后复盘觉得“如果早想到就不会这么被动”的点，全部摊开说。如果你正准备做一次体量相近的系统重构或升级上线，这份记录应该能帮你少走几条弯路。

1. 这个项目为什么要在这个时间点动工

1.1 老系统到底卡在了哪里

我们重构的对象是一套从2018年跑到现在客户服务工单系统。六年下来，单体应用里堆了三百多个Controller、五百多个JSP页面，一张工单主表里躺着九千多万条数据，业务字段超过两百个。功能上什么问题都能干，但每一个问题都干得不利索。

最明显的痛点有三个。第一，响应速度。上下班高峰期工单创建接口的耗时经常飙到1秒以上，客服点一下“提交”要转两三个圈圈。第二，发版难。每周一次发版，光打包部署就要耗掉一个下午，改一行代码要回归整个系统，因为谁都不敢保证这行改动不会把某个八竿子打不着的模块搞挂。第三，业务扩展没空间。2026年公司要推智能客服策略，工单要根据客户等级、问题类型、当前坐席负载自动路由，老系统的规则都埋在if else里，根本改不动。

1.2 为什么选择绞杀者模式而不是推倒重来

项目启动时，团队内部吵过一轮：是直接新写一套系统把老系统替换掉，还是用绞杀者模式慢慢切？

“推倒重来”听起来很痛快，但我们算了一笔账：老系统承担着全部客服业务，没有并行运行的时间和成本；九千多万条历史工单数据迁移不完就会有客服查不到单；新系统上线第一天就要扛住所有业务流量，一旦出问题连回退的余地都没有。吵了三天，最后统一意见：采用绞杀者模式。老系统继续跑核心流程，新系统先接工单创建、智能路由、消息通知这三个最痛的模块，通过网关按客户号灰度切流，逐步把流量从老系统迁到新系统。

这个决策是整场项目里最重要的一个决策。虽然后面上线当晚出了不少幺蛾子，但因为老系统全程在旁边兜底，我们任何时候都能一键回退。

1.3 另一个关键决策：不用分布式事务

工单业务涉及创建、分配、处理、转派、关闭等多个状态流转，中间还要扣减SLA计时、发通知、写操作日志，跨了四五个服务。第一个版本我们差点引入Seata做分布式事务，后来仔细看了业务场景，发现工单流转根本没有强一致需求——一张工单状态短暂不一致，隔几秒自动纠正，客服感知不到，客户更感知不到。

所以我们定了一个原则：核心状态变更用本地事务保证，跨服务的数据一致性全部走RocketMQ事务消息加消息表兜底，配合定时对账任务。这个决定让架构少了一大截复杂度。分布式事务这东西，业务量没到那个级别，引入它纯粹是给自己找麻烦。

2. 重构范围与选型复盘：哪些决定上线后证明是对的

2.1 模块边界怎么切

系统拆成了五个中心：工单中心、客户中心、路由中心、消息中心、报表中心。每个中心独立部署、独立数据库实例。这个拆分在后期帮了大忙——每个团队只管自己那摊子事，改工单中心的代码不需要通知消息中心的同事。

唯一没拆开的是报表中心。九千多万条历史数据，不可能在业务库里跑聚合查询。我们的方案是：业务库加一个只读从库，报表中心直接连从库，复杂报表走异步任务，结果落到ES里。上线后发现这个方案性价比极高，报表查询秒出，业务库一点压力都没有。

2.2 选型清单和当时的判断逻辑

技术选型这个事最怕跟风。我们的思路很单纯：团队里谁最熟就用什么，不在项目期间学新技术。

为什么不选Kafka？工单消息量其实不大，一天也就几十万条，Kafka的高吞吐优势根本用不上。RocketMQ的按Tag过滤、事务消息、定时消息这几个功能反而跟我们场景高度匹配。从团队熟悉度来看，没人玩过Kafka，RocketMQ好歹有两年的使用经验。选型不是选最强，是选最适合的。

2.3 前端团队的重构思路

前端这块也同步推倒重来了。老系统用的是JSP + jQuery，这次整体切到Vue 3 + TypeScript + Element Plus，前后端完全分离。组件库选了Element Plus是因为团队之前有Vue 2 + Element UI的基础，迁移成本相对可控。

前端最花时间的地方不是页面开发，而是接口契约对齐。前后端两个团队并行开发的时候，我们推行了OpenAPI 3.1规范，后端先定义好接口文档，前端拿文档直接开Mock。上线前两个月，前后端联调的时间压缩到两周，这个契约驱动模式功不可没。

3. 上线前三个月的排期与工程治理：真正花时间的事情

3.1 并行开发下的依赖管理

五个中心并行开发，最怕的是接口互相等待。我们的做法是：第一周就把模块间的依赖契约全部定死，包括接口路径、请求参数、响应结构、错误码规范。每人一份契约文档，谁改动谁通知，变更必须通过评审。

这套流程看起来官僚，实际上救了我们很多次。有一次路由中心要给工单中心增加一个“坐席繁忙标志位”，因为契约文档写了，他们在开发环境自测时就发现了工单中心还没实现这个字段，而不是等到联调才炸锅。

3.2 环境治理：项目里最不被重视却坑最深的环节

测试环境这件事，说出来都是泪。我们五条业务线共用一套K8s集群，Nacos命名空间没有物理隔离，经常出现A组改了个配置，B组服务全部重启的诡异问题。有段时间工单中心在测试环境反复启动失败，查了两天才发现是消息中心的人把共享命名空间里的数据源配置改掉了。

后来我们专门排了一个人做一个星期的环境治理：每个中心一套独立的Nacos命名空间，配置文件全部用环境变量注入，数据库连接串不允许写在配置中心明文里。这个动作做完，整个测试阶段的开发效率至少提升两倍。建议所有项目在启动第一周就把这件事干完，不要等到踩坑再补。

3.3 自动化回归：数据对比是重构项目的老大难

重构项目的最大风险不是新功能写不出来，而是老功能被改坏了。老系统光接口就有两百多个，人工回归的代价根本承受不起。我们花了三周时间，把老系统2019年以来的线上真实请求采样了四万条，做成回归用例集，新系统启动后逐条回放比对响应结果。字段级不一致的自动diff，diff出来的差异再人工确认是有意变更还是代码bug。

这套方案帮我抓到了至少二十个隐藏很深的兼容性问题。比如老系统允许工单状态从“已关闭”直接改到“处理中”，新系统如果严格按状态机来，就会拒绝这个操作。但这种操作在现实业务里就是存在，客服偶尔需要翻案。我们的路由逻辑里就有这么一条状态回调的分支，要不是回归测试抓到，上线后一定会被投诉到爆。

3.4 数据迁移与双写方案

九千多万条工单数据，迁移占用了一整个里程碑。我们没有做一次性全量迁移，而是选了双写方案：老系统写入数据库成功后，通过监听binlog实时同步到新系统数据库；存量数据先做全量迁移，再配合增量binlog回放补齐。

这个方案看着简单，实际磨人的是对账环节。每天写对账脚本，统计老库和新库的数量差异、关键字段差异。前两周每天都有几千条对不上的数据，基本都是类型转换问题——老库的tinyint存的是0和1，新库字段改成了字符串类型；老库的时间字段存的是Datetime，新库统一改成Timestamp。这类细节在数据量小的时候根本发现不了，一旦上了亿级数据，全部暴露出来。

4. 灰度发布与演练：把上线日变成一次可重复执行的剧本

4.1 灰度梯队的设置逻辑

新系统刚上线就要全量接流量，这是大忌。我们设计了三个梯队：第一梯队内部员工，五十个客服账号先切过去，跑三天；第二梯队VIP试点客户，人工挑选了二十家合作紧密的客户，切过去跑一周；第三梯队全量。

内部员工这一梯队最有价值。客服人员是最了解业务细节的人，工单创建、流转、转派这些操作一条龙跑下来，有问题当天就能反馈到开发群。我们内部试用第一周就收到了三十七条反馈，其中一半是体验问题，另外一半是真bug。比如工单附件上传超过10MB超时、手机端工单列表下拉刷新时会偶现白屏，这些问题如果没有内部员工试用，直接上到客户那里就是事故。

4.2 流量灰度怎么做

网关层的灰度规则我们用客户号做哈希分片：客户号尾号匹配灰度名单的流量走新系统，其余流量继续走老系统。名单放在Nacos配置中心，改个配置就能调整灰度比例，不用重新发布网关。

灰度比例的控制逻辑写成配置文件大概是这个样子：

yaml复制gray:
  enabled: true
  # 按客户号尾号灰度，取值范围0-99
  ratio: 10
  # 命中的尾号区间，比如10%流量时取0-9
  includeTailRange: 0-9

这个方案配合Nacos的长轮询生效机制，理论上配置发布后5秒内就能完成灰度策略切换。实际用下来，因为有些客户长连接的存在，完全生效要一两分钟，但比重新发版效率高得多。上线当晚我们就是靠这个配置中心在1分钟内实现了新老系统流量互切。

4.3 演练把问题逼出来了

正式上线前两周，我们做了三次全链路压测和两次故障演练。

压测暴露的问题主要集中在数据库连接池和RocketMQ消费端并发。最极限的一次，模拟了晚高峰两倍流量，工单创建接口的P99延迟在1000TPS时飙到2.8秒，排查了一圈发现是工单中心的数据库连接池只配了20个上限，MySQL最大连接数配置也跟着不够，线程都在排队等连接。

故障演练更刺激。我们人为杀掉了路由中心的Pod，看看消息中心、工单中心会不会雪崩。结果消息链路Broker堆积告警响了，但服务没有挂，Sentinel限流规则起了作用，把超标的请求直接降级到一个提示页面，没有拖垮下游。演练完之后，我们给所有核心接口都补了降级兜底逻辑，包括一个“就算路由中心全挂，工单也能直接进入默认客服组”的开关。

演练那天还发现了一个特别尴尬的问题：告警的钉钉群已经建了，但告警规则没有配置通知人。监控面板上红成一片，手机上一个消息都没收到。这个低级错误要不是演练暴露出来，上线当晚我们估计要盯着屏幕盯到天亮。

5. 上线日全记录：从切流到稳定，三次意外与排查链路

5.1 0点切流：预想中最难的部分其实最顺

上线窗口定在3月3日0点到4点，这个时间段业务流量最低，出了问题影响面可控。0点整，运维执行切流脚本，把网关层灰度比例从0调整为10%。0点04分，第一张真实工单进入新系统，就出现了开头说的那一幕——创建耗时1.2秒。

1.2秒的原因我们当时就有预判：新系统刚从镜像启动起来，JVM需要预热，MyBatis-Plus的SQL缓存、Redis缓存全是空的，数据库连接池是懒加载的，第一次请求要建立二十个连接。纯粹是冷启动问题，不是代码bug。

处理方案是加了一个启动预热脚本，在服务真正接流之前，主动调用一批核心接口，把缓存和连接池全部预热到位。

bash复制#!/bin/bash
# 服务启动后执行预热，再开始接收流量
sleep 15
for endpoint in "/api/ticket/create" "/api/ticket/list" "/api/customer/info" "/api/router/strategy"; do
  curl -s -X POST "http://localhost:8080${endpoint}" \
    -H "Content-Type: application/json" \
    -d '{"warmup": true}' > /dev/null 2>&1
done
echo "warmup complete"

这个脚本加完之后，我马上用模拟数据测了一轮：新进程从启动到接口响应恢复到300毫秒内，只需要20秒预热时间。上线后的第二波切流就没有再出现响应时间飙高的情况。

5.2 早晚高峰的OpenFeign线程池打满事故

切到10%流量的第二天早高峰，监控告警突然开始刷屏：工单中心的openfeign线程池活跃线程数打到上限。点进详情页看，工单列表接口报了大量503，路由中心调用超时。

当时我们的第一反应是“路由中心是不是扛不住了”，赶紧去看路由中心的CPU和内存，结果指标都在正常范围。当时我有点懵，直到把链路上的调用关系捋清楚了，才意识到问题不在路由中心，而在工单中心自己。

排查链路是这样的：告警从工单中心的Prometheus指标开始，发现openfeign的active-connections飙到500+，紧接着看依赖的下游服务，每个服务的响应时间都正常。再往上游查，发现工单列表接口接收了一个请求参数，从消息中心回查，这个参数会导致一次查询工单全量字段。也就是说，工单中心在列表页把每一条工单的所有字段都捞出来了，包括几个TEXT类型的大字段，每条工单光序列化就要消耗好几毫秒，线程全部卡在JSON序列化和IO读写上。

根因找到以后，修复方案很简单：列表接口只返回必要字段，大字段走详情接口查询，分页大小从50限制到20；同时给OpenFeign的线程池上限调大了三倍。这个教训给了我一个强烈提醒：排查性能问题的时候，永远先从自身服务找原因，不要一上来就甩锅给下游。

5.3 定时任务双跑导致重复短信

上线第三天发生了一次P2级事故：部分用户收到了重复短信。客服部门的投诉电话被打爆，说客户投诉“同一个工单提醒收到了三遍”。

排查这件事花了四十分钟，链路是这样的：

第一步，查看短信发送记录。消息中心查出来的结果让所有人愣了一下——同一条工单ID对应三条发送记录，但biz_id完全相同。大概率是上游重复投递。

第二步，检查消息消费逻辑。RocketMQ默认消费模式是集群消费，同一个消费组里多个消费者只会有一个收到消息。按理说不会重复消费，除非消费端代码做了重复提交。代码review了几遍，没有发现问题。

第三步，查定时任务。翻服务日志的时候发现消息里带了消息来源标识，有些消息的来源是“scheduled-task-sync”。一查才发现，老系统的定时任务脚本还挂在生产环境的crontab里，每天凌晨会跑一次，把当天的工单状态同步到数据仓库，同时触发一次短信提醒。我们的新系统在工单状态变更时已经发过一次消息了，老系统的同步脚本又触发一次，再加上消息中心做了一次重试补偿，同一个客户收到三条短信就不奇怪了。

修复方案：

1. 下线老系统的定时任务脚本，保留数据同步任务但禁止发消息；
2. 在短信发送逻辑里增加幂等校验——同一工单ID同一状态24小时之内只允许发一次；
3. 把RocketMQ消费端的确认机制改成手动确认，防止偶发重试导致重复。

踩完这个坑，我特意把“新老系统并存期间的定时任务清单”整理成一份表格，凡是老系统还在跑的定时任务，全部列出来，逐条确认是否需要保留、是否需要去重。这个表后来成了我们运维交接的核心文档之一。

6. 上线两周后的稳定性观察与团队沉淀

6.1 数据对比：重构到底值不值得

上线两周后，我从监控和业务侧拉了三个维度的数据来做前后对比：

从业务侧来看，最直观的变化是工单平均处理时长直接砍半。原因是新系统的智能路由能根据客户等级和问题类型自动匹配客服组，不再需要客服经理人工派单，光这一点就节省了大量时间。

技术侧的变化更明显。老系统发一次版要提前半天申请变更窗口，新系统走云原生流水线，分支合并后自动构建、自动跑测试、自动部署，平均20分钟完成一次上线。团队交付效率的提升是重构最容易被低估的价值。

6.2 如果重来一次，我会提前做的事

复盘会开了三个小时，收获最多的是下面这几条：

第一，环境隔离必须从第一天做起。我们在环境治理上花了一周时间，这一周的成本如果提前到项目第一周，整个开发期的效率会高很多。一开始图省事共用一套环境，后面付出的代价远远大于省下来的成本。

第二，契约文档的变更管理要更严格。这次虽然没有因为接口变更出大事故，但中间有几次联调扯皮都是因为一个团队改了接口没同步文档。如果下次做类似项目，我会把接口变更和代码评审绑定在一起，代码不通过评审，接口文档不允许更新。

第三，上线日的人力安排要更合理。当天晚上我们安排了十二个人值守，结果真正出力的只有三个——两个后端加一个运维。大部分人在会议室里干等，出了事故才被叫起来看日志。下次我会把值守团队分成两拨：核心处置组一拨负责排查代码和日志，保障支持组在后方待命，有问题通过电话远程支援，没必要所有人都守在现场。

6.3 上线手册和值班SOP的价值

这次项目结束后，团队沉淀了一套上线手册，内容涵盖：

• 新系统组件清单、版本号、配置项说明；
• 灰度策略修改的标准操作流程；
• 定时任务完整清单（哪些能停、哪些必须保留、哪些做了幂等）；
• 三类常见故障的应急处置SOP：接口超时、消息堆积、缓存击穿；
• 回滚的一键执行脚本说明和回滚后的数据校验步骤。

这套文档的价值在六月份一次版本升级时得到了验证。当时代码发布后某个旧版本不兼容，我们按SOP执行了回滚，从发现异常到完全恢复，一共用了九分钟。如果没有这套标准流程，至少得花半小时在翻文档、问人、试操作这些环节上。

经历过这次上线，我个人在项目管理层面最大的变化是：不再迷信“上线时全神贯注就能避免故障”，而是相信“提前把不必要的人为决策从流程里移除，故障才会真正减少”。上线日晚上的意外，没有一个是靠临场发挥解决的，全部是靠预案、演练和监控提前框住了边界。反过来说，那些没写进预案的情况——比如新老系统定时任务双跑——恰恰就是真正会搞出P2事故的地方。

如果你也在准备一次类似体量的系统上线，我建议你多花点时间做两件事：把灰度切换方案写到能一键执行的程度，把新旧系统并存期间的所有自动化任务列清楚。前者决定你出问题时能多快收手，后者决定你会不会在不知情的情况下自己给自己埋雷。其他的，交给监控和复盘去解决，总不会太差。