外卖跑腿系统平台多城市部署与多商户管理的实现思路

原创

万岳教育Lili

发布于 2026-02-02 15:07:43

1050

很多团队在做外卖跑腿系统初期，往往只服务一个城市，商户数量有限，订单规模不大，使用单体应用加单库结构就可以顺利运行。

但当业务开始扩张后，问题会迅速出现。

城市数量增加，数据混在一起，查询变慢商户变多，权限混乱，数据隔离困难订单暴涨，数据库压力过大，系统频繁卡顿

这些问题本质上都来自一个原因：底层架构没有提前为多城市和多商户做设计。

一套真正可长期运营的外卖跑腿系统，必须从一开始就考虑三个核心能力：

多城市部署能力多商户隔离能力高并发处理能力

下面结合实际开发经验，从架构和代码层面拆解具体实现方案。

一、整体系统架构设计

推荐采用分层加微服务的结构，将核心能力拆分成独立服务，例如：

网关层订单服务商户服务骑手调度服务支付结算服务城市管理服务缓存与消息队列层

所有终端（用户端、骑手端、商家端、后台）统一通过网关访问后端服务。

这样拆分的好处是：

各模块职责清晰可以独立扩容单个服务故障不影响整体更容易支持多城市部署

二、多城市部署实现方案

当业务覆盖多个城市时，最关键的是数据隔离。

如果所有城市共用一套数据库，订单量上来之后查询效率会急剧下降，同时也不利于独立扩容。

更合理的方式是按城市分库。

例如：

北京一个数据库上海一个数据库广州一个数据库

这样可以做到：

单城市独立维护查询性能更高扩容成本更低故障互不影响

城市动态数据源切换实现

在 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异步削峰容器化部署支持横向扩容

这样设计后：

新增城市只需增加数据库新增商户无需改动架构订单增长可直接扩容服务

系统可以稳定支撑长期发展，而不用反复重构。

外卖跑腿系统真正的竞争力并不是界面，而是底层架构是否能支撑规模化运营。

一套支持多城市、多商户和高并发的系统，才能帮助平台持续扩张和盈利。

如果你正在搭建或选型外卖跑腿系统源码，优先考虑是否具备以上架构能力，这比单纯的功能数量更重要。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

推荐系统

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

推荐系统

#外卖跑腿

#外卖系统

作者已关闭评论

0 条评论

热度