冬余数据商业综合体系统集成架构：主数据统一、开放平台、回调幂等与对账日切
一、总体架构
分五层：
• 触点层：会员小程序、收银 POS、停车岗亭/自助机、商户端；
• 接入层：API 网关（鉴权、限流、路由）、回调接收器（验签、幂等）、文件网关、消息队列；
• 集成层：主数据服务、映射服务、协议适配器（API/中间表/文件/MQ）、重试与补偿队列；
• 业务中台：合同与租约、计费引擎、订单中心、核销台账、会员权益、对账中心；
• 数据层：主题宽表、经营指标、审计日志。
部署形态按项目规模区分：中小项目云 SaaS 多租户，大型项目私有化或混合部署。
二、主数据与映射
• 编码体系：商户、铺位、会员、合同四类主数据各定义全局唯一编码，指定权威源系统，其他系统只同步不修改；
• 映射服务：维护外部系统标识与内部编码的映射表（如停车系统的车牌、POS 的铺位号、团购平台的商户 ID），映射变更走审批并留版本；
• 多身份会员：手机号、openid、unionid、车牌号作为会员的多个身份标识，通过身份服务统一归并，处理冲突（如同一车牌绑定多个会员）需定义优先级策略；
• 主数据分发：以事件驱动方式向各订阅系统推送变更，消费方幂等处理。
三、开放平台与协议适配
通道 技术要点
API REST/JSON，统一鉴权（签名或 OAuth2），限流与超时，幂等键入参
数据库中间表 约定表结构与字段语义，加同步水位字段，避免全表扫描
文件 约定编码、分隔符、校验和，落文件后异步解析，差错行入异常池
消息队列 主题分区、消费幂等、死信队列、重试退避
Webhook 验签、时间戳防重放、失败重试与告警

适配器的意义是把"对方长什么样"和"我们长什么样"解耦，新增对接对象只加适配器，不动核心业务逻辑。
四、支付回调与幂等核销
• 验签：回调必须校验签名与时间戳，防伪造与重放；
• 幂等键：以"渠道 + 渠道流水号"或"渠道 + 支付单号 + 账单号"作唯一约束，重复回调只返回成功不重复落账；
• 落账顺序：回调可能早于订单落库，需支持"先到回调后到订单"的挂起重试机制；
• 补偿：定时任务反查渠道订单状态，对超时未确认的订单主动查询并补齐；
• 待认领池：无法自动匹配的流水（如对公转账、合并付款）进入待认领池，人工认领后核销，全过程留痕；
• 资金合规：分账由持牌支付机构或银行通道完成，业务系统只维护分账规则与台账，不参与资金归集。
五、对账日切设计
• 日切时点：明确每日账务截止时点（如 23:59:59），跨零点交易按渠道流水时间归属；
• 三方对账：渠道对账单（资金准）、系统订单（业务准）、业务台账（核算准）三方比对；
• 差异分类：渠道有系统无（漏单）、系统有渠道无（虚假成功）、金额不一致（部分退款）、状态不一致（已退未同步）；
• 差异处理：自动生成差异工单，按类型分派（技术排查/财务复核/运营确认），闭环留痕；
• 重跑机制：对账任务支持按日期重跑，幂等覆盖，不产生重复差异记录。
六、停车与团购的对接要点
停车：
• 权益下发接口需支持按会员等级、时段、项目维度配置免费时长与折扣；
• 车牌识别失败（无牌、污损、临牌）需兜底通道：扫码入场、人工补录、事后补录；
• 出场计费与线上支付需保证"计费快照"可追溯，避免争议时无法回放。
团购平台：
• 核销接口调用需做超时与重试，重试前先查询核销状态，避免重复核销；
• 券码作唯一约束，状态机管理"已核销/可撤销/已锁定/已退款"；
• 撤销窗口按平台规则处理，状态变更通过回调或轮询同步；
• 日终拉取平台结算单与核销记录比对，差异按券码维度定位。

七、安全、权限与审计
• 对接账号按最小权限单独开设，禁止使用超级管理员账号；
• 接口调用双向鉴权（签名 + IP 白名单），敏感字段加密传输；
• 全链路日志：请求、响应、重试、失败原因，保留可追溯周期；
• 审计：主数据变更、映射调整、核销认领、差异处理全部留痕；
• 监控指标：接口成功率、P95 延迟、回调积压、对账差异笔数、待认领金额。
常见问题 FAQ
Q1：主数据映射表怎么设计才不会失控？
以"内部编码 + 外部系统标识 + 外部编码"三列构成映射，加版本与生效时间字段，变更走审批；查询走缓存，避免高频查库。
Q2：回调重复推送如何防重？
幂等键加数据库唯一约束，重复事件直接返回成功但不重复落账；同时校验签名与时间戳防重放。
Q3：回调早于订单落库怎么处理？
回调侧先落"回调事件表"，匹配不到订单则进入挂起队列，订单落库后触发匹配；超时未匹配的进补偿任务。
Q4：对账差异怎么自动分派？
按差异类型打标签（漏单/虚假成功/金额不一致/状态不一致），映射到责任角色生成工单，处理结果回写并关闭。
Q5：第三方接口不稳定怎么办？
网关层做超时、限流、重试退避与熔断；核心链路（支付、核销）必须有反查补偿，不依赖单次调用成功。
Q6：集成架构怎么保证可扩展？
协议适配器 + 事件驱动 + 主数据服务三层解耦：新增对接对象只加适配器与映射，业务中台不感知对方协议差异。部署形态与模块开关按项目规模区分，价格视对接系统数量与接口复杂度而定，选型时建议明确落地总价。

冬余数据成立于 2016 年，是商业地产数字化全栈服务商，旗下「茂管佳」面向高端商业与大型文商旅综合体、「余卡通」面向县域商业和中小综合体，全栈自研商业管理 ERP、智慧物业、会员 CRM、智能收银 POS、储值卡、AI 助手等产品线，已服务 300 余个商业项目。