社区外卖系统实战开发指南：从架构设计到部署上线

社区外卖系统实战开发指南：从架构设计到部署上线

社区外卖与普通外卖的区别在于“后一公里”的履约半径更短、配送时效更高，同时往往叠加了代取快递、上门家政、跑腿购物等本地生活服务。整套系统不再是简单的“用户下单→商家出餐→骑手配送”线性链路，而是围绕社区场景构建的多角色、多业务类型的协同平台。本文从技术角度出发，梳理社区外卖系统的完整开发路径，核心围绕Java后端服务、多端应用架构以及部署上线三个阶段展开。

一、业务模型与系统架构设计

社区外卖系统的业务复杂度高于标准外卖系统，原因在于其服务类型多样化：既有外卖点餐，也有跑腿代买、快递代取、家政预约等非餐业务。因此，系统的顶层设计需要考虑多业务子系统的拆分与协同。

核心角色划分：

• 用户端：下单、支付、订单追踪、优惠券使用、积分签到、历史浏览、邀请好友等
• 商户端（商家端）：菜品/服务管理、订单接单、出餐/服务状态更新、店铺信息维护
• 骑手端（配送端）：抢单/派单、取货、配送、送达确认、配送收益记录
• 管理后台：用户管理、商户入驻审核、骑手审核、订单监管、投诉处理、优惠券运营、分销推广配置

系统架构建议：

前端展示层（多端复用）
├── 小程序
├── 公众号（H5）
├── APP（iOS/Android）
└── 管理后台（PC Web）

后端服务层
├── 用户服务
├── 商户服务
├── 订单服务（核心）
├── 配送服务
├── 支付服务
├── 营销服务（优惠券/积分/分销）
└── 消息服务（通知/IM）

基础支撑层
├── MySQL（业务数据）
├── Redis（缓存/分布式锁/抢单队列）
├── RabbitMQ（异步消息/订单超时处理）
└── OSS（图片/文件存储）

多端复用方案采用uni-app（Vue语法）开发用户端与骑手端，管理后台采用Vue + ElementUI，后端服务基于Spring Boot + MyBatis Plus + MySQL。这一组合的优势在于技术栈统一、招聘成本低、社区生态成熟，同时支持一套代码编译到小程序、APP、H5等多端。

二、数据库设计与核心表结构

社区外卖系统涉及的数据库表较多，这里抽取核心的几张表进行设计说明，完整系统大约需要50+张表。

1. 订单主表（orders）

CREATE TABLE `orders` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单编号',
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `merchant_id` bigint(20) DEFAULT NULL COMMENT '商户ID',
  `rider_id` bigint(20) DEFAULT NULL COMMENT '骑手ID',
  `order_type` tinyint(4) NOT NULL COMMENT '订单类型：1-外卖 2-跑腿 3-家政 4-快递代取',
  `status` tinyint(4) NOT NULL COMMENT '订单状态：0-待支付 1-待接单 2-配送中 3-已完成 4-已取消',
  `pay_amount` decimal(10,2) NOT NULL COMMENT '支付金额',
  `delivery_fee` decimal(10,2) DEFAULT '0.00' COMMENT '配送费',
  `address_detail` varchar(255) NOT NULL COMMENT '配送地址',
  `expect_time` datetime DEFAULT NULL COMMENT '期望送达时间',
  `remark` varchar(500) DEFAULT NULL COMMENT '备注',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_order_no` (`order_no`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_merchant_id` (`merchant_id`),
  KEY `idx_rider_id` (`rider_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='社区外卖订单表';

2. 骑手抢单池（dispatch_task）

抢单功能是社区外卖区别于传统外卖的典型场景。家政、维修、代取等业务通常需要用户发布需求，然后由附近骑手/服务人员抢单。

CREATE TABLE `dispatch_task` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `task_type` tinyint(4) NOT NULL COMMENT '任务类型：1-外卖配送 2-家政服务 3-维修 4-代取',
  `order_id` bigint(20) NOT NULL COMMENT '关联订单ID',
  `lng` decimal(10,6) NOT NULL COMMENT '经度',
  `lat` decimal(10,6) NOT NULL COMMENT '纬度',
  `dispatch_type` tinyint(4) NOT NULL DEFAULT '1' COMMENT '派单方式：1-抢单 2-指派',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0-待抢单 1-已被接 2-超时未接',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_status_lng_lat` (`status`, `lng`, `lat`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='抢单派单任务池';

3. 优惠券表（coupon）

社区外卖系统的营销模块中，优惠券、满减、分销推广是核心运营工具，2.0版本中新增补费功能（如订单金额不足时补差价）也需要在订单表中预留supplement_amount字段。

CREATE TABLE `coupon` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL,
  `coupon_type` tinyint(4) NOT NULL COMMENT '1-满减券 2-折扣券 3-无门槛券',
  `amount` decimal(10,2) NOT NULL COMMENT '面值',
  `min_amount` decimal(10,2) DEFAULT '0.00' COMMENT '使用门槛',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0-未使用 1-已使用 2-已过期',
  `expire_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_user_status` (`user_id`, `status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

三、核心功能模块实现要点

1. 多端统一订单状态机

社区外卖系统中，不同业务类型的订单状态流转存在差异，建议在订单服务中维护统一状态机，通过order_type区分业务子类型：

public enum OrderStatus {
    PENDING_PAY(0, "待支付"),
    PENDING_ACCEPT(1, "待接单"),
    DELIVERING(2, "配送中"),
    COMPLETED(3, "已完成"),
    CANCELLED(4, "已取消"),
    REFUNDING(5, "退款中"),
    PENDING_SERVICE(6, "待服务");

    private final Integer value;
    private final String desc;

    // getter、setter省略
}

2. 抢单功能的并发控制

社区外卖场景中，抢单是高频并发操作，一个任务可能被多个骑手同时看到，必须防止“超抢”问题。推荐使用Redis + Lua脚本实现原子性抢单：

-- 抢单Lua脚本
local taskKey = KEYS[1]
local riderKey = KEYS[2]
local taskStatus = redis.call('HGET', taskKey, 'status')
if taskStatus == '0' then
    redis.call('HSET', taskKey, 'status', '1')
    redis.call('HSET', taskKey, 'rider_id', ARGV[1])
    redis.call('SADD', riderKey, ARGV[1])
    return 1
end
return 0

3. 订单超时自动取消

采用RabbitMQ延迟队列实现“下单后15分钟未支付自动取消”和“派单后N分钟无人接单自动取消”。相比定时任务轮询，延迟队列更精准，资源消耗更低。

@Configuration
public class RabbitDelayConfig {

    @Bean
    public Queue delayQueue() {
        return QueueBuilder.durable("order.delay.queue")
                .withArgument("x-dead-letter-exchange", "order.exchange")
                .withArgument("x-dead-letter-routing-key", "order.cancel")
                .build();
    }

    @Bean
    public DirectExchange delayExchange() {
        return new DirectExchange("order.delay.exchange");
    }

    @Bean
    public Binding binding() {
        return BindingBuilder.bind(delayQueue())
                .to(delayExchange())
                .with("order.delay");
    }
}

4. 余额支付与原路退款

在本地生活服务场景中，经常出现服务完成前的取消订单或服务过程中增加补费项（如上门维修需要更换配件）。建议在支付服务中统一封装退款接口，对接/支付宝的原路退款能力，同时维护资金流水表，确保每一笔资金的出入可对账。

四、多端开发与部署上线流程

1. 多端工程结构

├── server                    # Java 后端服务（Spring Boot）
│   ├── admin-api             # 管理后台接口
│   ├── user-api              # 用户端接口
│   ├── merchant-api          # 商户端接口
│   └── rider-api             # 骑手端接口
├── user-app                  # uni-app 用户端（小程序/App/H5）
├── rider-app                 # uni-app 骑手端
├── merchant-app              # uni-app 商户端
└── admin-web                 # Vue + ElementUI 管理后台

这种工程组织方式可以实现“一套后端、四个前置端”的完整交付，前端各端从统一网关（如Spring Cloud Gateway）接入不同业务模块接口。

2. 部署架构建议

社区外卖系统建议采用Docker Compose方式部署，便于快速上线和横向扩展：

version: '3.8'
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: community_delivery
    volumes:
      - ./mysql-data:/var/lib/mysql
    ports:
      - "3306:3306"

  redis:
    image: redis:7.0
    ports:
      - "6379:6379"

  rabbitmq:
    image: rabbitmq:3.12-management
    environment:
      RABBITMQ_DEFAULT_USER: ${RABBITMQ_USER}
      RABBITMQ_DEFAULT_PASS: ${RABBITMQ_PASS}
    ports:
      - "5672:5672"
      - "15672:15672"

  server:
    build: ./server
    depends_on:
      - mysql
      - redis
      - rabbitmq
    environment:
      SPRING_PROFILES_ACTIVE: prod
    ports:
      - "8080:8080"

  nginx:
    image: nginx:1.24
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./dist:/usr/share/nginx/html
    ports:
      - "80:80"
      - "443:443"

3. 上线前检查清单

• 支付商户号、证书文件是否上传到服务器
• 高德/腾讯地图Key是否正确配置，测试配送距离计算
• OSS Bucket是否设置公共读或签名URL读写
• HTTPS证书是否部署完整（小程序强制要求HTTPS域名）
• 日志采集（建议接入ELK或Loki）与异常监控（如Sentinel）是否就绪

五、FAQ 常见问题

Q1：社区外卖系统适合用单体架构还是微服务架构？

初期用户量不大时建议直接使用Spring Boot单体工程，按模块分包（用户模块、订单模块、支付模块等），后续业务复杂度上来后按需拆分为微服务。过度设计会增加开发与运维成本，社区外卖的关键在于业务流转顺畅，而非架构的“高大上”。

Q2：抢单功能如何避免并发问题产生超量派单？

核心方案是使用Redis + Lua脚本保证抢单操作的原子性，同时利用MySQL索引或UPDATE ... WHERE status = 0做数据库层面的兜底校验。推荐采用“Redis预占 + 数据库确认”两阶段方案，兼顾性能与可靠性。

Q3：一套代码如何同时支持小程序、公众号H5和APP？

选择uni-app框架，使用Vue语法编写业务逻辑，编译时分别输出小程序、H5和App资源包。注意各端的差异处理，如小程序的登录授权与APP的登录SDK初始化方式不同，建议在工程中封装platform工具类进行差异化管理。

Q4：社区外卖系统上线后期维护需要注意什么？

有两个重点：一是订单状态异常（如骑手接了单但未取货）的补偿机制，建议定期巡检订单表并自动触发消息提醒；二是资金安全，所有的支付、退款、提现操作必须有对账任务每天核对，避免出现资金差错。运力调度方面，当订单量突增时需设计熔断/降级策略，优先保证核心外卖业务的可用性。