做了这么多年餐饮SaaS说实话扫码点餐这个需求我之前一直没觉得有什么技术含量直到接了那个海外华人餐厅的单子才发现国际版三个字背后藏着一整座冰山。很多人以为国际版扫码点餐就是把按钮翻译成英文、菜单改成双语真正动手做起来才知道从订单状态机的设计、菜品的多语言与多规格模型到多币种金额处理、多时区的时间归因再到跨境支付回调的幂等防重每一层都是坑。这篇文章把我用Java从零实现国际版扫码点餐系统的完整过程、技术选型逻辑、核心模块设计以及踩过的坑一次说透适合正在做餐饮系统、或准备把手里的本地点餐项目推向海外市场的Java开发者参考。1. 扫码点餐不是简单扫码下单先理清国际版的真实需求1.1 从用户动线拆解核心流程我接这个项目时需求文档上写的是做一套和国内版差不多的扫码点餐支持英文和中文就行。拿到这种需求千万别急着写代码。我习惯第一步把用户动线完整画出来顾客进店坐下看到桌角的二维码掏出手机扫码进入餐厅的菜单页选菜加购提交订单后厨出餐服务员上菜顾客吃完后买单。这七步看着简单每一步放到国际版场景里都有变数。扫码之后手机浏览器打开的是H5不是小程序因为海外用户不装微信菜单加载要考虑CDN分发和多语言切换提交订单要处理不同国家的支付网关后厨出餐要对接KDS厨房显示系统或者热敏打印机买单环节有的国家习惯桌边刷卡有的习惯扫码支付有的直接去收银台。所以做国际版扫码点餐核心是先把业务动作抽象成一套与国家/地区解耦的流程引擎再把语言、货币、支付、打印格式做成可插拔的配置。1.2 国际版和国内版的本质差异这里我得说一个很多人忽略的点国际版不是国内版的翻译版而是另一套产品逻辑。国内版的扫码点餐微信支付和支付宝基本覆盖了90%的场景支付回调、退款、对账都围绕这两家来做。海外不同国家的支付方式极度碎片化北美流行信用卡和Apple Pay欧洲很多国家用iDEAL、Klarna东南亚用GrabPay、当地电子钱包拉美则大量依赖现金和Pix巴西。支付只是差异之一。数据库里的时间国内一个时区搞定国际版要面对全球几十个时区货币单位不同日元的金额是0位小数科威特第纳尔是3位小数如果数据库里金额字段用double存早晚出事还有菜单的多语言英文描述通常比中文长一倍UI空间和打印机的小票格式全要跟着调再往深处说有的国家对食品过敏原有强制标注要求有的国家对数字隐私有特定法规这些都要在系统里预留字段和逻辑。1.3 我的技术倾向与项目边界我最终采用的方案是Spring Boot 3.x单体架构起步按模块划分边界预留接口拆分微服务。理由后面详细说。项目整体分四个端顾客扫码后的H5点餐端、服务员用的管理端、后厨展示/打印端、商家后台运营端外加一个定时任务模块处理订单超时、库存释放、对账单生成。技术栈以Java 17为主Spring MVC做REST APIMyBatis-Plus做数据持久化Redis做缓存和分布式锁RabbitMQ做订单事件异步通知MySQL 8.0存核心业务数据MongoDB存菜单的多语言副本和操作日志。这个组合不算新潮但胜在稳定、社区资料多、出问题好排查餐饮系统不是炫技的地方。2. Java技术栈选型从单体到微服务的取舍2.1 为什么主力语言还是Java这个项目不是从零选语言但我也认真对比过Go、Node.js和Java的优劣势。餐饮点餐系统的特点是业务逻辑复杂订单状态机、库存、优惠、支付对账、并发有峰值但整体可控午晚餐高峰、团队后续要长期维护迭代。Java在这三个维度上依然是综合分最高的。它的生态里有成熟的状态机框架、分布式事务方案、丰富的支付SDK对接案例而且Java开发者在全球范围内都好招。Go在处理高并发连接上有优势但业务模型复杂之后开发效率反而不如Java加上一套好用的框架。具体的方案上我没有引入Spring Cloud那套全家桶而是先把所有功能做在一个可水平扩展的应用里。原因很直接这个项目的首版核心目标是快速跑通流程、验证需求单体架构在业务迭代初期的部署和调试成本远低于微服务。等订单量上来、团队扩充到多组并行开发时再按点餐服务、订单服务、支付服务、基础数据服务四个域拆也不迟模块边界我已经在代码层面用Package分好了。2.2 核心框架的版本与搭配细节Spring Boot 3.x要求Java 17起步这正好让我避开了老项目中一堆基于javax包的兼容问题。这里要说个实操经验很多老程序员拿到Spring Boot 3.x项目把别人的配置一拷结果启动报错十有八九是依赖包引入了旧版javax.servlet、javax.annotation。我在项目里用了一个笨办法保证干净统一用Maven BOM管理依赖版本pom.xml里显式排除所有javax开头的传递依赖核心依赖列表如下。组件版本用途说明Spring Boot3.2.xWeb、Validation、ActuatorMyBatis-Plus3.5.xORM与分页插件Redis客户端Lettuce缓存与分布式锁RabbitMQ3.12.x订单事件异步解耦ZXing3.5.x二维码生成Quartz2.3.x超时订单扫描与对账定时任务数据库连接池我用了HikariCPSpring Boot默认集成配置时注意maximum-pool-size不要贪大我以前见过有人设成100结果数据库连接数被打满整个系统雪崩。按部署实例数平均每个实例20个连接在小规模餐饮项目里完全够用。2.3 从单体出发哪些模块必须提前预留接口虽然我说了用单体架构但有两处接口必须提前抽象。第一是支付网关我定义了一个PaymentGateway接口下面先实现Stripe和PayPal两个适配器后续要接Adyen、Klarna只需要扩展适配器下单流程和回调处理完全不动。第二是消息推送推送到H5端我用了WebSocket Spring Messaging推送到后厨大屏用的是SSEServer-Sent Events这两条通道在接口层统一封装为OrderEventPublisher业务代码只发一个OrderEvent具体走WebSocket还是SSE由配置决定。这里加密说一句单体架构下代码粒度不是越大越好模块之间的依赖方向要在Package结构上卡死。我按接口层→应用服务层→领域服务层→基础设施层的依赖规则去做架构评审谁违反谁重构这样后续拆微服务时只需要把不同Package拎出来部署并补上Feign调用即可业务代码改动量很小。3. 多语言、多币种、多时区国际化三大硬骨头的落地解法3.1 多语言不等同于资源文件Spring的MessageSource做多语言简单但放到点餐场景里就复杂了一个菜品的名称、描述、过敏原提示、口味说明都是多语言内容而且品类不同语言的字符长度差异很大。英文的Grilled Salmon with Lemon Butter Sauce放在中文香煎三文鱼配柠檬黄油汁的位置肯定要换行甚至撑破布局。所以我的方案是菜单基础表只存菜品ID和全局唯一编码菜品名称、描述、过敏原、自定义标签存到独立的多语言表结构大致这样。CREATE TABLE dish_i18n ( id BIGINT AUTO_INCREMENT PRIMARY KEY, dish_id BIGINT NOT NULL, locale VARCHAR(16) NOT NULL, name VARCHAR(200) NOT NULL, description VARCHAR(1000), allergen_info VARCHAR(500), UNIQUE KEY uk_dish_locale (dish_id, locale) );使用方通过一个I18nMenuService取菜品时按当前请求头里的Accept-Language或者顾客选购时选择的语言偏好去查对应语言字段。这里有一个细节内容不能只按语言存还要按国家/地区存因为同样是英语英国、美国、澳洲的菜品描述和拼写习惯是有差异的比如chips和fries所以locale我存的是en-US、en-GB、zh-CN这种完整格式fallback链是en-US → en → 默认语言。3.2 金额处理BigDecimal是底线国际版涉及多币种最数据安全的点是金额精度。数据库凡是涉及金额的字段全部用DECIMAL(12, 2)或DECIMAL(12, 4)Java代码里一律用BigDecimal严禁double和float。一套菜品在不同国家定价涉及到汇率换算我单独建了currency_rate表每天定时任务从汇率服务拉取最新汇率换算时用中间货币USD做锚点避免A国货币直接换算B国货币时的交叉汇率误差。国际版还有一个容易被忽视的点不同货币的小数位数不同。JPY是0位小数USD和EUR是2位BHD和KWD是3位。我的Money对象里封装了currencyCode和BigDecimal amount格式化显示时通过Currency.getDefaultFractionDigits(currencyCode)动态取小数位前端也通过接口拿到小数位配置避免显示¥100.00这种在日本场景里奇怪的精度。小票打印的金额格式也一样不能写死。3.3 时区与时间归因数据库统一存UTC一台部署在新加坡的服务器服务的顾客可能来自全球各地。订单的创建时间、支付时间、对账时间在数据库里必须统一存UTC时间戳展示层再按餐厅所在时区或者顾客所在时区去转换。我封装了一个TimeZoneResolver组件从餐厅表里取该店铺的默认时区配合H5前端通过JS获取用户本地时区两相结合决定每个请求里的时间上下文。这里还有一个业务归因问题报表统计需要按餐厅本地日期分组而不能按服务器日期直接按天聚合。比如一个美国洛杉矶的餐厅UTC时间凌晨2点对应的还是当地前一天晚上7点。我的做法是在生成日报时先从UTC时间按餐厅时区偏移到本地时间再按本地y-m-d分组否则每天的单量和营业额会算错边界。类似的坑做跨时区项目的一定要提前设计。4. 扫码点餐核心链路的设计与实现从桌台码到订单状态机4.1 桌台码的生成与绑定每张桌子的二维码我存的核心信息只有三个餐厅ID、桌台ID、一个随机校验签名。扫码后前端拿到这些参数请求后端换取一个绑定桌台的短期Token后续的所有操作都带着这个Token。二维码内容我经过ZXing库生成编码格式用的是带校验的Payload内容设计如下。public String generateTableCode(Long restaurantId, Long tableId) { String raw restaurant restaurantId table tableId expire (System.currentTimeMillis() 30 * 24 * 3600 * 1000L); String sign HmacUtils.hmacSha256Hex(SECRET_KEY, raw); return Base64.getUrlEncoder().encodeToString((raw sign sign).getBytes(StandardCharsets.UTF_8)); }这里有人会问为什么不直接用桌台ID做码因为要防伪造。如果有人篡改二维码里的桌位参数就可能占别人的桌台或者给后厨下恶作剧订单。签名校验能够保证二维码是系统签发的同时过期时间避免二维码被长期滥用。扫码落地后桌台在Redis里生成一个状态Key标记有人用餐等结账后再清除。4.2 购物车与菜品多规格的处理顾客扫码后的点餐过程购物车在服务端Session和本地存储之间我选择了本地存储服务端校验的混合模式。购物车明细保存在H5前端的localStorage里减少后端压力提交订单时后端一次性校验菜品库存、价格有效性、规格组合是否合法。为什么不把购物车放Redis因为点餐场景下用户加购、改购的请求频率高每个操作都走Redis网络I/O在弱网环境下体验会很差本地存储则零延迟。价格和库存校验收口在服务端完成就不会有客户端篡改价格的风险。多规格比如饮品选糖度、小料牛排选熟度我建了一张sku表简单的规格组合用JSON字段存复杂的组合按SKU维度拆库存。关键点在于规格的显示文本也是多语言的糖度的少糖半糖正常在不同的语言环境里要有对应翻译涨价和库存扣减只能针对SKU不能对着菜品级别操作否则会出现不同规格共享库存导致超卖。4.3 订单状态机的驱动力事件驱动 状态流转扫码点餐的订单状态比电商订单复杂因为它有已下单→已接单→制作中→已上菜→已完成这条线下链路中间还可能插入催单退菜超时未支付自动取消等异常操作。我用一张订单状态表记录状态状态流转全部通过OrderStatusEvent事件驱动用RabbitMQ异步执行后续动作核心状态机模型如下。当前状态触发事件目标状态执行动作PENDING_PAYMENTPAY_SUCCESSRECEIVED后厨推送、打印订单PENDING_PAYMENTPAY_TIMEOUTCANCELLED释放桌台、释放库存RECEIVEDKITCHEN_STARTPREPARING更新预计出餐时间PREPARINGDISH_READYDELIVERED叫号通知顾客DELIVEREDSETTLE_ACCOUNTCOMPLETED生成对账单状态流转不能散落在业务代码里我统一收口在一个OrderStateMachine类中每个合法转移都做前置校验防止脏数据把订单卡在一个进退两难的节点。这里要特别提醒支付成功的回调处理必须保证幂等即同一笔订单的支付成功事件重复消费不会导致状态重复流转。我在事件里引入了eventId去重表消费前先查一条一样eventId的记录有没有处理过处理过就直接ACK不做任何状态变更。4.4 超时未支付的订单处理延时消息与定时扫单国际版的顾客支付习惯不同有些国家的顾客下单后习惯慢慢选支付方式支付超时时间不能写死。我设置了一个可配置的支付超时时间默认15分钟。实现上用了三级保障第一级RabbitMQ的延迟消息插件在订单创建后发送一条延时消息到点检查是否已支付第二级Quartz每3分钟扫描一次处于待支付、时间超过阈值的订单做兜底取消第三级顾客主动取消接口直接释放资源。三级保障确保了即使某个环节出问题也不至于把桌台和库存扣住不放。关于RabbitMQ延迟消息有一点踩坑经验rabbitmq_delayed_message_exchange插件是把消息存在MnesiaErlang的分布式数据库里插入和读取性能远不如普通队列如果订单量很大会让Broker压力剧增。所以我只在OrderCreated事件上用延迟消息其他业务事件还是走普通交换机。后来测试高峰期订单创建几千笔时延迟插件所在Broker的内存和消息堆积明显偏高后来我调整了策略延迟消息只用于订单超时提醒5分钟以上的超时场景改用定时扫单兜底插件压力就降下来了。spring: rabbitmq: listener: simple: retry: enabled: true max-attempts: 3 initial-interval: 1000订单事件消费者我开启了重试机制。这里有个学习要点如果消费者处理消息时抛出异常不能简单无限重试否则会造成消息循环堆积甚至死信。配置如上最多重试3次仍失败进入死信队列由定时任务查库纠正状态。消息和数据库状态是两个独立系统最终要对账一致性绝对不能只靠消息驱动。5. 国际版高并发场景下的性能优化实践5.1 菜单缓存与热点数据隔离扫码点餐在午晚餐高峰期的特点非常明显短时间内大量顾客同时打开菜单菜品信息和图片请求量瞬间拉升。菜单数据是典型的读多写少我用Redis做了两级缓存第一级是本地Caffeine缓存过期时间60秒等于每个服务实例在本地留一份热点菜单第二级是Redis缓存过期时间5分钟负责多实例间的数据同步和穿透兜底。请求进来先查Caffeine不中再查Redis再回源查MySQL。这套机制有一个细节要注意菜单更新比如菜品下架、临时沽清需要主动淘汰缓存否则顾客看到的菜单和实际库存不一致。我在菜单更新接口里写了一个cacheService.evictMenu(restaurantId)方法先删除Redis里的菜单缓存再把本地Caffeine实例删除。单个实例删除本地缓存比较容易但有多个实例时得通过Redis Pub/Sub广播一个缓存的失效事件让其他实例也删。不然有的用户看到的是新菜单有的还是旧菜单在时差问题下体验很糟糕。5.2 高并发扣库存Redis原子操作 数据库兜底点餐系统和电商系统一样存在超卖风险但餐饮的库存模型更轻主要针对沽清每日限量菜品如例汤、特色甜点。我用Redis的Lua脚本做库存预扣原子性由Redis保证脚本逻辑是判断当前库存大于0就减一否则返回失败。同时落数据库用乐观锁版本号做兜底防止Redis数据丢失后重启恢复不一致。if redis.call(exists, KEYS[1]) 1 then local stock tonumber(redis.call(get, KEYS[1])) if stock 0 then redis.call(decr, KEYS[1]) return 1 end return 0 end return -1分布式环境下我可以更进一步做订单维度的防重同一个桌台、同一顾客、同一种菜品在30秒内的重复下单用Redis的SETNX加一个锁来拦截避免顾客手滑多点了几份。这个防重用后来看非常有效至少挡掉了很大比例的重复请求。5.3 订单通知的推送通道WebSocket与SSE分工国际版点餐前端是H5页面自然优先考虑WebSocket维持长连接但WebSocket在弱网环境里的自动重连、断线恢复处理比较麻烦。我的做法是按消息类型拆分面向点餐顾客的状态变化通知比如订单制作完成、可以取餐了用SSE单向通道服务端主动推给顾客代码简洁断线自动重连由浏览器原生能力处理面向顾客扫码后的实时聊天如果有才用WebSocket双向通道。这里有一个隐藏性能点SSE和WebSocket连接都属于长连接每个实例的连接数上限受Nginx和Tomcat配置影响。我在压测时发现默认Nginx没有配置超时时间时空闲的SSE连接会一直挂着限制并发能力。后来我把proxy_read_timeout设为60秒配合前端SSE的心跳重连逻辑连接数和稳定性都比较理想。线程模型上Tomcat的默认最大线程数是200每个SSE连接会占一个线程所以当在线顾客多的时候不能盲目开太多SSE连接我按餐厅ID做连接复用一个餐厅连接一个推送通道消息里带桌台标识进行广播。6. 部署与运维阶段踩过的坑多区域、支付回调与日志监控6.1 多区域部署与数据同步国际版自然要考虑多区域部署。我最初天真地以为部署在一个区域、全球访问就行结果东南亚的顾客打开欧洲节点的页面时菜单图片加载慢得让人抓狂。后来前端静态资源挂CDN核心API部署到两个区域一个主区域一个灾备区域MySQL做主从复制Redis跨区域只读副本。这里有一个一致性取舍跨区域同步数据有延迟所以我把订单创建强一致留在主区域菜单、餐厅信息这类低频变更数据通过MQ异步同步到其他区域的只读副本。有一个小的经验不同区域之间的数据库时区设置要保持一致统一UTC表结构变更要走Online DDL工具比如pt-online-schema-change否则在复制环境下添加字段可能锁表。我踩过一次直接ALTER TABLE加索引大表在从库同步时延迟飙升线上点餐查询慢得不行从那以后全部走gh-ost或者pt-osc。6.2 支付回调的幂等与防重Stripe、PayPal、Adyen这些支付网关的回调机制和国内支付平台大同小异但有两个额外痛点回调来源IP不确定、回调可能重复送达且不保证顺序。我在所有支付回调入口做了三件事验签用各自的Webhook签名机制、幂等eventId去重表、状态机校验只有待支付订单才能流转到已支付。另外支付回调接口必须返回200响应给支付网关如果业务处理成功前就直接返回200支付网关会认为投递成功丢失订单如果业务处理失败得要返回4xx来触发网关重试但要小心重试风暴所以重试次数和间隔要在网关后台配置好。我在开发时遇到过一个问题Stripe回调顺序不是严格按时间排序的比如payment_intent.succeeded事件先到charge.refunded事件后到两个事件处理同一个订单处理逻辑必须都是幂等的否则就会把已支付的订单又标记成已退款中间还经历了状态机拦截。后来单独写了一个callback_audit表把每个事件的原始Payload、处理结果、耗时都记录下来方便对账和排障。6.3 日志与监控的国际化陷阱多语言环境下日志里不能出现乱码这是基本要求。我所有应用日志文件统一UTF-8编码数据库连接串加了characterEncodingutf8RabbitMQ消息体强制JSON字符串UTF-8编码。以前我遇到过一个问题中文菜单名写入消息队列后消费者拿到的字符串末尾多了一个问号排查半天发现是生产者用的字符集是平台默认字符集在Linux下是UTF-8在Windows下是GBK后来强制在消息发送时指定StandardCharsets.UTF_8再没出现过问题。监控方面我用了Spring Boot Actuator暴露指标健康、线程、内存、缓存命中率、数据库连接池水位配合Prometheus抓取、Grafana展示。关键报警围绕三点订单支付成功率突降、支付回调积压数超过阈值、订单表数据量接近分表阈值。餐饮高峰期一过凌晨定时对账如果发现异常触发告警到值班群。这几种监控就够用了没必要一开始就上全链路追踪先把核心链路盯住。6.4 索引设计与慢查询治理一段实际优化实录系统上线运营两个月后发现顾客查看历史订单的接口越来越慢慢查询日志显示一条SQL扫了60多万行。这条SQL的问题是一个多月前埋下的WHERE restaurant_id #{restaurantId} ORDER BY created_at DESC LIMIT 20当时没建联合索引结果随着订单表数据量增长排序和过滤都全表扫描了。我加了一个联合索引(restaurant_id, created_at DESC)以后接口耗时从1.8秒降到40毫秒。这个案例想说的是索引设计一定要配合实际查询模式来列表页的筛选字段、排序字段都应该通过联合索引覆盖不要等到慢查询报警才去补救。再补充一条分页的坑如果订单量特别大用LIMIT 10000, 20这种深分页性能很差可以用游标分页代替。也就是上一页最后一条订单的时间戳作为下一页的查询条件避免扫大量无关行。这个优化对移动端下拉加载历史订单特别有效。最终这套系统上线稳定运行了大半年。从一台最小配置的云主机起步到高峰期扛过了一天几万的订单量。整体看下来国际版扫码点餐的难点不在单点技术而在业务理解和抽象能力。我在实际开发中的最大体会是做国际化项目第一个版本就要把语言、时区、币种当成一等公民来设计千万不要在中后期打补丁。刚开始多花一周时间把基础模型做扎实后面整体能省出一个月的返工时间。还有一点如果你也是自己做整个系统一定要留出足够的联调时间国际版的三方对接支付网关、CDN、消息推送、汇率API比国内版本多得多联调周期至少按国内版的1.5倍估。扫码点餐的脚手架代码不难找但每一家餐厅的菜单结构、后厨动线和支付习惯都不同真正值钱的不是那几行Java代码而是对业务的深入理解。希望这篇文章能帮你少踩几个坑把项目顺利做上线。 
长河君 · 2026/9/11 6:55:13 · 阅读 1.2k Java从零实现国际版扫码点餐系统：架构设计与踩坑总结
做了这么多年餐饮SaaS说实话扫码点餐这个需求我之前一直没觉得有什么技术含量直到接了那个海外华人餐厅的单子才发现国际版三个字背后藏着一整座冰山。很多人以为国际版扫码点餐就是把按钮翻译成英文、菜单改成双语真正动手做起来才知道从订单状态机的设计、菜品的多语言与多规格模型到多币种金额处理、多时区的时间归因再到跨境支付回调的幂等防重每一层都是坑。这篇文章把我用Java从零实现国际版扫码点餐系统的完整过程、技术选型逻辑、核心模块设计以及踩过的坑一次说透适合正在做餐饮系统、或准备把手里的本地点餐项目推向海外市场的Java开发者参考。1. 扫码点餐不是简单扫码下单先理清国际版的真实需求1.1 从用户动线拆解核心流程我接这个项目时需求文档上写的是做一套和国内版差不多的扫码点餐支持英文和中文就行。拿到这种需求千万别急着写代码。我习惯第一步把用户动线完整画出来顾客进店坐下看到桌角的二维码掏出手机扫码进入餐厅的菜单页选菜加购提交订单后厨出餐服务员上菜顾客吃完后买单。这七步看着简单每一步放到国际版场景里都有变数。扫码之后手机浏览器打开的是H5不是小程序因为海外用户不装微信菜单加载要考虑CDN分发和多语言切换提交订单要处理不同国家的支付网关后厨出餐要对接KDS厨房显示系统或者热敏打印机买单环节有的国家习惯桌边刷卡有的习惯扫码支付有的直接去收银台。所以做国际版扫码点餐核心是先把业务动作抽象成一套与国家/地区解耦的流程引擎再把语言、货币、支付、打印格式做成可插拔的配置。1.2 国际版和国内版的本质差异这里我得说一个很多人忽略的点国际版不是国内版的翻译版而是另一套产品逻辑。国内版的扫码点餐微信支付和支付宝基本覆盖了90%的场景支付回调、退款、对账都围绕这两家来做。海外不同国家的支付方式极度碎片化北美流行信用卡和Apple Pay欧洲很多国家用iDEAL、Klarna东南亚用GrabPay、当地电子钱包拉美则大量依赖现金和Pix巴西。支付只是差异之一。数据库里的时间国内一个时区搞定国际版要面对全球几十个时区货币单位不同日元的金额是0位小数科威特第纳尔是3位小数如果数据库里金额字段用double存早晚出事还有菜单的多语言英文描述通常比中文长一倍UI空间和打印机的小票格式全要跟着调再往深处说有的国家对食品过敏原有强制标注要求有的国家对数字隐私有特定法规这些都要在系统里预留字段和逻辑。1.3 我的技术倾向与项目边界我最终采用的方案是Spring Boot 3.x单体架构起步按模块划分边界预留接口拆分微服务。理由后面详细说。项目整体分四个端顾客扫码后的H5点餐端、服务员用的管理端、后厨展示/打印端、商家后台运营端外加一个定时任务模块处理订单超时、库存释放、对账单生成。技术栈以Java 17为主Spring MVC做REST APIMyBatis-Plus做数据持久化Redis做缓存和分布式锁RabbitMQ做订单事件异步通知MySQL 8.0存核心业务数据MongoDB存菜单的多语言副本和操作日志。这个组合不算新潮但胜在稳定、社区资料多、出问题好排查餐饮系统不是炫技的地方。2. Java技术栈选型从单体到微服务的取舍2.1 为什么主力语言还是Java这个项目不是从零选语言但我也认真对比过Go、Node.js和Java的优劣势。餐饮点餐系统的特点是业务逻辑复杂订单状态机、库存、优惠、支付对账、并发有峰值但整体可控午晚餐高峰、团队后续要长期维护迭代。Java在这三个维度上依然是综合分最高的。它的生态里有成熟的状态机框架、分布式事务方案、丰富的支付SDK对接案例而且Java开发者在全球范围内都好招。Go在处理高并发连接上有优势但业务模型复杂之后开发效率反而不如Java加上一套好用的框架。具体的方案上我没有引入Spring Cloud那套全家桶而是先把所有功能做在一个可水平扩展的应用里。原因很直接这个项目的首版核心目标是快速跑通流程、验证需求单体架构在业务迭代初期的部署和调试成本远低于微服务。等订单量上来、团队扩充到多组并行开发时再按点餐服务、订单服务、支付服务、基础数据服务四个域拆也不迟模块边界我已经在代码层面用Package分好了。2.2 核心框架的版本与搭配细节Spring Boot 3.x要求Java 17起步这正好让我避开了老项目中一堆基于javax包的兼容问题。这里要说个实操经验很多老程序员拿到Spring Boot 3.x项目把别人的配置一拷结果启动报错十有八九是依赖包引入了旧版javax.servlet、javax.annotation。我在项目里用了一个笨办法保证干净统一用Maven BOM管理依赖版本pom.xml里显式排除所有javax开头的传递依赖核心依赖列表如下。组件版本用途说明Spring Boot3.2.xWeb、Validation、ActuatorMyBatis-Plus3.5.xORM与分页插件Redis客户端Lettuce缓存与分布式锁RabbitMQ3.12.x订单事件异步解耦ZXing3.5.x二维码生成Quartz2.3.x超时订单扫描与对账定时任务数据库连接池我用了HikariCPSpring Boot默认集成配置时注意maximum-pool-size不要贪大我以前见过有人设成100结果数据库连接数被打满整个系统雪崩。按部署实例数平均每个实例20个连接在小规模餐饮项目里完全够用。2.3 从单体出发哪些模块必须提前预留接口虽然我说了用单体架构但有两处接口必须提前抽象。第一是支付网关我定义了一个PaymentGateway接口下面先实现Stripe和PayPal两个适配器后续要接Adyen、Klarna只需要扩展适配器下单流程和回调处理完全不动。第二是消息推送推送到H5端我用了WebSocket Spring Messaging推送到后厨大屏用的是SSEServer-Sent Events这两条通道在接口层统一封装为OrderEventPublisher业务代码只发一个OrderEvent具体走WebSocket还是SSE由配置决定。这里加密说一句单体架构下代码粒度不是越大越好模块之间的依赖方向要在Package结构上卡死。我按接口层→应用服务层→领域服务层→基础设施层的依赖规则去做架构评审谁违反谁重构这样后续拆微服务时只需要把不同Package拎出来部署并补上Feign调用即可业务代码改动量很小。3. 多语言、多币种、多时区国际化三大硬骨头的落地解法3.1 多语言不等同于资源文件Spring的MessageSource做多语言简单但放到点餐场景里就复杂了一个菜品的名称、描述、过敏原提示、口味说明都是多语言内容而且品类不同语言的字符长度差异很大。英文的Grilled Salmon with Lemon Butter Sauce放在中文香煎三文鱼配柠檬黄油汁的位置肯定要换行甚至撑破布局。所以我的方案是菜单基础表只存菜品ID和全局唯一编码菜品名称、描述、过敏原、自定义标签存到独立的多语言表结构大致这样。CREATE TABLE dish_i18n ( id BIGINT AUTO_INCREMENT PRIMARY KEY, dish_id BIGINT NOT NULL, locale VARCHAR(16) NOT NULL, name VARCHAR(200) NOT NULL, description VARCHAR(1000), allergen_info VARCHAR(500), UNIQUE KEY uk_dish_locale (dish_id, locale) );使用方通过一个I18nMenuService取菜品时按当前请求头里的Accept-Language或者顾客选购时选择的语言偏好去查对应语言字段。这里有一个细节内容不能只按语言存还要按国家/地区存因为同样是英语英国、美国、澳洲的菜品描述和拼写习惯是有差异的比如chips和fries所以locale我存的是en-US、en-GB、zh-CN这种完整格式fallback链是en-US → en → 默认语言。3.2 金额处理BigDecimal是底线国际版涉及多币种最数据安全的点是金额精度。数据库凡是涉及金额的字段全部用DECIMAL(12, 2)或DECIMAL(12, 4)Java代码里一律用BigDecimal严禁double和float。一套菜品在不同国家定价涉及到汇率换算我单独建了currency_rate表每天定时任务从汇率服务拉取最新汇率换算时用中间货币USD做锚点避免A国货币直接换算B国货币时的交叉汇率误差。国际版还有一个容易被忽视的点不同货币的小数位数不同。JPY是0位小数USD和EUR是2位BHD和KWD是3位。我的Money对象里封装了currencyCode和BigDecimal amount格式化显示时通过Currency.getDefaultFractionDigits(currencyCode)动态取小数位前端也通过接口拿到小数位配置避免显示¥100.00这种在日本场景里奇怪的精度。小票打印的金额格式也一样不能写死。3.3 时区与时间归因数据库统一存UTC一台部署在新加坡的服务器服务的顾客可能来自全球各地。订单的创建时间、支付时间、对账时间在数据库里必须统一存UTC时间戳展示层再按餐厅所在时区或者顾客所在时区去转换。我封装了一个TimeZoneResolver组件从餐厅表里取该店铺的默认时区配合H5前端通过JS获取用户本地时区两相结合决定每个请求里的时间上下文。这里还有一个业务归因问题报表统计需要按餐厅本地日期分组而不能按服务器日期直接按天聚合。比如一个美国洛杉矶的餐厅UTC时间凌晨2点对应的还是当地前一天晚上7点。我的做法是在生成日报时先从UTC时间按餐厅时区偏移到本地时间再按本地y-m-d分组否则每天的单量和营业额会算错边界。类似的坑做跨时区项目的一定要提前设计。4. 扫码点餐核心链路的设计与实现从桌台码到订单状态机4.1 桌台码的生成与绑定每张桌子的二维码我存的核心信息只有三个餐厅ID、桌台ID、一个随机校验签名。扫码后前端拿到这些参数请求后端换取一个绑定桌台的短期Token后续的所有操作都带着这个Token。二维码内容我经过ZXing库生成编码格式用的是带校验的Payload内容设计如下。public String generateTableCode(Long restaurantId, Long tableId) { String raw restaurant restaurantId table tableId expire (System.currentTimeMillis() 30 * 24 * 3600 * 1000L); String sign HmacUtils.hmacSha256Hex(SECRET_KEY, raw); return Base64.getUrlEncoder().encodeToString((raw sign sign).getBytes(StandardCharsets.UTF_8)); }这里有人会问为什么不直接用桌台ID做码因为要防伪造。如果有人篡改二维码里的桌位参数就可能占别人的桌台或者给后厨下恶作剧订单。签名校验能够保证二维码是系统签发的同时过期时间避免二维码被长期滥用。扫码落地后桌台在Redis里生成一个状态Key标记有人用餐等结账后再清除。4.2 购物车与菜品多规格的处理顾客扫码后的点餐过程购物车在服务端Session和本地存储之间我选择了本地存储服务端校验的混合模式。购物车明细保存在H5前端的localStorage里减少后端压力提交订单时后端一次性校验菜品库存、价格有效性、规格组合是否合法。为什么不把购物车放Redis因为点餐场景下用户加购、改购的请求频率高每个操作都走Redis网络I/O在弱网环境下体验会很差本地存储则零延迟。价格和库存校验收口在服务端完成就不会有客户端篡改价格的风险。多规格比如饮品选糖度、小料牛排选熟度我建了一张sku表简单的规格组合用JSON字段存复杂的组合按SKU维度拆库存。关键点在于规格的显示文本也是多语言的糖度的少糖半糖正常在不同的语言环境里要有对应翻译涨价和库存扣减只能针对SKU不能对着菜品级别操作否则会出现不同规格共享库存导致超卖。4.3 订单状态机的驱动力事件驱动 状态流转扫码点餐的订单状态比电商订单复杂因为它有已下单→已接单→制作中→已上菜→已完成这条线下链路中间还可能插入催单退菜超时未支付自动取消等异常操作。我用一张订单状态表记录状态状态流转全部通过OrderStatusEvent事件驱动用RabbitMQ异步执行后续动作核心状态机模型如下。当前状态触发事件目标状态执行动作PENDING_PAYMENTPAY_SUCCESSRECEIVED后厨推送、打印订单PENDING_PAYMENTPAY_TIMEOUTCANCELLED释放桌台、释放库存RECEIVEDKITCHEN_STARTPREPARING更新预计出餐时间PREPARINGDISH_READYDELIVERED叫号通知顾客DELIVEREDSETTLE_ACCOUNTCOMPLETED生成对账单状态流转不能散落在业务代码里我统一收口在一个OrderStateMachine类中每个合法转移都做前置校验防止脏数据把订单卡在一个进退两难的节点。这里要特别提醒支付成功的回调处理必须保证幂等即同一笔订单的支付成功事件重复消费不会导致状态重复流转。我在事件里引入了eventId去重表消费前先查一条一样eventId的记录有没有处理过处理过就直接ACK不做任何状态变更。4.4 超时未支付的订单处理延时消息与定时扫单国际版的顾客支付习惯不同有些国家的顾客下单后习惯慢慢选支付方式支付超时时间不能写死。我设置了一个可配置的支付超时时间默认15分钟。实现上用了三级保障第一级RabbitMQ的延迟消息插件在订单创建后发送一条延时消息到点检查是否已支付第二级Quartz每3分钟扫描一次处于待支付、时间超过阈值的订单做兜底取消第三级顾客主动取消接口直接释放资源。三级保障确保了即使某个环节出问题也不至于把桌台和库存扣住不放。关于RabbitMQ延迟消息有一点踩坑经验rabbitmq_delayed_message_exchange插件是把消息存在MnesiaErlang的分布式数据库里插入和读取性能远不如普通队列如果订单量很大会让Broker压力剧增。所以我只在OrderCreated事件上用延迟消息其他业务事件还是走普通交换机。后来测试高峰期订单创建几千笔时延迟插件所在Broker的内存和消息堆积明显偏高后来我调整了策略延迟消息只用于订单超时提醒5分钟以上的超时场景改用定时扫单兜底插件压力就降下来了。spring: rabbitmq: listener: simple: retry: enabled: true max-attempts: 3 initial-interval: 1000订单事件消费者我开启了重试机制。这里有个学习要点如果消费者处理消息时抛出异常不能简单无限重试否则会造成消息循环堆积甚至死信。配置如上最多重试3次仍失败进入死信队列由定时任务查库纠正状态。消息和数据库状态是两个独立系统最终要对账一致性绝对不能只靠消息驱动。5. 国际版高并发场景下的性能优化实践5.1 菜单缓存与热点数据隔离扫码点餐在午晚餐高峰期的特点非常明显短时间内大量顾客同时打开菜单菜品信息和图片请求量瞬间拉升。菜单数据是典型的读多写少我用Redis做了两级缓存第一级是本地Caffeine缓存过期时间60秒等于每个服务实例在本地留一份热点菜单第二级是Redis缓存过期时间5分钟负责多实例间的数据同步和穿透兜底。请求进来先查Caffeine不中再查Redis再回源查MySQL。这套机制有一个细节要注意菜单更新比如菜品下架、临时沽清需要主动淘汰缓存否则顾客看到的菜单和实际库存不一致。我在菜单更新接口里写了一个cacheService.evictMenu(restaurantId)方法先删除Redis里的菜单缓存再把本地Caffeine实例删除。单个实例删除本地缓存比较容易但有多个实例时得通过Redis Pub/Sub广播一个缓存的失效事件让其他实例也删。不然有的用户看到的是新菜单有的还是旧菜单在时差问题下体验很糟糕。5.2 高并发扣库存Redis原子操作 数据库兜底点餐系统和电商系统一样存在超卖风险但餐饮的库存模型更轻主要针对沽清每日限量菜品如例汤、特色甜点。我用Redis的Lua脚本做库存预扣原子性由Redis保证脚本逻辑是判断当前库存大于0就减一否则返回失败。同时落数据库用乐观锁版本号做兜底防止Redis数据丢失后重启恢复不一致。if redis.call(exists, KEYS[1]) 1 then local stock tonumber(redis.call(get, KEYS[1])) if stock 0 then redis.call(decr, KEYS[1]) return 1 end return 0 end return -1分布式环境下我可以更进一步做订单维度的防重同一个桌台、同一顾客、同一种菜品在30秒内的重复下单用Redis的SETNX加一个锁来拦截避免顾客手滑多点了几份。这个防重用后来看非常有效至少挡掉了很大比例的重复请求。5.3 订单通知的推送通道WebSocket与SSE分工国际版点餐前端是H5页面自然优先考虑WebSocket维持长连接但WebSocket在弱网环境里的自动重连、断线恢复处理比较麻烦。我的做法是按消息类型拆分面向点餐顾客的状态变化通知比如订单制作完成、可以取餐了用SSE单向通道服务端主动推给顾客代码简洁断线自动重连由浏览器原生能力处理面向顾客扫码后的实时聊天如果有才用WebSocket双向通道。这里有一个隐藏性能点SSE和WebSocket连接都属于长连接每个实例的连接数上限受Nginx和Tomcat配置影响。我在压测时发现默认Nginx没有配置超时时间时空闲的SSE连接会一直挂着限制并发能力。后来我把proxy_read_timeout设为60秒配合前端SSE的心跳重连逻辑连接数和稳定性都比较理想。线程模型上Tomcat的默认最大线程数是200每个SSE连接会占一个线程所以当在线顾客多的时候不能盲目开太多SSE连接我按餐厅ID做连接复用一个餐厅连接一个推送通道消息里带桌台标识进行广播。6. 部署与运维阶段踩过的坑多区域、支付回调与日志监控6.1 多区域部署与数据同步国际版自然要考虑多区域部署。我最初天真地以为部署在一个区域、全球访问就行结果东南亚的顾客打开欧洲节点的页面时菜单图片加载慢得让人抓狂。后来前端静态资源挂CDN核心API部署到两个区域一个主区域一个灾备区域MySQL做主从复制Redis跨区域只读副本。这里有一个一致性取舍跨区域同步数据有延迟所以我把订单创建强一致留在主区域菜单、餐厅信息这类低频变更数据通过MQ异步同步到其他区域的只读副本。有一个小的经验不同区域之间的数据库时区设置要保持一致统一UTC表结构变更要走Online DDL工具比如pt-online-schema-change否则在复制环境下添加字段可能锁表。我踩过一次直接ALTER TABLE加索引大表在从库同步时延迟飙升线上点餐查询慢得不行从那以后全部走gh-ost或者pt-osc。6.2 支付回调的幂等与防重Stripe、PayPal、Adyen这些支付网关的回调机制和国内支付平台大同小异但有两个额外痛点回调来源IP不确定、回调可能重复送达且不保证顺序。我在所有支付回调入口做了三件事验签用各自的Webhook签名机制、幂等eventId去重表、状态机校验只有待支付订单才能流转到已支付。另外支付回调接口必须返回200响应给支付网关如果业务处理成功前就直接返回200支付网关会认为投递成功丢失订单如果业务处理失败得要返回4xx来触发网关重试但要小心重试风暴所以重试次数和间隔要在网关后台配置好。我在开发时遇到过一个问题Stripe回调顺序不是严格按时间排序的比如payment_intent.succeeded事件先到charge.refunded事件后到两个事件处理同一个订单处理逻辑必须都是幂等的否则就会把已支付的订单又标记成已退款中间还经历了状态机拦截。后来单独写了一个callback_audit表把每个事件的原始Payload、处理结果、耗时都记录下来方便对账和排障。6.3 日志与监控的国际化陷阱多语言环境下日志里不能出现乱码这是基本要求。我所有应用日志文件统一UTF-8编码数据库连接串加了characterEncodingutf8RabbitMQ消息体强制JSON字符串UTF-8编码。以前我遇到过一个问题中文菜单名写入消息队列后消费者拿到的字符串末尾多了一个问号排查半天发现是生产者用的字符集是平台默认字符集在Linux下是UTF-8在Windows下是GBK后来强制在消息发送时指定StandardCharsets.UTF_8再没出现过问题。监控方面我用了Spring Boot Actuator暴露指标健康、线程、内存、缓存命中率、数据库连接池水位配合Prometheus抓取、Grafana展示。关键报警围绕三点订单支付成功率突降、支付回调积压数超过阈值、订单表数据量接近分表阈值。餐饮高峰期一过凌晨定时对账如果发现异常触发告警到值班群。这几种监控就够用了没必要一开始就上全链路追踪先把核心链路盯住。6.4 索引设计与慢查询治理一段实际优化实录系统上线运营两个月后发现顾客查看历史订单的接口越来越慢慢查询日志显示一条SQL扫了60多万行。这条SQL的问题是一个多月前埋下的WHERE restaurant_id #{restaurantId} ORDER BY created_at DESC LIMIT 20当时没建联合索引结果随着订单表数据量增长排序和过滤都全表扫描了。我加了一个联合索引(restaurant_id, created_at DESC)以后接口耗时从1.8秒降到40毫秒。这个案例想说的是索引设计一定要配合实际查询模式来列表页的筛选字段、排序字段都应该通过联合索引覆盖不要等到慢查询报警才去补救。再补充一条分页的坑如果订单量特别大用LIMIT 10000, 20这种深分页性能很差可以用游标分页代替。也就是上一页最后一条订单的时间戳作为下一页的查询条件避免扫大量无关行。这个优化对移动端下拉加载历史订单特别有效。最终这套系统上线稳定运行了大半年。从一台最小配置的云主机起步到高峰期扛过了一天几万的订单量。整体看下来国际版扫码点餐的难点不在单点技术而在业务理解和抽象能力。我在实际开发中的最大体会是做国际化项目第一个版本就要把语言、时区、币种当成一等公民来设计千万不要在中后期打补丁。刚开始多花一周时间把基础模型做扎实后面整体能省出一个月的返工时间。还有一点如果你也是自己做整个系统一定要留出足够的联调时间国际版的三方对接支付网关、CDN、消息推送、汇率API比国内版本多得多联调周期至少按国内版的1.5倍估。扫码点餐的脚手架代码不难找但每一家餐厅的菜单结构、后厨动线和支付习惯都不同真正值钱的不是那几行Java代码而是对业务的深入理解。希望这篇文章能帮你少踩几个坑把项目顺利做上线。