在复杂业务场景下的一次架构升级探索：从0到1重构系统的技术实战

背景与初心

我是一个在一线技术岗位摸爬滚打了十多年的开发者，现在是某中型互联网公司的技术负责人。我们公司主营在线教育服务，过去几年里用户增长迅速，产品线也越来越多，老系统开始显得捉襟见肘。

事情要从去年夏天说起，那时候我们整个系统的性能已经到了临界点，特别是在大课抢购和直播高峰期，经常出现请求延迟高、接口超时甚至服务崩溃的情况。虽然我们一直在通过横向扩容、缓存优化等方式维持着，但大家心里都清楚：这不是长久之计，必须做一次大的架构升级。

于是，我带着团队开始了为期半年的系统重构之路。这不仅是一次技术挑战，更是一场对“技术探索”和“工程实践”如何结合的深度思考。

这篇文章，我想用自己的视角，讲一讲这次重构的过程，遇到的问题，以及背后的思考和成长。

---

项目背景：一场危机引发的变革

我们的主系统最初采用的是单体架构，使用Java Spring Boot搭建，数据库用MySQL，前端是Vue + SSR渲染，部署在一个阿里云ECS集群上。

随着业务发展，问题逐渐暴露出来：

• 请求响应时间拉长，尤其在课程秒杀、活动促销期间
• 模块耦合严重，修改一个小功能容易牵一发动全身
• 部署流程复杂，一次全量更新需要停服
• 新人上手成本高，文档不齐，结构混乱

最糟糕的一次事件是在2023年暑假开学季的大促活动中，系统直接崩了两次，造成了严重的客户流失和品牌影响。

这场事故之后，公司决定立项进行系统架构升级，并由我来牵头负责。

---

重构目标与技术选型

目标明确：

1. 解耦系统模块，降低风险
2. 提升整体性能和可扩展性
3. 建立可持续迭代的开发流程
4. 提高系统可观测性和容错能力

技术路线选择：

模块	原方案	新方案	选择理由
架构风格	单体架构	微服务架构（Spring Cloud）	提升可维护性 & 可扩展性
网关	Nginx硬编码配置	Spring Cloud Gateway	支持动态路由、鉴权、限流等特性
注册中心	无	Nacos	开源成熟，社区活跃，支持服务发现/配置管理
数据库	MySQL单库	分库分表+读写分离	承载更大数据量和并发
缓存层	局部Redis应用	Redis集群 + Caffeine本地缓存	多级缓存提升性能
日志体系	无统一日志管理	ELK + Zipkin	实现全链路追踪和异常定位
CI/CD	Jenkins脚本	GitLab CI + Docker + K8s	自动化部署，提升效率

这个过程我们不是一拍脑袋定下来的，而是经过多轮技术评审和压力测试对比后确定的。比如我们曾经考虑过Go语言重写核心服务，最后综合人力成本、迁移难度和长期维护等因素，选择了继续以Java生态为主。

---

关键挑战与应对

在整个过程中，我们遇到了不少实际困难，下面是我印象最深刻的几个点。

挑战一：数据一致性如何保障？

微服务拆分后，原来一个事务操作变成了跨服务调用，这时候就会面临分布式事务问题。比如订单创建可能涉及库存扣减和账户余额变动。

我们一开始尝试用Seata框架，结果发现引入了太多运维成本，而且Seata本身在高并发场景下性能不太理想。

最终选择了**“柔性事务 + 最终一致”**的思路：

• 使用RocketMQ消息队列做异步处理
• 核心步骤用状态机控制业务流转
• 通过补偿任务兜底修复异常数据

这种方式虽然没有强一致性，但在实际场景中满足了业务需求，而且大大降低了系统复杂度。

挑战二：服务拆分粒度过细怎么办？

刚开始我们尝试将系统按业务维度拆分成几十个微服务，结果导致：

• 启动慢、调试繁琐
• 接口数量爆炸式增长
• 网络调用变多，延迟加大

后来调整为“先粗后细”的策略，将核心业务（如用户中心、课程中心、订单中心）作为主服务，非核心或低频模块仍保留在聚合服务中。这样保持了一个平衡，避免过度设计。

挑战三：旧系统中的历史代码难以迁移

这是最难啃的一块骨头。很多代码逻辑已经非常复杂，缺少单元测试，也没有文档说明。

我们采取了几种方式：

1. 编写契约文档：先梳理所有接口行为，形成API规范，方便后续替换。
2. 双跑策略：新旧系统并行运行一段时间，逐步切换流量。
3. 自动化测试：利用Postman+Newman构建基础接口回归测试集。
4. 白盒化改造：对关键模块进行重构，加上注释和指标埋点。

这部分花了整整三个月，几乎占了整个项目的三分之一时间。

---

技术实现细节分享

1. API网关限流策略配置（Spring Cloud Gateway）

spring:
  cloud:
    gateway:
      routes:
        - id: course-service
          uri: lb://course-service
          predicates:
            - Path=/api/course/**
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 100
                redis-rate-limiter.burstCapacity: 200
                key-resolver: "#{@userKeyResolver}"

配合自定义的 userKeyResolver 来根据用户ID做限流，防止恶意刷接口。

public class UserKeyResolver implements KeyResolver {
    @Override
    public Mono<String> resolveKey(ServerWebExchange exchange) {
        String userId = exchange.getRequest().getHeaders().getFirst("X-User-ID");
        return Mono.just(StringUtils.isEmpty(userId) ? "unknown" : userId);
    }
}

2. RocketMQ 异步通知示例（生产端）

public void sendOrderCreatedEvent(Order order) {
    Message<Order> msg = new Message<>("ORDER_CREATED_TOPIC", JSON.toJSONString(order).getBytes());
    try {
        rocketMQTemplate.convertAndSend(msg, null);
    } catch (Exception e) {
        log.error("发送订单消息失败", e);
        // 补偿机制入库
        eventStore.saveFailedEvent(order.getId(), "ORDER_CREATED", e.getMessage());
    }
}

消费端我们加了重试机制和幂等校验，保证即使消息重复也不会出错。

3. 多级缓存架构设计

public Course getCourseDetail(Long courseId) {
    // 先查本地缓存
    Course local = localCache.getIfPresent(courseId);
    if (local != null) return local;

    // 查Redis
    Course redis = redisTemplate.opsForValue().get("course:" + courseId);
    if (redis != null) {
        localCache.put(courseId, redis);  // 更新本地缓存
        return redis;
    }

    // 查数据库
    Course db = courseRepository.findById(courseId);
    if (db != null) {
        redisTemplate.opsForValue().set("course:" + courseId, db, 5, TimeUnit.MINUTES);
        localCache.put(courseId, db);
    }

    return db;
}

这套机制在压测中让课程详情页的访问耗时从平均 280ms 降到了 60ms。

---

遇到的坑和经验教训

坑一：Nacos注册延迟导致服务不可达

刚上线的时候，我们发现服务启动正常，但有些接口总是报503，后来发现是Nacos注册和健康检查之间存在延迟窗口，导致部分服务被错误地判定为可用。

解决办法：调整健康检查间隔和初始化延迟，在启动类加如下配置：

management:
  health:
    nacos:
      enabled: true
spring:
  cloud:
    nacos:
      discovery:
        metadata:
          version: 1.0.0
        health-check-delay: 5s

坑二：Zipkin采样率过高导致性能下降

为了监控调用链，我们接入了Zipkin，但默认采样率是1，导致大量日志写入ES，系统性能反而下降。

优化措施：设置合理的采样率，日常环境设为0.1，紧急时刻再开全量采集。

spring:
  zipkin:
    sleuth:
      sampler:
        probability: 0.1

坑三：Redis缓存雪崩

某个促销活动期间，由于大量缓存同时失效，导致数据库压力剧增，差点崩溃。

应对方法：

1. 设置不同缓存过期时间（在基础时间上增加随机值）
2. 引入本地缓存兜底
3. 设置缓存预热机制

---

结果与收益

重构完成后，我们做了详细的数据对比：

指标	上线前	上线后
页面加载平均响应时间	1.2s	450ms
订单创建QPS	180/s	1000/s
服务部署频率	每月一次	每周多次
故障隔离能力	不具备	良好
容错能力	差	支持熔断降级
日志可观测性	无	集成ELK、Zipkin

最直观的感受就是：研发效率大幅提升，线上报警明显减少，运维同学终于可以睡个安稳觉了。

---

我的经验总结

在这半年多的重构过程中，我学到了很多，也有一些感悟想跟大家分享：

1. 技术是手段，不是目的

永远不要为了新技术而用新技术。我们要解决问题，而不是去玩技术堆叠。

2. 平衡比完美更重要

重构不是推倒重来，也不是无限追求极致。要在质量、成本、进度之间找到平衡点。

3. 有文档≠文档有用

写文档不能光靠程序员自觉，要有规范、模板和强制机制。否则文档很快就会落后于代码。

4. 团队协作大于个人英雄主义

一个成功的系统依赖的是良好的分工、沟通和持续交付能力，而不是某一个人的“牛逼”。

5. 不要忽略运维的价值

架构做得再漂亮，如果没人懂怎么部署、监控、应急响应，那就是空中楼阁。

---

写给读者的话

作为一名老程序员，我深知每一次技术决策背后都需要承担不小的风险。但正是这些看似“艰难”的探索，让我们不断成长，也让系统真正变得强大。

如果你也在面对类似的技术升级或者架构优化，不妨参考以下几点建议：

1. 从小处切入，逐步推进：重构可以从最小的核心模块做起，验证效果后再推广。
2. 先做监控再做优化：不知道哪里慢，就别谈优化。
3. 拥抱变化，也要接受妥协：现实往往不如理论优雅，但实用才是第一要务。
4. 重视代码质量和工程规范：代码是写给人看的，偶尔给机器跑一下。

希望这篇文章能给你带来一些启发和帮助。技术路上，我们一起前行。

---

作者：阿杰（技术负责人）
来源：我的日常代码笔记
首发于 2025 年 4 月

---