导读

京东科技业务在快速发展的同时，产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点，且无法满足“风法财审”对于资金流程的管控要求，在此背景下金道结算平台孕育而生。本文从系统建设的背景、设计细节、已支撑案例及适用业务场景多个层面进行详细阐述。读者可以关注文中所讲的系统实践过程，进而对结算领域系统设计能力提升，具有一定的参考价值。

一、概述

1.1 背景

业务在快速发展的同时，产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点，且无法满足“风法财审”对于资金流程的管控要求。金道结算平台应运而生，专注于内部中心化流量场外的、通过外部场或搭建撮合平台进行获客、转化的场景，支撑业务方面向客户、合作伙伴、经销商、供应商等多利益相关方，实现快速、专业、高效、准确的线上化计费结算解决方案提供和能力支持。金道结算平台对接各垂直业务系统，实时同步业务的交易数据，并经过标准的结算流程（数据标准化预处理，清分，计费，分摊，结算单生成、运营确认等），最终通过财务渠道或其他支付渠道完成资金结算，有效降低了各业务系统结算成本的投入，提升业务资金流转的健康度，为业务的快速增长赋能。

1.2 痛点

业务系统在开展业务时，以当前线下处理的方式，普遍存在以下痛点：

计算难：计算规则复杂，数据量大，人工难以处理；

响应慢：现有业务变化快和新增业务速度快，人工效率较低，难以快速响应新资金结算模式；

风险高：人工计费、核对、结算数据风险高且不合规，难以溯源，操作风险高；

运营难：基础数据不完善，线下无法多维度分析，无法精准管理业务成本，及时调整策略；

成本大：人工结算的方式，投入的时间和资源成本高。

1.3 定位

金道结算平台深耕业务场景，打通平台接口，支持跨平台结算，是业财一体化的桥梁，为平台型交易及全域营销赋能。

图 1 平台定位

1.4 优势

金道平台的建设，在解决业务痛点基础上，平台优势能够从准、快、好、省几个层面体现：

1. 计费准确：支持大数据量计费，准确性达 99.99%；

2. 结算快速：灵活支持按日或月等维度结算，缩短结算账期，实现资金快速收付；

3. 运营精细：支持业务精细化运营，助力业务发展；

4. 成本降低：提高运营效率，节省成本。

二、系统架构介绍

2.1 名词解释

表 1 名词解释

2.2 服务域设计

图 2 服务域划分

平台基于 DDD 思想，划分清分域、清算域、结算域及报表域四个大域，每个子域又依次划分了自己的子域。

2.3 整体架构图

图 3 整体架构图

说明：

1. 金道平台从数据处理流向上，自上而下划为分数据源、清分、清算、结算及下游，从使用群体上分为零售客户及科技客户。

2. 业务数据通过实时或离线两种方式接入平台。在清分中判别数据归属清分类型（通用流程或个性化流程），而进入不同的清分处理流程。清分域主要是按一定的规则对原始数据进行核对、识别、调整及打标动作，为清算做好数据标准化。

3. 当清分标准化数据后，会推送结果数据到清算域，清算按模型配置的清算规则，通过流程控制进入计费、分摊、累额等不同的组合处理（譬如：只计费、先计费后分摊、只分摊、先分摊后计费等），以及会补全结算户、合同及汇率数据，数据落到清算明细表。

4. 结算模型达到结算周期条件时，会产生一个结算任务。结算任务处理时，会从清算表中按条件获取待结算明细，然后按结算维度汇总，各自产生结算单信息。结算单自动按预定审批流程完成确认，最终推送到财务渠道（渠道当前有：科技财务、预存款账户、pop 核算等），由财务渠道系统完成收付款。

2.4 典型问题技术设计

2.4.1 分片任务处理组件

平台采用 cds 实现分库分表存储数据，通过 DTS 把数据同步到 ES，并进行报表明细显示。在整个结算流程中，存在众多需要聚合表数据处理操作（譬如：单据预处理、清算预处理、生成结算单，条件拉取条件数据等），因为本平台是与资金结算相关，金额必须绝对准确，所以未采用 ES 作为可信的聚合处理源。在前期公司调研相关产品后，未找到基于分库分表有高效的聚合工具，所以特研发以下“分片任务处理组件”：

图 4 分片任务处理组件

此组件提供抽象的类 shardingTask,预定好 3 个核心动作：split(如何分片）、do(分片数据如何处理）、merge(最终数据如何聚合）。

核心处理过程为：先统一抽象批量处理逻辑，把批量数据分片发送 MQ 并落库。多节点多线程进行消费，消费完成后，对数据库 MQ 记录的状态进行修改。每个分片处理完后，匀检查该任务下的消息是否全部处理完成，如果完成后，最后执行合并逻辑，那么此时我们想要的最终结果就出来了。

2.4.2 顺序清算

背景

某些业务系统要求以业务发生的流水，按顺序做计算、分摊及累额，为了解决这个场景，特设计以下通用的处理流程。

实现过程

第一步：数据接入在中间表中，按业务时间排序，然后打上唯一流水号（流水号自增特点）：

图 5 打标流水号

第二步：业务人员或系统自动处理单据，进行清算时，会触发条件 ，进入以下预清算处理流程：

图 6 预清算处理流程

原理：

不需要按顺序处理的单据数据，直接发送了待清算 MQ 主题 中，需要按顺序清算单据，进入主流程。

挑战：

1. 分片存储情况下业务数据明细百万级排序；

2. 顺序处理如何保证处理效率；

3. 顺序清算异常情况，如何断点继续处理。

实现核心点：

原始快照表打标顺序流水号，利用分片任务组件，拉取数据后放在 zset 中进行排序，全部放入后，触发顺序清算流程。为应对大促销日，可以在业务能容忍的范围中，开放并发清算（并发数据之间不保证顺序），要成功整体成功，要失败整体失败。

2.4.3 累额重置

背景

按顺序计费、分摊及累额场景，当业务人员需要回退到历史某个时间的单据重新顺序清算时，就需要从累额明细中重置到将要执行单据的位点（也就是累加的总额回退回去，并在流水中标识出哪些是无效数据）。

实现原理

图 7 累额重置实现原理

三、系统功能介绍

3.1 结算流程

图 8 结算流程

整个流程主要分为 4 个步骤：

1. 出具结算方案：每当有新业务场景接入，需由产品同学调研业务运营同学以了解业务场景，并出具专业的线上化结算解决方案，辅助业务系统备齐结算所需数据来源，并辅助业务数据同学加工结算数据表。

2. 结算模型配置：依据结算解决方案，在金道结算系统完成结算模型的基本信息配置以及单据处理、清算处理、结算处理、下游处理等环节的规则配置。

3. 结算任务处理：业务交易发生推送到结算平台，然后经过清分流程处理、清算流程处理、结算单生成，如果有对账确认流程配置，则会推送账单由客户进行账单确认，发票暂由运营人员线下开具（后续会支持）。

4. 结算完成：等确认完账单后，账单会推送到财务进行收付款处理，财务的处理结算会通知到结算平台。最终账单信息可以由结算平台提供归档及检索。

3.2 主要配置

3.2.1 结算模型

1. 基本信息

图 9 基本信息

2. 规则信息

图 10 规则信息

结算模型是本平台核心配置，内容涵盖基本信息、结算周期、单据处理、清算处理、结算处理及下游配置，运营人员可以通过引导一站式配置好整个所需功能。

3.2.2 计费模型

1. 计费规则

图 11 计费规则

对外提供计费服务，支持不同产品的计费模型和计费规则，形成计费规则引擎，实现计费规则和模型的可配置化，可支持灵活多变的计费场景。

2.分摊规则

图 12 分摊规则

本平台支持基于预算的分摊配置能力，适合成本分摊型结算。目前我们支持分摊方式有按比例、按顺序及按固定金额，支持两级分摊，具备了大部分业务应用场景支撑能力。

四、业务支持案例

目前金道结算平台已赋能了 微电佣金、白条息费成本、内容平台创作者佣金、支付营销券计收等 业务的线上化结算场景，日均处理订单量达 5000 万+，日均有效结算金额达 1300 万+，有力支撑了业务快速发展。

4.1 微电业务

合作案例：为微电业务解决职场、坐席销售金融产品而产生的资金结算问题，包括佣金、业绩考核、企微加粉费和电话使用费等。

业务场景：微电业务售卖的金条、白条、基金、养老保障、小金保、股票、延保、CPA 等。

图 13 微电业务

4.2 白条业务

合作案例：为白条与商城解决商城、科技、供应商、POP 商家联合营销而产生的白条营销费用收取问题。

业务场景：收取商城、供应商、POP 商家的白条营销费用。

图 14 白条业务

4.3 支付业务

合作案例：为支付解决外部机构采购优惠券，而产生的支付营销费用收取问题.

业务场景：收取外部机构的支付营销费。

图 15 支付业务

五、总结

针对目前业务场景、商业模式进行调研分析，主要有四种结算模式:分佣结算、业绩考核结算、技术服务结算及商品营销结算。

4 种模式覆盖目前所有场景，随着接入业务场景的扩展，模式可再增加。

作者：京东科技 张学君

来源：京东云开发者社区 转载请注明来源