郑州商城APP开发 线上交易+线下核销打通郑州新零售经营链路

      上线郑州商城的那段日子，我先从业务痛点切入：线上下单与线下核销割裂，库存、优惠与结算常常不同步。项目要求是“线上交易+线下核销打通新零售链路”，听着简单，做到无缝就不简单了。我偏向先把场景拆成三类：交易撮合、门店验收、线下实时库存，这样设计更便于技术拆分与风险隔离。

      后端选型落脚在Spring Boot + Spring Cloud（Nacos做配置与服务发现）配合Seata处理分布式事务，消息中间件用RocketMQ实现订单与核销事件的最终一致。实践里我更倾向于把核心支付流程放在同步链路，使用幂等键与本地事务-消息表结合，避免直接在MQ上做主事务，这样排查回滚时要清晰很多。

      离线核销是关键：门店端采用轻量级Flutter或原生混合方案，扫码核销使用一次性动态二维码（包含订单ID、时间戳与HMAC签名），扫码端校验签名并通过gRPC向核销服务确认。现场实现时遇到网络抖动，我选择在门店端加入SQLite作本地队列，后台有冲突解决策略（基于版本号的乐观锁与补偿事务），经验告诉我：离线优先设计比事后补救可靠得多。

      数据同步则用Debezium做MySQL CDC，把订单、库存变更流入Kafka再写入Redis与ElasticSearch。曾因表结构变更导致消费者挂掉，教训是：先做schema治理，使用兼容性变更，且在CI里加入Kafka contract测试。我的做法是用GitLab CI + Docker镜像，Kubernetes上用Helm管理，ArgoCD做持续交付，回滚路径必须预演。

      可观测性不可省：Prometheus + Grafana抓指标，Jaeger做调用链，ELK收集日志。调试线上订单错单时，我经常用trace id展开链路，结合kubectl port-forward和scp日志片段，快速定位是MQ重复投递还是数据库写入超时。实操感悟：越早让链路打上trace id，排查越省力。

      支付与结算环节需要兼顾合规与稳定：接入银联、微信支付、支付宝，各自有异步回调与对账窗口。我在实现里加了专门的对账微服务，使用时间窗批处理和幂等校验，异常单触发人工复核流程。小提示：证书管理与回调重试策略常常被忽视，生产环境会出问题。

      前端方面，除了移动端App，我建议同步做微信小程序，门店端则做一个轻量管理端。接口采用REST给前端，gRPC用于微服务间高效通信；同时启用HTTP/2与gzip减小延迟。实践中发现，接口文档和Mock比抽象设计更有用——反复迭代比一次性完美更现实。

      收尾不做空泛总结：我倾向于先把最危险的边界（支付、库存冲突、核销幂等）做硬性保障，再优化体验。技术栈会随实践调整，但设计原则不变：可观测、幂等、可回滚。最后给一句实操建议：把故障复现步骤写清楚，自动化演练几次，问题就不会反复出现。