从踩坑到成长：我的技术探索与优化实践之路

我是一名有着多年经验的后端开发工程师，目前在一家中型电商公司担任架构师。我们的系统是一个典型的高并发、分布式电商系统，核心业务包括商品展示、下单、库存扣减、支付回调、订单履约等。今天想和大家分享一段我在实际工作中经历的技术探索与优化过程，希望通过这篇文章能让大家少走一些我曾经踩过的坑。

背景介绍：为什么需要一次深度重构？

2022年底，我们迎来了公司一年一度的“双十一大促”，这是我们最重要的营销节点之一。但这次活动结束后，我和团队发现了一个严重的问题：系统稳定性下降明显，尤其是在大促期间，出现了大量订单超时、接口慢、甚至服务雪崩的情况。

为了提升用户体验和保证后续类似活动的稳定性，技术负责人决定进行一次全链路优化，目标是：

• 提升接口响应速度（尤其是订单创建和库存扣减流程）
• 减少系统耦合
• 增强系统的容错性和可维护性
• 为后续业务扩展预留空间

我负责的模块正好是订单服务，也是整个链路中的关键一环，自然就成了改革的重点对象。

问题描述：性能瓶颈在哪？

我们先来看一下当时订单服务的基本架构：

1. 订单创建请求首先会经过一个网关层；
2. 网关将请求打到订单微服务；
3. 订单服务内部调用库存服务做预占；
4. 调用优惠券服务做优惠计算；
5. 生成订单后写入 MySQL，并发送消息到 Kafka；
6. 最终由下游消费者异步处理履约逻辑（如推单、物流同步等）。

表面上看这是一套标准的分层结构，但在实际运行中却暴露了多个问题：

问题一：服务间调用阻塞严重

在订单服务里，调用库存服务和优惠券服务时采用了同步阻塞方式，而且没有做降级或超时处理。一旦其中一个服务响应慢，整个订单流程都会被拖累，甚至导致线程池耗尽。

问题二：数据库瓶颈明显

使用 MySQL 作为主数据源，订单表设计不合理（没有水平拆分、缺少索引），加上高峰期订单量暴增，在大促时段频繁出现“Lock wait timeout exceeded”异常。

问题三：日志埋点混乱、链路追踪缺失

当时日志记录杂乱无章，缺乏统一的日志格式和 traceId，导致出现问题难以定位。虽然接入了 SkyWalking，但由于初期配置不规范，很多关键链路无法还原。

问题四：业务逻辑耦合严重

例如在订单创建过程中，我们嵌入了很多业务规则判断，比如限购策略、会员折扣、预售逻辑等等，这些都糅杂在同一个类里，代码臃肿、改动风险极高，每次上线都要提心吊胆。

解决方案：如何一步步优化升级？

面对这些问题，我和团队制定了几个核心方向：解耦、缓存、异步、监控、压测验证。以下是具体的实施过程。

一、服务间通信改造：引入 Feign + Resilience4j 替代 Retrofit + Hystrix

我们之前使用的是 Retrofit 作为 HTTP 客户端，搭配 Netflix 的 Hystrix 做熔断，但后来发现 Retrofit 的同步调用模式限制了并发能力，而 Hystrix 已经进入维护状态，社区活跃度低。

因此我们改用 Spring Cloud OpenFeign + Resilience4j：

@GetMapping("/deduct")
@CircuitBreaker(name = "inventoryService", fallbackMethod = "fallbackInventoryDeduct")
@Retry(name = "inventoryService")
public ResponseEntity<Boolean> deductStock(@RequestParam String skuCode, @RequestParam int quantity);

这套组合不仅支持更灵活的熔断策略，还可以通过 Retry 进行重试，大大提升了对外调用的健壮性。

Tip：Resilience4j 支持基于配置中心动态调整熔断阈值，非常适合用于生产环境。

同时我们也将部分非关键路径的调用改为异步执行（如优惠券领取信息上报），减少主线程阻塞时间。

二、数据库优化：读写分离 + 拆分策略初步尝试

针对数据库瓶颈，我们做了以下几件事：

1. 引入读写分离中间件（ShardingSphere）

我们将原来的单一 MySQL 实例拆分为“一主多从”的结构，所有查询操作走从库，写操作走主库。通过 ShardingSphere 的配置，几乎不需要修改业务代码就完成了迁移。

2. 慢 SQL 分析与优化

我们借助 SkyWalking 抓取所有耗时超过 500ms 的 SQL，逐一进行分析。发现有以下几个常见问题：

• 查询未走索引
• 使用了 LIKE %xxx% 导致全表扫描
• 大批量写入事务过长

我们对这些 SQL 做了重写和索引补充，并且将某些历史订单的查询独立出来，通过定时任务归档到 ElasticSearch，避免影响主库压力。

3. 初步尝试水平拆分（ShardingKey）

对于订单表，我们采用了以用户ID为Sharding Key的方案，将一张表拆成4张，降低了单表容量和锁竞争的概率。虽然不是彻底的分库分表，但已初见成效。

三、引入事件驱动架构：让订单流程更健壮

原来我们采用的是直接写入 MySQL 后再发 Kafka 消息的方式，这种方式在极端情况会导致“数据写成功但消息没发出去”，从而产生一致性问题。

于是我们引入了一个简单的事务消息机制，结合本地事务表来保证消息可靠投递。大致流程如下：

1. 写入订单数据前，先插入一条事务消息记录；
2. 插入订单主表数据；
3. 如果都成功，则标记事务消息为可消费状态；
4. 另外一个定时任务检查未完成的消息并重新推送。

当然这还不是 RocketMQ 或 Kafka 的事务消息机制，但我们根据当前阶段的业务需求选择了轻量实现。

四、日志规范化 + 链路埋点增强

我们对所有的日志打印进行了规范化处理，定义了统一的格式模板，包含：

• traceId（来自 MDC）
• 方法耗时
• 用户 ID
• 请求来源 IP/ua

同时打通了 SkyWalking 和业务日志，方便快速定位问题。

此外，我们在关键入口（如 Controller 层）增加了 logback 的拦截器，自动生成 traceId 并注入到 MDC 上下文中，这样就能实现在同一个请求中贯穿所有日志输出。

五、功能抽象 + 业务规则引擎化尝试

为了避免每个版本都因为新规则导致代码膨胀，我们开始尝试使用 Drools 规则引擎。

举个例子：订单创建时，需要校验用户是否参与限购、是否符合满减条件、是否满足特定会员等级等。

以前这些判断都硬编码在 service 中，现在我们抽离出 rule 目录，每个规则对应一个 .drl 文件，由规则组维护。

这样做的好处：

• 开发人员只需关注规则执行流程
• 业务人员可以配合规则配置，降低沟通成本
• 新规则添加更加灵活，不需要频繁上线

缺点也存在：规则复杂后调试困难，表达式容易写错。所以我们还在不断完善规则测试工具和规则模拟器。

效果总结：优化前后对比

指标	优化前（平均）	优化后
下单接口响应时间	800ms~1.2s	300ms以内
订单服务CPU负载	接近100%	降至40%-50%
日均错误日志数	500+	少于30
故障定位时间	1小时左右	5-10分钟内
线上发布变更失败次数	每月2次以上	保持稳定
新业务规则上线周期	至少一周	3天以内

整体来看，这次优化带来了明显的性能提升和服务质量改善，也为后续承接更大流量打下了基础。

经验分享：给同行的一些建议

1. 架构演进要匹配业务发展阶段

不要盲目追求“先进架构”，比如一开始我们就想着搞微服务、搞 DDD，结果发现业务还没发展到那个阶段，反而让事情变得更复杂。合适的架构永远比先进的架构更重要。

2. 监控是优化的前提

你不可能凭空做出一个高效稳定的系统，只有通过数据反馈才能知道哪里出了问题。所以一定要建立好日志、链路、指标采集体系。推荐组合：SkyWalking + Prometheus + Grafana + ELK。

3. 性能优化不能脱离真实场景

有时候我们会陷入“为了优化而优化”的误区。比如对某个函数做极致的 CPU 节省，但其实它在整个链路中占比极低，意义不大。建议先用 APM 找到真正的瓶颈点再去下手。

4. 技术债要及时还

我们最初忽视了一些小细节，比如日志不规范、没有 traceId、接口没有降级策略，结果到了关键时刻这些都成了绊脚石。别低估技术债的成本，越早清理越好。

5. 多动手，少争论

技术选型很重要，但很多时候讨论半天也难有结论。不如写个 PoC（Proof of Concept）跑起来看看效果。亲自动手才是最真实的评估方式。

---

结语：每一次优化都是成长的机会

回顾整个优化过程，说实话很辛苦，特别是在项目上线前后，几乎天天加班赶进度。但也正因为那次项目的锤炼，让我对系统设计、技术选型、协作沟通都有了更深的理解。

技术本身并不难，难的是如何在一个不断变化、资源有限的环境中，持续地交付高质量的系统价值。

如果你也在经历类似的挑战，请相信一点：每一次的优化、重构、甚至是失败，都是通往更好架构的关键一步。坚持下去，一定会看到改变。

希望这篇经验分享对你有所启发。如果有任何问题或者想法，欢迎留言交流！