实践系列：分销平台的技术架构

0. 目标

16年初，在美团主导建设的猫眼演出业务的分销平台，其中涉及订单交易部分，是电商业务下的典型场景。最近主导支付技术团队建设，在技术氛围建设方面，组织一些列的团队内部分享，拿这个 case 分享一下。

Note：整理有一个 keynote 版本，当时一起进行系统建设的另一个师兄 & 好友小宇，现在阿里。

备注：当前 blog 中说的分销平台，本质也是其他业务场景的开放平台。

1. 概要

背景：
- 为扩大销量，引入下游「分销商」，准备自建分销平台
- 分销平台作为基础服务，支持下游渠道接入
- 对外开放资源的同时，要求做好「系统安全」和「资源权限」管理
难点与挑战：
- 订单设计：订单状态含义要清晰内聚，而且状态流转可控
  - 出票接口幂等：避免针对同一订单重复出票
  - 掉单问题：出票之前 fail fast 策略提升用户体验，出票采取「协商策略」减少掉单
- 应收结算：订单状态流转，能够支撑对下游分销商的应收款收取和对上游资源方结算单的结算
- 系统安全控制：账号权限、资源权限、权限时效控制

转存失败重新上传取消

2. 分销平台：架构&细节

几个方面：

功能模块：为了满足需求，同时，能够进行落地开发，功能的边界拆分.
业务架构：整体业务边界和范围
关键要点：落地实现的细节

2.1. 功能模块

分销平台，主要功能模块：

数据分发：向分销商分发基础数据
账号管理：只有指定账号才能获取数据资源
权限管理：不同账号的资源权限粒度不同
订单管理：订单状态伴随用户下单、出票过程流转
对接结算：根据订单状态和退款记录，生成结算单

转存失败重新上传取消

2.2. 业务架构

为了满足业务需求，围绕上述的功能模块分析，分销平台的业务架构：

转存失败重新上传取消

2.3. 关键要点

几个方面：

领域模型
订单系统
应收结算：资金沉淀
系统安全：接口验签 + 时间窗口

2.3.1. 领域模型

分销平台的领域模型设计：

转存失败重新上传取消

领域模型的落地细节：

转存失败重新上传取消

2.3.2. 订单系统

订单系统，涉及几个要点：

订单状态拆分：
- 配送状态：物流状态
- 下单出票状态
接口幂等：相同的下单出票请求，只会触发一次真正的下单出票
组合策略：降低掉单率
- Fail Fast ：出票之前，通常用户未付款，采取快速失败策略
- 协商策略：出票过程中，如果不确定是否成功，就进入协商状态（fail cache）
- 补偿策略：资源方退票时，为保证结算周期的精确，记录退票操作记录，系统容错性、可用性
结算、应收逻辑：根据明确的订单状态，生成结算流水和应收流水

2.3.2.1. 订单状态拆分

转存失败重新上传取消

订单状态拆分之后：

配送状态
下单出票状态

带来的好处：

配送之后的订单，在极端情况下，仍可以进行「退票」等操作

a.配送状态:

转存失败重新上传取消

b.下单出票状态:

转存失败重新上传取消

2.3.2.2. 组合策略：极致优化掉单率

为了极致优化掉单率以及提升资金沉淀，采用组合策略：

Fail Fast ：出票之前，通常用户未付款，采取快速失败策略
协商策略：出票过程中，如果不确定是否成功，就进入协商状态（fail cache）
补偿策略：资源方退票时，为保证结算周期的精确，记录退票操作记录，系统容错性、可用性

转存失败重新上传取消

2.3.3. 应收结算：资金沉淀

特别说明：

设计订单的时候，不仅仅是设计订单，在设计阶段，考虑应收和结算的逻辑

应收和结算原则：

在指定的应收结算周期内，完成流水核对
资金沉淀：应收 >= 结算

应收和结算时间基准：

应收：
- 正流水：
  - 订单状态为：LOCKED、CANCELED、FIXING、FIXED、REFUNDING、REFUNDED、REFUND_FAIL
  - 结算周期的时间基准：下单成功时间
- 负流水：
  - 订单状态为：CANCELED、REFUNDED
  - 结算周期的时间基准：
    - 分销商退票成功时间
    - 如果没有退票成功时间，以取消成功时间为准
结算：
- 正流水：
  - 订单状态为：FIXED、REFUNDING、REFUNDED、REFUND_FAIL
  - 结算周期的时间基准：出票成功时间
- 负流水：
  - 订单状态为：REFUNDING、REFUNDED、REFUND_FAIL
  - 结算周期的时间基准：资源方退票成功时间

转存失败重新上传取消

2.3.4. 系统安全

系统安全：

HTTP：接口验签 + 时间窗口
- 窃听风险
- 篡改风险
- 重放攻击
HTTPS：时间窗口
- 重放攻击
- HTTPS 自身的 SSL/TSL 层，解决了窃听和篡改的风险

对于 HTTP 的 BA 认证和 HTTPS 的实现原理，可以参考：

HTTP Basic Auth 剖析：HTTP 接口验签的实现原理和细节
HTTPS：原理剖析

3. 相关问题（Q&A）

Q：美团侧业务和分销系统的关系？
- A：两个系统上层分离，依赖于基础数据（单点）的库存等数据。
Q：Fail cahce的轮询阈值？
- A：依赖于供应商提供的利率，响应效率等因素创建规则，分开判断。
Q：有用到分布式事务吗？
- A：大事务拆分成小事务，能用业务解决的尽量不用技术解决。
Q：订单状态的补偿机制？
- A：补偿机制内聚在核心的支付系统中，通过定时器的方式将中间态改为终态。

4. 参考资料

之前工作的要点总结