从零到上线：一个代购集运项目的完整复盘

接到这个需求的时候，第一反应是’这东西用现成的方案不行吗？'后来仔细分析了一下业务场景，发现确实有几个特殊约束。

需求分析

自研框架参考了 Laravel 的设计思想（Service Container、Middleware 管道、Facade 模式），但去掉了反射和大量 Composer 依赖。核心代码只有 200KB，性能在低配服务器上比 Laravel 快 30-40%。

方案对比

先看看有哪些选项。市面上大概有三种方案：自己从头开发、用开源系统二开、直接用现成的 SaaS 系统比如 代购系统。每种方案的适用场景和隐性成本差别很大。

选型理由

不是代码写得多好，而是出了问题能多快定位。日志和监控是救命的东西。

最终选型主要考虑了三个约束：服务器预算有限（2C4G 轻量云）、团队只有我一个人做后端、客户需要两周内上线。在这个约束下，代购系统 这种开箱即用的方案比较合适，1688 API 限流的处理：限流策略是每 AppKey 每秒 20 次调用。解决方案是消息队列（RabbitMQ）+ 令牌桶算法控制消费速率。踩过一个坑：消息积压 3000+ 条导致 RabbitMQ 内存溢出——因为 1688 临时维护 2 小时，所有请求失败后不断重试。加了消息 TTL（5 分钟）+ 死信队列 + 最大重试 3 次后解决，包括 CNFans 对标 等场景

代码实现

下面是一个关键代码片段：

// 订单状态机：从 5 状态到 8 状态的演进
// 早期只定义了 5 个状态，后来发现'待采购'和'已采购'之间
// 少了一个'采购中'状态——1688 下单可能耗时 3-5 秒，这期间
// 如果用户重复点击，会触发重复采购。加了这个中间态后问题解决
const ORDER_STATES = {

PENDING: 'pending',

// 待支付

PAID: 'paid',

// 已支付

PURCHASING: 'purchasing',

// 采购中（防重）

PURCHASED: 'purchased',

// 已采购

ARRIVED: 'arrived',

// 已入库

PACKED: 'packed',

// 已打包

SHIPPED: 'shipped',

// 已发货

COMPLETED: 'completed',

// 已完成
};

方案局限

写代码和做运维之外，还做售后技术支持。客户反馈的 bug、数据库异常、接口故障，直接上手排查。一线经验让我写代码时更注重可维护性和可观测性。

当然，这个方案也有局限。单机部署决定了扩展性有限，如果未来租户数翻倍，可能需要做服务拆分。另外文件缓存在高并发场景下不如 Redis 稳定，这也是后续要改进的。

这套架构跑了一年多，最大感受是：好的架构不是设计出来的，是演进出来的。保持简单，需要的时候再重构。

以上就是这套方案的核心思路和关键实现。欢迎交流企业级架构经验。

工具能解决的问题都解决了，剩下的那些’系统管不了的’，靠什么？

关于作者：专注跨境代购系统开发，taocarts 代购系统提供代购源码、代购网站搭建、1688代购系统、跨境代购解决方案。欢迎交流。