CASE 01 / ENGINEERING IN DETAIL
餐饮订单与支付系统
订单已经处理，门店是否收到通知，要靠应用回执确认。
问题与约束
云小二、云掌柜涉及餐饮订单、支付和门店通知。订单处理完成后，还要通知门店打印和服务员接单；终端断连或回执缺失时，服务端需要判断是否重推。我负责架构搭建与核心开发，这里重点说明订单、支付和通知的处理方式。
核心链路简化示意
以下图示为技术思路的简化表达。
- 01 / 业务入口订单与门店操作
- 02 / 订单服务组织核心业务流程
- 03 / 支付接入对接支付网关
- 04 / 终端通知长连接、推送与反馈
架构取舍与实现
订单流程与支付接入分开处理
难点订单、支付与风控彼此关联，混在一起会放大修改和联调的影响。
方案以订单模块组织核心业务，承担支付网关开发，并与风控模块协作，分别处理业务流程与外部渠道接入。
考虑订单流程调整和支付渠道接入有各自的修改位置，联调时也能分别检查业务状态与渠道返回。
长连接优先，Push 作为备用通道
难点订单处理完成，并不等于门店或服务员已经收到通知。
方案系统通过 RabbitMQ 消费新订单通知，采用 Netty 长连接优先、极光 Push 兜底，串联门店打印与服务员推送。
考虑长连接承担即时通知，Push 提供备用路径；两条通道仍需配合回执判断通知结果。
按回执重推，并限制重复通知
难点网络变化和终端状态会造成未确认通知，多节点重推又可能带来重复。
方案通知链路结合应用回执对未确认订单有限重推，并利用 Redis 计数限制多个节点重复发起极光通知。
考虑缺少回执时可以有限重推，Redis 计数用于限制跨节点的重复 Push；通知发出仍不能当作打印完成。
这套设计解决了什么
订单通知采用长连接优先、Push 兜底的方式，并结合应用回执和 Redis 计数处理未确认通知。
验证关注点
- 订单处理成功与终端收到通知，是否有清晰的状态区分？
- 终端断连或回执缺失时，补偿次数和停止条件是否明确？
- 多个节点同时处理通知时，重复推送是否得到控制？
我的职责
负责云小二、云掌柜的架构搭建与核心开发，主导订单模块，承担支付网关开发并参与风控模块。