1. 项目概述从零搭建餐饮外卖平台的技术实践去年接手公司餐饮系统重构项目时我选择了苍穹外卖作为内部代号。这个基于Java技术栈的外卖平台完整实现了从用户下单到骑手配送的全流程数字化管理。不同于简单的CRUD练习项目它涉及高并发订单处理、实时位置追踪、多端数据同步等真实业务场景的技术实现。2. 技术架构设计2.1 整体技术选型采用SpringBoot 2.7 MyBatis-Plus 3.5作为基础框架组合MySQL 8.0作为主数据库Redis 6.2处理缓存和会话。前端使用Vue3Element Plus通过RESTful API与后端交互。特别之处在于订单模块采用RabbitMQ实现削峰填谷配送系统集成高德地图WebService API支付对接了支付宝沙箱环境2.2 微服务拆分策略虽然单体架构也能实现功能但考虑到后期扩展性我们按业务边界拆分为用户服务account-service店铺服务shop-service订单服务order-service配送服务delivery-service支付服务payment-service每个服务独立数据库通过Nacos实现服务发现和配置管理。这种设计在开发阶段增加了联调成本但在上线后显著降低了模块间的耦合度。3. 核心模块实现细节3.1 高并发订单处理订单创建流程包含几个关键优化点// 使用分布式锁防止重复下单 String lockKey order_lock: userId; try { Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 30, TimeUnit.SECONDS); if (Boolean.TRUE.equals(locked)) { // 1. 校验库存 // 2. 生成订单号雪花算法 // 3. 写入订单表分库分表 // 4. 发送MQ消息 } } finally { redisTemplate.delete(lockKey); }3.2 实时配送系统骑手位置更新采用WebSocketGeoHash方案骑手端每15秒上传GPS坐标服务端计算GeoHash值精度7位通过Redis GEO存储位置信息顾客端订阅配送员ID的频道关键点GeoHash精度选择需要平衡查询效率和位置准确性经过测试7位编码约150米精度最适合城市配送场景。4. 典型问题排查实录4.1 订单超时问题上线初期出现的订单处理延迟最终定位到MySQL连接池配置不当# 错误配置默认值 spring.datasource.hikari.maximum-pool-size10 # 修正后配置 spring.datasource.hikari: maximum-pool-size: 50 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 18000004.2 缓存雪崩防护促销活动时出现的Redis集群崩溃通过以下措施解决缓存过期时间增加随机偏移30分钟±5分钟热点数据永不过期通过后台线程更新实现多级缓存CaffeineRedis5. 开发环境搭建指南5.1 基础环境准备JDK 17注意LTS版本选择Maven 3.8配置阿里云镜像IDEA安装Lombok插件Docker Desktop用于运行MySQL/Redis5.2 数据库初始化建议使用Flyway管理数据库变更-- V1__init_schema.sql CREATE TABLE t_user ( id bigint NOT NULL COMMENT 主键, openid varchar(45) DEFAULT NULL COMMENT 微信用户唯一标识, name varchar(32) NOT NULL COMMENT 姓名, phone varchar(11) NOT NULL COMMENT 手机号, sex varchar(2) DEFAULT NULL COMMENT 性别, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;6. 项目演进路线建议初级版实现基础下单流程3-5天用户注册登录商品浏览购物车功能订单创建进阶版增加分布式特性2周分布式锁控制库存消息队列解耦定时任务处理超时订单企业级完善监控治理1周Prometheus监控SkyWalking链路追踪接口幂等设计这个项目最值得分享的经验是在开发配送轨迹功能时直接调用地图API返回的坐标序列会导致移动路径不自然。我们最终采用了贝塞尔曲线算法对坐标点进行平滑处理使移动轨迹更符合真实骑行场景。实现代码虽然只有20行但用户体验提升非常明显——这提醒我们技术方案的选择要以业务场景为第一考量。
