CASE 03 / ENGINEERING IN DETAIL
电销系统架构改造
在拆分单体的同时，处理锁竞争、超时和 OOM。
问题与约束
人工和机器人外呼持续迭代，原单体系统出现锁竞争、超时和 OOM。我主导服务拆分，开展 JVM、SQL、缓存和冷热数据优化。系统还采用并行坐席标签查询等机制。拆分服务时，需要保留原有业务规则，协调任务调度、配置和发布。
核心链路简化示意
以下图示为技术思路的简化表达。
- 01 / 业务受理人工与机器人外呼
- 02 / 规则校验禁呼、黑名单与限制
- 03 / 服务协作业务调用与任务管理
- 04 / 数据支撑缓存、查询与冷热分离
架构取舍与实现
拆分服务，保留原有业务规则
难点单体中多类职责相互影响，局部压力容易变成整体运行问题。
方案主导单体向微服务拆分，引入 XXL-JOB 与 Apollo 管理任务和配置。系统设有独立外呼校验服务，处理禁呼、黑名单、号码与次数限制。
考虑外呼校验与业务执行分别维护；服务拆分后的规则、异常返回和限制仍需逐项核对。
并行查询标签，保留部分结果
难点坐席标签依赖多个下游查询，串行等待与单项失败都会影响结果整理。
方案标签查询采用有界线程池和 CompletableFuture 并行获取下游结果；单项异常时，继续整理已有信息。
考虑多个查询可以同时执行，单项失败仍可返回已有信息；线程池容量限制并发规模，下游慢响应仍需检查。
分别处理内存、查询和数据量问题
难点锁竞争、慢查询和内存压力交织，单一参数调整难以覆盖所有问题。
方案围绕并发访问调整 JVM 参数，优化 SQL 索引与 Redis 缓存，并进行冷热数据分离，分别处理运行时、查询和数据规模问题。
考虑JVM、索引、缓存和数据拆分各有作用位置，需要在相近负载下分别观察，不能只凭一次响应变快判断整体效果。
这套设计解决了什么
完成服务拆分及任务、配置接入，并开展 JVM、SQL、缓存和冷热数据优化。
验证关注点
- 服务拆分前后的规则、异常返回和业务限制是否保持一致？
- 下游慢响应或单项失败时，线程资源与部分结果处理是否符合预期？
- JVM、SQL、缓存和冷热分离的调整，是否在可比较负载下验证？
我的职责
主导单体向微服务拆分，承担技术方案、核心开发和团队交付，协同产品、测试与运维处理迭代和线上问题。