县城外卖怎么上云：稀疏运力下的订单-运单解耦与腾讯云拼装

问题从哪来：县城外卖把稀疏运力与对账约束拧在一起

同城外卖可以把「运力」当成城市骑手池，「地址」当成道路坐标连续空间。县城外卖不是缩小版同城：商圈稀疏、单量脉冲靠午晚两峰撑、商家自送与众包混编、地址常不规范、结算账目比轨迹炫技更影响续约。失败形态高度集中——派不出去、送超时、账对不清——背后往往是同一类工程缺口：订单与运单耦合、调度只有指派没有抢单回退、片区没有分片边界、接入层无限流、支付回调与通知同事务、结算表缺审计字段。

本文按云上工程边界拆：领域分层与腾讯云组件选型、订单与运单状态机、片区分片与指派+抢单、表结构草图、REST/事件接口、高峰时序、幂等支付退款、失败模式与观测。不讨论首页怎么好看，也不讨论采购或商用交付；只讨论系统怎么在稀疏运力下算得清、派得动、结得明。县城外卖的工程目标是「稳态 + 可对账」，不是「微服务拆到每个人工一服务」。

县城外卖订单与运单解耦

领域分层：先画边界，再点名组件

县城外卖建议按域切开，而不是按「小程序页面」堆接口。一层逻辑对应一类扩展与一类故障面：

小程序或 H5 前端可用 CloudBase 静态托管与云开发能力做轻量落地；核心交易、调度与结算建议放到云托管（容器），便于按午晚高峰水平扩展。县城日单量通常远低于一线商圈，默认单地域、可备份、可只读副本，不要为了「看起来像大厂」拆成十余个微服务。订单热点表与历史归档分表，避免月末结算报表拖垮在线库。

硬约束三条：

1. 订单与运单解耦——商家接单不等于运力已锁定；自送与平台运力可在同一订单上切换路径，但状态机要分开。
2. 下单主路径同步、通知与积分异步——不要把订阅消息写进支付回调的同一同步链。
3. 结算以单据与流水为准——佣金、服务费、异常扣款必须可导出、可审计，不能靠群聊截图对账。

订单与运单状态机：先画转移，再写接口

县城外卖的核心对象是「订单实例 + 运单实例」，不是「商家工作台截图」。订单状态建议至少覆盖：

运单（waybill）建议独立状态机，与订单用事件对齐，禁止骑手端直接 UPDATE orders SET status：

自送路径：商家端可创建 fulfill_mode=MERCHANT_SELF 的运单，状态从 ACCEPTED_BY_RIDER（商家自身）直接进入取送，跳过开放抢单；平台众包则走指派+抢单回退。两条硬约束：

1. 转移必须带原因码与操作者（用户取消、商家拒单、支付超时、调度超时、骑手上报联系不上）。裸改状态字段无法复盘「单去哪了」。
2. 取餐、送达、退款动作必须幂等。弱网下骑手重复点「已取餐」「已送达」非常常见；同一 waybill_id + action + idempotency_key 重放应返回同一业务回执。

EXCEPTION 与 OPEN_GRAB 是县城特有、最容易被省略的中间态：若只有「指派成功/失败」两态，无人接单、地址别名对不上、电话打不通都只能塞进备注，调度与客服无法自动化。

片区分片与指派+抢单：稀疏网络的调度骨架

县城不要按「全市最短路」做实时轨迹炫技，先按片区（小区聚合点 / 餐饮街 / 乡镇街道）做 geo shard。推荐模型：

1. 片区字典 district：district_id、中心点、服务半径或多边形、营业时段、预计送达区间（诚实区间，不是虚假准时宝）。
2. 地址归一：下单优先选小区字典 + 楼栋/门牌备注，禁止纯自由文本作为唯一履约坐标；别名表由运力主管维护。
3. 下单时锁定 district_id：后续调度、限流、运力池、结算统计都按片区维度，而不是事后用经纬度猜。
4. Redis GEO：骑手上报位置写入 GEOADD rider:geo:{district_id}；指派时按片区集合 GEORADIUS 取候选，避免全市扫。
5. 调度策略：先指派（权重：距离、当前负载、完单率、新手保护量）→ 超时未接 → 同片区 OPEN_GRAB → 仍无人 → EXCEPTION 进人工台。不要无限自动扩半径把空驶成本打穿。

指派事件与抢单事件分开：waybill.dispatch.assigned、waybill.dispatch.open_grab、waybill.dispatch.accepted、waybill.dispatch.timeout。抢单用短事务或 Redis 分布式锁（SET grab:{waybill_id} rider_id NX EX）保证一单一人；落库后再 ACK 队列消息。

成本感知：片区数少时，调度服务可以与交易服务同进程不同模块；片区与日单起来再拆。单地域部署足够覆盖绝大多数县城外卖场景，跨地域多活是伪需求。

片区分片下的指派与抢单

表结构草图（可单体，边界按域切开）

早期可单体部署，表与接口按域切开，后续拆服务少搬家。

订单 county_order

• id, county_id, district_id, user_id, merchant_id
• fulfill_mode（PLATFORM / MERCHANT_SELF）
• address_id, address_snapshot（结构化小区 + 备注）
• status, pay_amount, paid_at
• eta_from, eta_to（预计送达区间）
• idempotency_key, version

订单行 county_order_item

• order_id, sku_id, qty, price_snapshot

运单 waybill

• id, order_id, district_id, rider_id（可空）
• status, dispatch_mode（ASSIGN / GRAB / SELF）
• assigned_at, grab_open_at, accepted_at, picked_at, delivered_at
• exception_code, exception_note
• version

片区 district

• county_id, name, center_lat, center_lng, radius_m 或 polygon_json
• eta_minutes_min, eta_minutes_max, active

小区字典 community

• district_id, name, aliases_json, gate_note

结算 settlement_bill / settlement_line

• 账单头：merchant_id 或 rider_id, period_start, period_end, status（DRAFT / CONFIRMED / PAID_OUT）
• 明细行：order_id, waybill_id, gross_amount, commission, service_fee, penalty, net_amount, reason_code
• 导出字段与后台「本周应付」对齐，避免月末手工拼表。

审计 order_audit_log

• order_id / waybill_id, from_status, to_status, reason_code, operator, at

索引至少覆盖：(district_id, status, created_at)（片区拉单/调度）、(merchant_id, status, created_at)（商家拉单）、(rider_id, status)（骑手端）、(user_id, created_at)（我的订单）、(status, grab_open_at)（抢单超时扫描）、(merchant_id, period_end)（结算）。

REST 与事件契约（草图）

用户端 / 商家端 / 骑手端打到同一后端，用角色鉴权拆开：

POST /api/v1/orders                         # 创建订单，Header: Idempotency-Key
POST /api/v1/orders/{id}/pay-callback       # 支付回调（验签后投递队列）
POST /api/v1/orders/{id}/accept             # 商家接单
POST /api/v1/orders/{id}/ready              # 出餐 → 触发运单创建/调度
POST /api/v1/waybills/{id}/assign           # 调度指派（系统或人工台）
POST /api/v1/waybills/{id}/open-grab        # 开放抢单
POST /api/v1/waybills/{id}/grab             # 骑手抢单，幂等
POST /api/v1/waybills/{id}/pickup           # 取餐，幂等
POST /api/v1/waybills/{id}/deliver          # 送达，幂等
POST /api/v1/waybills/{id}/exception        # 上报异常进人工台
GET  /api/v1/merchants/{id}/orders:pull     # 商家批量拉单
GET  /api/v1/riders/me/waybills:pull        # 骑手按片区拉单
POST /api/v1/refunds                        # 发起退款（幂等键）
GET  /api/v1/settlements/{id}/export        # 结算导出

领域事件（TDMQ/CMQ Topic 示例名）：

• order.paid
• order.accepted
• order.ready
• waybill.created
• waybill.dispatch.assigned
• waybill.dispatch.open_grab
• waybill.dispatch.accepted
• waybill.dispatch.timeout
• waybill.picked
• waybill.delivered
• waybill.exception
• refund.succeeded
• settlement.period_closed

支付回调只做验签、落库「已支付意图」、投递 order.paid；真正的接单通知、运单创建、订阅消息由消费者处理。午晚高峰回调堆积时靠队列削峰，保证最终一致，而不是把网关线程拖死。

高峰时序：限流、片区调度、批量拉单、结算异步

假设场景：11:30–12:30 与 17:30–19:00，两三个热门片区单量脉冲，商家自送与众包混编。推荐主路径时序：

1. 接入层：API 网关对 POST /api/v1/orders 做县域级令牌桶 + 用户级配额；超限返回业务码 RATE_LIMITED 与可读文案，而不是裸 5xx。静态菜单与片区配置走 CDN/Redis，避免首屏把下单接口一起打爆。
2. 创建订单：校验商家营业态、片区可配送、地址合法性 → 写 CREATED → 返回支付参数。幂等键：user_id + merchant_id + cart_hash + 时间窗。重复提交返回同一 order_id。
3. 支付回调：验签 → 标记支付意图 → 发 order.paid → 快速 200。消费者推商家、写审计。
4. 商家侧：高峰不用「一单一推爆炸」；商家端轮询或长轮询 orders:pull，支持批量接单。可暂停接单并写入预计恢复时间。
5. 出餐与运单：ready 后按 fulfill_mode 创建运单；平台运力走指派，超时转抢单；自送运单绑定商家账号。
6. 骑手侧：按 district_id 拉单与上报位置；pickup / deliver 幂等；异常码标准化（ADDR_UNCLEAR、PHONE_UNREACHABLE、USER_REJECT）。
7. 结算：日终或周结任务扫 DELIVERED / REFUNDED 生成 settlement_line，不在送达回调里同步算佣金，避免高峰把结算逻辑打进关键路径。

云上拼装示例（按需取舍，不是清单式硬广）：接入用 API 网关限流；交易与调度跑云托管；尖峰消费者、超时扫描、结算任务用云函数订阅 TDMQ；菜单/售罄/片区 GEO 进 Redis；订单、运单、结算进云数据库 MySQL；商品图与售后图进 COS；网关 4xx/5xx、下单成功率、队列堆积、无人抢单率、退款失败率进 CLS 告警。CloudBase 适合快速搭管理端或原型；一旦调度状态机与结算复杂度上来，核心路径放到可水平扩的云托管更可控。

幂等支付与退款：双花和对账事故都出在这里

支付与退款是县城外卖续约的底线——商家更关心「什么时候能打到钱、扣了什么」，用户更关心「退款有没有到」。工程上最少保证：

1. 下单幂等：Idempotency-Key 落地唯一索引；冲突时查原单返回。
2. 支付回调幂等：按支付平台 transaction_id 去重；已处理直接 ACK。
3. 退款幂等：refund_request_id 唯一；部分退按行项目回滚，避免整单释放导致可售虚高或重复赔付。
4. 送达/取餐幂等：已是目标状态则返回成功回执，而不是「状态不允许」的假冲突。
5. 结算防重：同一 order_id + fee_type 在 settlement_line 唯一；退款成功发 refund.succeeded，结算消费者冲正对应行，而不是手工改库。

失败模式要提前写进手册：支付成功但 order.paid 消费者失败 → 靠队列重试与对账任务；退款渠道成功但本地状态未收敛 → 对账任务以渠道账单为准回写；指派成功但骑手 App 未收到 → 以服务端状态为准，客户端拉单和解；Redis GEO 骑手点漂移 → 调度仍以片区归属为主、距离为辅，避免跨片区乱派增加空驶。

失败模式、观测与单地域容量

观测（CLS 等）建议分级：

• P1：下单成功率骤降、支付回调失败率、退款失败率、队列死信
• P2：接单延迟、调度超时率、无人抢单率、异常单占比
• P3：慢 SQL、结算任务积压、COS 上传失败、片区 GEO 上报缺失

容量与成本：单地域起步；云托管副本按午晚定时扩缩，闲时缩到保底；数据库规格按 P99 下单与结算任务峰值选型，而不是按「未来全县开通」提前买大型号。监控先保下单、支付、接单、调度、退款五条链路，再谈漂亮的大盘。

安全侧：退款/改价/结算确认审计；管理端角色拆分商务、运力主管、值班客服、只读财务；演练伪造 district_id 下单、越权接单、刷抢单。后台权限按角色裁剪，避免人人都能改价退款。

稀疏运力下的失败模式与观测

上线前最低测试矩阵

1. 同一 Idempotency-Key 重复下单（不双建单）
2. 支付回调重复投递（状态仍一致）
3. 回调堆积时下单与接单仍可用（消费者可水平扩）
4. 指派超时自动转抢单，抢单并发只有一人成功
5. 骑手重复「取餐」「送达」（幂等）
6. 异常码上报进入人工台并可改派
7. 自送与平台运力在同一商家下切换路径，状态机不串
8. 部分退款冲正结算行，导出金额与明细一致
9. 跨片区地址校验拒绝、别名命中正确片区
10. 伪造片区参数、越权接单、越权确认结算

常见工程坑：订单状态直接当运单用，导致自送与众包无法并存；只有指派没有抢单回退，稀疏运力下大量出餐积压；预计送达写成定点而不是区间，客诉无法用规则消化；把订阅消息与结算计算写进支付/送达同步链；UTC 与业务时区混用导致日结切日错乱；小区自由文本导致骑手电话轰炸。把这些写进运维手册，成本远低于第一个旺季客服救火。

小结

县城外卖在工程上要优先保证四件事：订单/运单状态机可审计且解耦、片区 geo shard 下的指派+抢单可回退、接入层可限流、支付与通知用消息队列削峰并让结算可对账。小区字典、异常人工台、结算明细与冲正事件，是稀疏运力下续约的底座；API 网关、云托管、云函数、TDMQ/CMQ、Redis（含 GEO）、云数据库 MySQL、COS、CLS，以及可选的 CloudBase，是按边界拼装的零件，用「例如」对齐能力即可，不必绑死单一产品口号，更不必为了架构展览拆微服务。UI 与运营位是触达手段；派不动、送不明、账不清的系统，菜单再漂亮也只是把故障放大。先把两三个片区的状态机、调度回退与周结跑稳，再复制到下一片区，才是可持续的扩展方式。