1. 项目背景与核心需求苍穹外卖这个命名很有意思让我联想到一个覆盖范围广、服务能力强的外卖配送系统。作为从业十年的技术人我见过太多外卖平台从零搭建的过程。Day01的笔记往往决定了整个项目的技术走向这里分享下这类系统首日搭建的关键要点。外卖系统的核心是解决用户下单-商家接单-骑手配送这个铁三角关系。首日搭建需要完成基础框架的搭建通常包括用户端界面原型商家后台雏形基础订单流转逻辑最简单的配送算法特别提醒很多团队第一天就陷入技术选型的纠结。我的经验是先用最简方案跑通核心流程细节优化可以后续迭代。2. 技术栈选型分析2.1 前端技术选择移动端优先考虑React Native或Flutter开发效率高一套代码多端运行热更新能力关键外卖业务需求变化快性能足够支撑基础功能如果团队有原生开发经验也可以采用AndroidKotlin Jetpack ComposeiOSSwiftUI实测建议首日先用React Native快速出原型后期再视情况重构。我们团队曾用3小时就完成了首版登录-下单流程。2.2 后端架构设计微服务架构是必然选择但Day01可以简化graph TD A[API Gateway] -- B[用户服务] A -- C[商家服务] A -- D[订单服务] A -- E[配送服务]关键配置参数# 网关超时设置外卖场景建议值 gateway: connect-timeout: 3000ms read-timeout: 5000ms数据库选型用户/商家数据MySQL关系型数据订单数据MongoDB灵活扩展字段地理位置Redis GEO3. 核心业务流程实现3.1 订单状态机设计外卖订单的典型状态流转public enum OrderStatus { CREATED, // 已创建 PAID, // 已支付 ACCEPTED, // 商家接单 PREPARING, // 备餐中 READY, // 备餐完成 DISPATCHING, // 配送中 COMPLETED, // 已完成 CANCELLED // 已取消 }状态变更要注意支付超时自动取消通常15分钟商家接单超时提醒5分钟未接自动取消备餐超时预警根据菜品类型设置不同阈值3.2 配送算法V1.0首日只需实现最简派单逻辑获取商家坐标和用户坐标计算直线距离后期改用道路距离查找3公里内空闲骑手按接单率排序派单距离计算代码示例from math import radians, sin, cos, sqrt, asin def haversine(lat1, lon1, lat2, lon2): # 将十进制度数转化为弧度 lon1, lat1, lon2, lat2 map(radians, [lon1, lat1, lon2, lat2]) # haversine公式 dlon lon2 - lon1 dlat lat2 - lat1 a sin(dlat/2)**2 cos(lat1) * cos(lat2) * sin(dlon/2)**2 c 2 * asin(sqrt(a)) r 6371 # 地球平均半径单位为公里 return c * r4. 首日避坑指南4.1 时间处理陷阱外卖系统必须统一时区遇到过的问题服务器UTC时间 vs 本地时间订单超时计算错误促销活动时间对不齐解决方案// 强制使用东八区时间 ZoneId zone ZoneId.of(Asia/Shanghai); LocalDateTime now LocalDateTime.now(zone);4.2 金额计算精度浮点数计算导致的金额错误使用BigDecimal代替double数据库存储单位用分整数优惠券分摊算法要精确到厘4.3 压力测试要点即使Day01也要关注模拟集中下单场景午高峰数据库连接池配置第三方接口如支付的熔断策略推荐测试工具JMeter模拟并发订单Gatling测试地理位置查询5. 监控体系搭建Day01就要埋点关键业务指标订单创建成功率支付转化率平均接单时长技术指标API响应时间P99数据库查询耗时缓存命中率Prometheus配置示例scrape_configs: - job_name: takeaway metrics_path: /actuator/prometheus static_configs: - targets: [user-service:8080]6. 后续演进方向完成Day01搭建后建议优先优化智能派单算法考虑骑手路线、商家出餐速度动态定价策略高峰时段溢价预测备餐系统基于历史数据技术债要重点记录需要重构的临时方案已知的性能瓶颈待完善的监控项