很多团队在做外卖跑腿系统初期，往往只服务一个城市，商户数量有限，订单规模不大，使用单体应用加单库结构就可以顺利运行。
但当业务开始扩张后，问题会迅速出现。
城市数量增加，数据混在一起，查询变慢
商户变多，权限混乱，数据隔离困难
订单暴涨，数据库压力过大，系统频繁卡顿
这些问题本质上都来自一个原因：底层架构没有提前为多城市和多商户做设计。
一套真正可长期运营的外卖跑腿系统，必须从一开始就考虑三个核心能力：
多城市部署能力
多商户隔离能力
高并发处理能力
下面结合实际开发经验，从架构和代码层面拆解具体实现方案。
一、整体系统架构设计
推荐采用分层加微服务的结构，将核心能力拆分成独立服务，例如：
网关层
订单服务
商户服务
骑手调度服务
支付结算服务
城市管理服务
缓存与消息队列层
所有终端（用户端、骑手端、商家端、后台）统一通过网关访问后端服务。
这样拆分的好处是：
各模块职责清晰
可以独立扩容
单个服务故障不影响整体
更容易支持多城市部署
二、多城市部署实现方案
当业务覆盖多个城市时，最关键的是数据隔离。
如果所有城市共用一套数据库，订单量上来之后查询效率会急剧下降，同时也不利于独立扩容。
更合理的方式是按城市分库。
例如：
北京一个数据库
上海一个数据库
广州一个数据库
这样可以做到：
单城市独立维护
查询性能更高
扩容成本更低
故障互不影响
城市动态数据源切换实现
在 SpringBoot 项目中，可以通过动态数据源实现自动路由。
第一步，使用 ThreadLocal 保存当前城市标识。
public class CityContextHolder {
private static final ThreadLocal<String> CITY = new ThreadLocal<>();
public static void set(String city){
CITY.set(city);
}
public static String get(){
return CITY.get();
}
public static void clear(){
CITY.remove();
}
}
第二步，请求进入时通过拦截器识别城市。
@Component
public class CityInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String cityCode = request.getHeader("city-code");
CityContextHolder.set(cityCode);
return true;
}
}
第三步，实现动态数据源切换。
public class DynamicDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey() {
return CityContextHolder.get();
}
}
这样一来，同一套代码即可根据不同城市自动访问不同数据库，实现真正的多城市部署。
三、多商户管理实现思路
外卖跑腿平台本质是多商户入驻模式。
每个商家都需要独立管理自己的订单、商品、财务数据，因此必须采用多租户设计。
最简单可靠的方法是字段隔离，也就是每张核心业务表都带上 merchant_id。
例如订单表：
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
merchant_id BIGINT,
user_id BIGINT,
amount DECIMAL(10,2),
status TINYINT,
create_time DATETIME
);
所有查询都必须携带 merchant_id 条件。
自动注入商户ID
可以使用 AOP 在请求进入时自动写入商户上下文。
public class MerchantContext {
private static final ThreadLocal<Long> HOLDER = new ThreadLocal<>();
public static void set(Long id){
HOLDER.set(id);
}
public static Long get(){
return HOLDER.get();
}
}
@Aspect
@Component
public class MerchantAspect {
@Before("execution(* com.xxx.service..*(..))")
public void setMerchant() {
MerchantContext.set(LoginUser.getMerchantId());
}
}
查询时统一带入：
@Select("select * from orders where merchant_id = #{merchantId}")
List<Order> list(Long merchantId);
这样可以确保商户之间数据完全隔离，权限模型也更加简单清晰。
四、高并发订单处理优化
当订单量上来之后，数据库往往成为最大瓶颈。
正确做法不是提升硬件，而是引入缓存和消息队列削峰。
推荐组合：
Redis 负责缓存和库存控制
MQ 负责异步处理订单
数据库专注持久化
典型下单流程如下：
用户提交订单
Redis 校验库存
发送消息队列
异步创建订单
调度骑手
示例代码如下。
发送消息：
rabbitTemplate.convertAndSend(
"order.exchange",
"order.create",
orderDTO
);
消费消息：
@RabbitListener(queues = "order.queue")
public void createOrder(OrderDTO dto){
orderService.create(dto);
}
这种方式可以把瞬时高峰流量变成平滑流量，极大提高系统稳定性。
五、架构落地建议总结
如果希望系统具备长期可运营能力，建议从一开始就采用以下方案：
城市分库部署
商户多租户隔离
微服务拆分架构
Redis缓存加速
MQ异步削峰
容器化部署支持横向扩容
这样设计后：
新增城市只需增加数据库
新增商户无需改动架构
订单增长可直接扩容服务
系统可以稳定支撑长期发展，而不用反复重构。
外卖跑腿系统真正的竞争力并不是界面，而是底层架构是否能支撑规模化运营。
一套支持多城市、多商户和高并发的系统，才能帮助平台持续扩张和盈利。
如果你正在搭建或选型外卖跑腿系统源码，优先考虑是否具备以上架构能力，这比单纯的功能数量更重要。
