清结算系统架构设计

前言

清结算系统我认为是比较难设计的一类系统，近年来有幸参与该方向的系统设计和开发，接下来就拿我个人的开发经验来和大家分享。不足之处请大家包含并指正！

清结算系统架构设计

话不多说，直接上图。

接下来针对这张图结合我个人实际情况进行分析每个模块及环节的作用和运行机制。

1.订单落地

交易系统（包括各个交易端）产生订单，这些订单他们会以消息形式广播，结算系统监听相应消息并将结算所需信息落地（这样做到了与交易系统解耦，可以离线结算、重试）,同时按结算维度拆分出结算单元(结算粒度)。比如是按子单维度，还是按主单维度，甚至是按sku维度，这些都可以基于不同的业务场景拆分不通的结算单元，为后续的清分做准备。

2.清分因子

这一部分可以理解为是每个订单的清分规则，B端商家可以通过管理后台或者商家app去自定义分账规则，这些规则包含分账人、分账比例、结算周期、分账订单载体（设备或店铺）。另外还可以管理其他费用的收费标准配置，比如平台服务费、算法费、渠道手续费等等，一个单独的模块或者系统去维护管理，为后续的清分提供标准的api接口。

3.计费

计费则是在订单落地后，很快已结算单元维度生成对应的计费信息，这些计费信息包含但不限于订单金额、实付金额、平台补贴、商家补贴、各种服务费（平台服务费、算法费、渠道支付手续费）、以及当订单产生了退款时，去回更计费信息里的退款金额、退补贴、退服务费，最后总和上述费用之后的最终计算出的待结清分金额（这部分钱是真正需要按照比例结算给商家以及分账人的）。总是，在计费这里把各种费用记录的清清楚楚，后续的结算以及账单产出都很容易了。

4.调度(清分)

这一环节记录了订单的清分规则以及指令。
基于订单落地信息结合清分因子，拆分出一个订单的每一项费用，生成一个调度任务，每一个调度任务数据，体现了这项费用的来源和将来某个时间点的去向。即这里的每一条数据都记录着一项分账规则，在什么结算周期结算给谁、结算比例是什么，结算的类型是什么等等，单独启任务去检索这些满足了结算周期的结算调度数据，按照指令、结合计费信息，计算出一条条清分明细数据。

5.结算

生成清分明细数据后，就可以有单独的任务针对这些明细逐条结算，不管是调用三方支付公司接口，或者微信、支付宝接口，甚至自建账户体系提供的的接口进行结算分账。

6.完结

最后以结算单元维度进行完结，调用三方接口进行资金的最终解冻操作，同时产出相应的结算账单，账单可以是多视角的，每个视角看到的账单数据是不一样的。

7.异常

最后就来看看异常的处理方式，结算系统流程长且复杂，各个环节都有可能出现问题导致结算挂起，对于这些情况，可以在每个异常点进行埋点，记录下导致结算异常关键信息，并为这些异常场景进行编码归类，统一的写入异常队列，之后可以单独的一个守护任务去对这个异常队列根据异常编码进行定制化处理类去逐场景修复。基于以上思路可以在后续的运维过程中对发现的异常场景，均可依照此方式进行自动化处理。这样能够减少很大部分的人工处理。

8.总结

结算系统繁琐复杂，结算场景多之又多，但我们总是能在复杂的场景中找出规律，总结出流程，拆分出步骤，将繁琐的东西简单化。以上是个人拙见，也是基于我们公司相应的业务设计的一套解决方案，供大家参考。