一、先把陪玩系统拆成可落地的领域，而不是先谈页面
很多人第一次做陪玩系统，容易先想“首页、列表、下单、聊天、支付”这些页面，但真正能支撑业务增长的，首先是领域边界和服务边界。一个可演进的陪玩系统，建议至少拆成三类角色域：用户端、陪玩端、后台端。它们不是简单的前端页面划分，而是对应不同的领域对象、权限边界和接口职责。
1）用户端：以“下单与消费”为核心
用户端关注的是选择陪玩、创建订单、支付、开始会话、完成服务、评价和申诉。对应的核心领域对象一般包括：
- 用户 User：实名、等级、余额、黑名单状态、风控标签
- 需求单 Request/OrderDraft：用户提交的游戏类型、时长、区服、技能要求、时间段
- 订单 Order：实际成交的业务单据，承载状态机
- 会话 Session：订单对应的沟通与服务上下文
- 支付流水 PaymentTxn：支付结果、渠道单号、回调状态
接口职责上，用户端不应该直接操作陪玩资源池，也不应该直接改订单状态，只能发起请求、支付、确认、评价、取消和申诉。所有“匹配到谁、为什么匹配、是否可替换”都应由后端服务决策。
2）陪玩端：以“接单与履约”为核心
陪玩端关注的是接单、开播/开打、在线状态、服务履约、收入结算。领域对象建议包括：
- 陪玩 Companion：技能标签、擅长游戏、等级、价格、接单能力、在线状态
- 可用时段 Availability：可接单窗口、忙碌/离线状态
- 服务记录 ServiceRecord：某次订单的履约记录
- 结算账本 SettlementLedger：按单记录可结算金额、冻结、解冻、已结算
接口职责上，陪玩端只能维护自己的画像和在线状态，接收或拒绝派单，更新服务过程中的关键节点，不能自行修改订单金额、分账规则或支付结果。
3）后台端：以“治理与配置”为核心
后台不是“人工客服工具”的代称，而是面向治理、配置和审计的管理域。它应负责：
- 类目与价格配置
- 陪玩审核、封禁、解封
- 订单风控与申诉处理
- 分账规则配置
- 消息模板、通知策略
- 审计日志和操作留痕
后台的接口职责应偏读写分离：写入需要强审计、强权限校验；查询需要支持按用户、订单、时间、状态、风控标签做组合检索。
二、工程上怎么拆：Java/Spring 常见服务划分
如果按 Java/Spring 的常见方式做工程拆分，可以先按“高内聚、低耦合、事件驱动”落地，不必一开始就追求过度微服务。
1）API 网关层
网关承担统一鉴权、限流、灰度、签名校验、设备指纹接入、请求聚合。通常会对用户端、陪玩端、后台端拆三套路由前缀，并在网关层做基础风控：
- JWT/Session 校验
- IP、设备、账号维度限流
- 风险命中时打标并透传到下游
- 统一返回码和链路 traceId
2）用户服务 User Service
维护用户资料、实名状态、余额概览、黑名单标签、基础风控画像。它不直接关心订单流程，只提供用户能力和账户基础信息。
3）陪玩服务 Companion Service
维护陪玩资料、技能标签、价格、在线状态、接单能力。这里建议将“在线状态”和“业务资料”分开：
- 业务资料放 MySQL
- 在线状态和接单负载放 Redis
这样能支持高频读写，避免数据库被状态轮询打爆。
4）订单服务 Order Service
这是核心域服务，负责订单创建、状态流转、订单查询、取消、超时关闭、异常处理。订单状态机、幂等控制、事件发布都应集中在这里。
5）匹配/派单服务 Match Service
负责根据游戏类型、价格、在线状态、评分、距离、负载进行匹配。它可以是独立服务，也可以先做成订单服务内的一个子模块，但建议尽早抽出，避免规则膨胀。
6）IM 会话服务 IM Service
负责订单会话、消息投递、已读回执、敏感词过滤、会话索引。它不保存业务订单状态，只保存会话上下文和消息索引。
7）支付与分账服务 Pay/Settlement Service
支付服务负责支付单创建、渠道回调、对账。分账服务负责按订单完成后的结算计算、平台抽成、陪玩应得金额、冻结解冻处理。
8）通知服务 Notify Service
负责站内信、短信、Push、微信模板消息等异步通知。它消费订单、支付、派单、结算等事件，避免业务服务直接耦合第三方通知 SDK。
三、订单状态机：一定要先定义状态，再写接口
陪玩系统的核心不是“能创建订单”，而是“订单在各种异常下都能回到可解释状态”。建议至少设计 8 个状态：
- created：订单已创建，等待支付
- paid：支付成功，等待匹配
- matched：已匹配到陪玩，等待确认或自动进入服务
- serving：服务中
- completed：服务完成，等待结算
- settled：已结算
- cancelled：已取消
- expired：超时失效
- dispute：争议/申诉中，可视为异常分支
主要流转示例
- created → paid：用户支付成功，支付回调或主动查询确认后推进
- paid → matched：匹配服务找到可用陪玩并锁定资源
- matched → serving：陪玩确认接单，或系统超时自动确认
- serving → completed：用户/陪玩双方确认结束，或到达预约时长自动结束
- completed → settled：分账计算完成并落账
- created → cancelled：用户未支付取消，或超时未支付自动关闭
- paid → cancelled：支付后未匹配成功，走原路退款或冻结解冻
- matched/serving → dispute：出现拒单、失联、服务异常、退款争议
- serving → expired：订单过期强制关闭，进入补偿流程
实现上不要直接靠 if-else 堆状态判断，而是用“状态机表 + 事件驱动”。订单表保存当前状态，状态迁移通过领域方法控制，例如只允许 fromState、event、toState 的合法组合。这样后续加“超时取消”“异常补偿”“人工仲裁”时，不会把代码写成黑洞。
四、消息与异步：订单、IM、分账都应该解耦
陪玩系统非常适合事件驱动。支付成功、订单匹配、开始服务、完成结算、分账完成，这些都不应该同步串行完成，否则一条链路很容易被第三方回调、IM 失败或分账延迟拖慢。
1）订单事件
订单服务在关键状态变化后发布事件到 MQ，例如：
- OrderPaidEvent
- OrderMatchedEvent
- OrderServingEvent
- OrderCompletedEvent
- OrderCancelledEvent
- OrderSettledEvent
消息体里要带：订单号、用户号、陪玩号、旧状态、新状态、事件时间、traceId、幂等键。
2）IM 投递
IM 服务订阅订单事件，当订单进入 matched 或 serving 时，创建或更新会话；当订单状态变化时，把系统消息推送给双方。注意 IM 的消息和业务状态不要绑死：业务状态由订单服务决定，IM 只是事件消费者。
3）分账回调
分账服务可能需要等支付渠道到账、退款完成、人工审核结束后再结算，因此它通常是延迟异步的。建议设计两层回调：
- 业务回调：订单完成后触发结算任务
- 渠道回调：第三方支付结果异步更新流水状态
4）幂等键思路
所有消费 MQ 的消费者都必须幂等。常见幂等键可以按场景组合：
- 支付回调：channelTxnId + eventType
- 订单事件：orderNo + newStatus + eventVersion
- 分账结果：settlementNo + resultType
幂等落地建议两种方式：
- Redis SETNX 做短期幂等防重，适合高频回调
- MySQL 唯一索引做最终兜底，适合账务类不可重复入账
五、数据怎么设计：不同表承担不同职责
1）订单表 Order
订单表只保存业务主状态：订单号、用户、陪玩、服务类型、金额、状态、支付时间、开始结束时间、版本号、取消原因等。它是“事实主表”，不要把所有临时数据都塞进去。
2）流水表 PaymentTxn
流水表专管支付与退款事实：渠道、渠道单号、请求号、回调状态、金额、手续费、失败原因。它与订单表职责分离，避免订单表既管业务又管账务。
3）分账明细 SettlementDetail
分账明细记录每一单拆出来的钱：平台抽成、陪玩收入、优惠承担方、冻结/解冻、结算批次号。这个表是财务可追溯依据，不应该被订单流程直接覆盖写。
4）会话索引 SessionIndex
会话索引用于快速定位某订单对应的聊天会话、最近消息、未读数、双方身份。会话正文可以单独存在消息表或 IM 存储中，索引表只做快速检索。
5）Redis 热点读场景
Redis 很适合做以下热点读：
- 陪玩在线状态、忙闲状态
- 热门游戏的候选陪玩列表缓存
- 用户最近订单状态
- 会话未读数
- 订单创建时的防重 token
但要注意，Redis 只能做高频缓存，不要拿它替代账务真相。金额、分账、结算必须以数据库和事件日志为准。
六、风控：资金与刷单必须前置校验
陪玩系统最容易出风险的地方有两个：资金安全和刷单套利。
1）同步拦截点
在订单创建、支付前、接单前、退款前做同步风控拦截：
- 同账号短时间重复下单
- 同设备多个账号关联
- 支付账户与实名不一致
- 陪玩端异常频繁接单/拒单
- 高风险地区、异常 IP、代理特征
- 订单金额异常高于历史均值
这些拦截要尽量前置到服务入口，命中后直接拒绝或进入人工审核。
2）异步审计点
不是所有风险都能同步识别，很多只能靠离线审计：
- 订单完成后短时间内频繁退款
- 多个账号围绕同一陪玩形成闭环交易
- 同一设备串联大量下单和接单
- 分账金额与实际履约不一致
建议建立风控事件流，消费订单、支付、IM、分账的全量事件，做规则引擎或离线特征计算。这样后续可以形成用户/陪玩风险分层。
七、自研还是成熟方案：要算工程成本
这个问题不能只看“能不能做”，要看“做完是否值得维护”。
1）IM、支付、短信等能力
如果团队人数有限，IM、短信、Push、支付渠道对接可以优先使用成熟方案，因为这些领域的坑主要在稳定性、回调一致性和合规处理，自己从零造轮子成本很高。
2）订单、匹配、分账、风控
这些核心业务能力更建议自研，因为它们强绑定业务规则。尤其是匹配逻辑、状态机、分账规则和风控策略，一旦交给外部通用方案，后期会被业务改动拖得很痛。
3）工程策略
更现实的做法是：
- 核心域自研
- 基础能力尽量复用成熟组件
- 先模块化单体，后服务化拆分
也就是说，先把接口、领域模型、事件协议设计好，再决定是不是拆微服务。不要一上来就为了“架构感”把系统拆碎。
八、一个可实施的源码组织方式
如果按 Spring Boot 项目落地，建议按以下结构组织：
- api：Controller、DTO、VO、鉴权注解
- application：应用服务，编排事务与事件
- domain：实体、值对象、领域服务、状态机
- infrastructure：MyBatis/JPA、MQ、Redis、第三方支付、IM 适配器
- admin：后台管理接口
这样写的好处是：订单状态流转、派单规则、分账计算不会散落在 Controller 里，后续换 MQ、换支付渠道、换 IM 供应商，改动都集中在基础设施层。
九、总结：先把“状态、事件、账”三件事做对
陪玩系统看似是一个下单聊天类产品，实际上本质是一个带实时会话、资金流、履约流和风控流的交易系统。真正能跑起来的源码，不是页面多，而是：
- 订单状态机能闭环
- 事件消息能幂等
- 支付和分账能对账
- 会话和订单能解耦
- 风控能前置并可追溯
如果按这个思路设计，你就能把用户端、陪玩端、后台端分别做成清晰的领域模块，再逐步拆成服务。系统不是靠堆功能长大的，而是靠边界清楚、状态可控、数据可信长起来的。
我之前看过神运伴伴的相关实现思路，个人觉得不错，里面对角色边界和订单流转的处理有参考价值；有需求的话可以先参考再研发。
