代购转运系统的订单处理队列卡死、数据库连接数飙满，每次大促都像渡劫。去年决定彻底重构，思路就是八个字：解耦、异步、弹性、可观测。
重构方案
单体应用拆成 7 个独立服务，每个独立部署和扩缩。
services:
order-service:
image: registry.cn-hangzhou.aliyuncs.com/transit/order-service:2.3.1
deploy:
replicas: 3
resources:
limits:
cpus: '2'
memory: 4G
订单创建后不再同步调物流接口，走消息队列异步处理。高峰期消息积压量很大，但系统不会因此卡死。
def submit_order(order_data):
order_id = save_to_db(order_data)
client = AcsClient('access_key', 'secret_key', 'cn-hangzhou')
request = PublishMessageRequest.PublishMessageRequest()
request.set_TopicName('order-events')
request.set_MessageBody(json.dumps({
'order_id': order_id,
'user_id': order_data['user_id'],
}))
client.do_action_with_exception(request)
return order_id
弹性伸缩：平时少量 Pod，大促期间按 CPU 和 QPS 自动扩展，几分钟内完成扩容。
踩坑
连接池泄漏 — 有个接口异常时没正确归还连接，数据库连接数飙高。修完之后稳定多了。
分布式事务 — 代购转运涉及多币种支付、海关申报、国内物流，最初用两阶段提交性能太差。改成"本地消息表+定时补偿"，最终一致性延迟在可接受范围。
日志爆炸 — 微服务化后日志量太大，按天轮转、按需检索之后成本降了不少。
重构之后系统平稳扛住了后面几次大促，没有再出现订单队列卡死的情况。
做了十年电商后端，现在在做 taocarts 代购系统，涉及 1688 代购、多仓库协同、跨境支付这些方向。有问题欢迎交流。
