供应链系统设计-供应链中台系统设计（十六）- 清结算中心设计篇（五）

本文链接：https://blog.csdn.net/niuniu_1983/article/details/145417873

概述

我们在供应链系统设计-供应链中台系统设计（十四）- 清结算中心设计篇（三）中关于业务诉求的好的标准进行了架构设计，如下图所示：

主要是基于我们之前对于一个清结算系统从业务诉求角度来看，一个清结算系统好的标准如下：

1.高准确性：清算是资金流转的基石，若计算结果错误，直接导致资金损失或纠纷。

2.全面覆盖业务场景，灵活性与可配置性：作为清算中台，支持前端复杂业务规则（分账、退款、手续费计算）、多币种处理等，通过配置而非代码调整规则。

3. 合规与风控能力：符合金融监管要求（如反洗钱、实名认证），内置风险检测（如大额交易预警、异常行为拦截）。

4. 透明可追溯：所有交易流水、清算记录、资金变动清晰可查，支持实时对账和审计追溯。

5. 资金流动性高效：缩短结算周期，提升资金周转效率（如实时到账、自动归集）。

基于这样的整体应用划分以及分层架构设计，本篇文章从技术架构层面来剖析一下，如何从系统质量角度，一个清结算系统好的标准如何来实现：

1.高性能与高并发处理能力：支持高并发交易处理，响应时间短，吞吐量高。

2. 高可用性与容灾能力：系统7x24小时稳定运行，具备故障自动恢复能力。

3. 数据一致性与完整性：在分布式环境下确保数据最终一致，无丢失或冲突。

4. 安全性：保护交易数据不被篡改或泄露，防范外部攻击。

5. 可扩展性：架构支持水平扩展，应对业务增长。

核心讲解逻辑如下：

从业务交易层到清结算接入层
从接入层到清算层
从清算层到结算层
从结算层到稽核层
上篇文章供应链系统设计-供应链中台系统设计（十五）- 清结算中心设计篇（四），我们已经讲过从业务交易层到清结算接入层的主要架构思想，因此本篇文章，主要阐述一下从从接入层到清算层的核心架构设计的思想和以及对于思考。

清算整体设计

什么是清算，我们首先如下：

我们之前清算就是算钱，结算可以理解为付钱。如果对于清结算概念不是很清楚的同学可以参考：供应链系统设计-供应链中台系统设计（十一）- 清结算中心概念片篇来进行了解。

一、总体架构思想

该清结算系统采用分层架构与事件驱动模型，通过模块化解耦、异步处理、动态扩缩容等设计，实现高并发、高可靠、灵活可配置的资金处理能力。核心目标为：

标准化清算流程：统一业务入口，避免代码冗余。
弹性扩展：根据负载动态调整资源，应对流量高峰。
全链路风控：实时拦截风险，保障资金安全。
能力复用与隔离：通过原子能力链支持多业务场景，提升开发效率。

如下图所示：

以下为各层详细解析：

清算预处理：

1、需要将接入层处理好的标准数据转化为清算需求，清算需求对象作为统一的整个业务中台的统一清算入口，这样是清算请求标准化，不会造成清算内部的代码腐化。

2、清算需求信息补齐，因为清算信息可能还包含清算特有的信息，例如：借贷方、清算渠道、商品信息相关补齐等等

3、清算需求是一个标准模型，模型中包含了清算时所需要的标准信息，同时还需要将清算需求保存到对应的数据库中，并且针对清算需求的状态进行管理

4、根据清算需求，获取中台的业务身份ID。中台业务身份ID是根据中台对于每个业务定义了对应的业务身份，根据分配的业务身份以及关键识别要素，可以获取对应的能力链，获取对应的能力链后，可以在流程编排成引擎中，基于业务的能力链执行。

流程编排与原子能力层：

1、中台针对上层每个业务都会定义好一个业务身份ID，这个是中台用来标识前台业务的唯一标识。通过业务身份 + 场景ID + 执行动作ID可以获取对应的流程执行实例ID。

2、流程执行实例ID可以看成为由原子能力组成的，经过编排的原子能力链，这样不同的业务就可以执行不同的流程，但是实际上底层能力是不需要重复来进行开发的。这样就可以实现了不同业务之间能力的复用，同时在流程上有起到了隔离的作用。

以下以清算校验为例，如下图所示：

上图是通过流程编排进行配置的，他核心思想就是通过对于原子能力编排，实现不同的业务流程的隔离和原子能力的复用，减少中台能力的重复开发。

清算引擎计算层：

1、将清算需求转化为清算任务，由rocket mq消息队列进行转发，清算队列在消息队列中进行排队，等待清算执行引擎进行并行的异步消费，这样可以实现快速消费

2、清算执行引擎与清算的其他应用分开进行部署，清算执行引擎可以根据清算任务的数量动态来调整清算引擎应用实例，这样对于清算任务的处理可以实现弹性的扩容机制。

3、需要有清算异常处理机制，清算发生异常，必须也安排保存到数据库中，需要有XXLJOB定时拉取策略，拉取之后重新执行清算。

4、清算预处理主要是初始化清算任务，根据清算任务获取对应的清算规则，解析清算规则，将清算规则中肯可能涉及到的变量进行替换。清算后置处理主要将清算计算的结果进行封装。

5、双重实时风控校验机制。第一次风控校验主要针对清算任务进行校验，校验更多是基于清算任务中的相关信息，例如：分账主体是否黑名单，清算业务渠道是否合法。基于清算结果进行风控，例如：校验分账比例结果是否合规。一个是对业务相关信息进行风控，一个是对清算结果进行风控，不同的维度，风控侧重点是不一样的。

上图是对风控模块的简单描述，在这里不做重点描述，主要提两点，就是风控规则和风控AI模型：

1、风控规则是基于固定的人工设定的风控规则进行校验。

2、风控模型校验，主要基于训练好的AI模型进行风控推理分析，如果风控AI模型推理分析存在可能的风控，将实施风控实时拦截处理。

风控引擎总共分为两层：

第一层：规则引擎
- 执行硬性规则（如单笔金额限制、黑名单校验）
- 快速拦截明显风险，减轻后续压力
第二层：模型引擎
- 执行复杂AI推理（如用户行为异常检测）
- 处理规则无法覆盖的隐蔽风险

二、分层架构解析

1. 接入层：标准化数据与生成清算需求

核心职责：

数据标准化：将不同业务系统（如电商、支付平台）的异构数据（JSON/XML）转换为统一清算需求模型。
信息补齐：补充清算特有信息（如借贷方、商品详情、清算渠道），确保数据完整性。
状态管理：将清算需求持久化到数据库，记录状态（如“待处理”、“已完成”）。

通俗示例：

类比快递分拣中心：不同快递公司（淘宝、京东）的包裹（交易数据）在此被统一贴上标准标签（清算需求模型），分类存放（存储到数据库），等待后续配送（清算）。

设计优势：

代码防腐：统一入口隔离业务差异，避免核心清算逻辑被污染。
可追溯性：持久化存储支持事后审计与重试。

2. 流程编排层：任务调度与动态扩缩容

核心职责：

任务生成：将清算需求转化为清算任务，通过RocketMQ消息队列分发。
弹性扩缩容：根据队列积压情况动态增减清算引擎实例。
异常处理：失败任务保存至数据库，通过XXL-JOB定时重试。

示例：

类比物流调度系统：包裹（清算任务）被分配到不同运输车辆（清算引擎实例），车辆数量根据包裹量动态调整（高峰期增加卡车，闲时减少）。

设计优势：

高吞吐：异步消息队列削峰填谷，支持每秒数万级任务处理。
容错性：失败任务自动重试，减少人工干预。

3. 清算执行引擎层：规则解析与计算

核心职责：

规则加载：从配置中心获取清算规则（如分账比例、手续费模板）。
变量替换：将规则中的动态参数（如汇率、税率）替换为实时值。
结果封装：生成标准清算结果（如应付金额、分账明细）。

示例：

类比自动售货机：输入商品编号（清算任务），机器按预设规则（价格表）计算金额并出货（生成清算结果）。

设计优势：

灵活配置：规则与代码分离，支持动态调整（如分账比例从10%改为20%）。
高效计算：并行处理任务，提升执行效率。

4. 风控层：实时校验与合规拦截

核心职责：

双重风控校验：
- 任务级风控：校验分账主体是否黑名单、渠道是否合法。
- 结果级风控：校验分账比例是否合规（如平台抽成不得超过20%）。
实时拦截：高风险任务直接阻断，生成告警通知。

通俗示例：

类比机场安检：乘客（清算任务）需通过两重安检（任务校验和结果校验），携带危险品（高风险交易）被拦截。

设计优势：

风险前置：在资金划转前拦截问题，避免损失。
合规保障：内置监管规则（如反洗钱），降低法律风险。

5. 清算能力层：原子能力与流程编排

核心职责：

业务身份ID管理：为每个业务分配唯一标识（如电商业务ID=001），绑定原子能力链（如分账+手续费计算）。
能力复用：通过编排原子能力（如汇率转换、分账计算）生成定制化流程。

通俗示例：

类比乐高积木：不同业务（建筑模型）使用相同的积木块（原子能力），但通过不同拼接方式（流程编排）实现个性化需求。

设计优势：

开发效率：复用能力减少重复开发，新业务接入周期缩短50%。
业务隔离：不同业务的流程互不影响，避免耦合。

三、实际场景验证

场景：电商大促期间的清结算

接入层：每秒接收10万笔订单，转换为标准清算需求并存储。
流程编排层：生成清算任务并通过RocketMQ分发，动态扩容至200个清算引擎实例。
清算执行层：按规则计算分账（平台抽成10%），生成应付金额。
风控层：拦截1000笔高风险交易（如黑名单商户）。
结果处理：成功任务触发结算，失败任务进入重试队列。

结果：

清算耗时从10分钟缩短至30秒，资金到账时效提升20倍。
风险拦截准确率超99%，避免数百万元资金损失。

二、架构设计的核心思想

一、核心架构思想

1. 分层设计：模块化解耦，提升可维护性

设计原因：
清结算系统涉及多业务场景（电商、支付、跨境），各环节复杂度高。通过分层设计（接入层、流程编排层、清算执行层、风控层），将数据标准化、任务调度、规则计算、风险控制等职责分离，避免代码耦合。
优势：
- 独立演进：例如风控规则调整无需修改清算引擎代码，降低迭代风险。
- 快速定位问题：若分账错误，可直接排查清算执行层规则解析逻辑。
通俗示例：
类似汽车生产线，发动机组装、喷漆、质检分属不同车间，互不干扰，效率更高。

2. 异步消息队列（RocketMQ）：弹性扩展与高吞吐

设计原因：
清算任务存在明显波峰波谷（如电商大促），需动态调整资源。消息队列解耦生产与消费，任务堆积时可快速扩容消费者实例。
优势：
- 削峰填谷：双十一期间，任务积压通过横向扩展实例快速消化。
- 容错性：消息持久化存储，故障恢复后继续处理。
通俗示例：
高峰期的快递分拣中心，临时增加分拣员（清算引擎实例）处理包裹积压。

3. 规则引擎与原子能力链：灵活适配多业务

设计原因：
不同业务（如电商、直播）分账规则差异大，需通过配置化规则和原子能力复用，避免重复开发。
优势：
- 快速接入新业务：例如新增跨境业务，只需配置汇率转换规则，复用分账能力。
- 业务隔离：电商分账规则调整不影响直播业务。
通俗示例：
乐高积木按需拼接，相同积木块（原子能力）组合成不同模型（业务场景）。

二、架构的优势总结

4. 双重风控校验：全链路风险拦截

设计原因：
资金安全是核心，需在任务处理前（黑名单校验）和结果生成后（分账合规性）双重拦截风险。
优势：
- 风险前置：黑名单商户交易直接拦截，避免资金损失。
- 合规保障：分账结果超比例时自动冻结，满足监管要求。
通俗示例：
机场安检两重关卡：行李扫描（任务级风控）和登机前证件核查（结果级风控）。

三、架构的优势总结

设计目标	实现方式	业务价值
高并发处理	RocketMQ异步消息队列 + 弹性扩缩容	支持每秒10万级交易，保障大促期间稳定性
灵活适配业务	规则引擎 + 原子能力链	新业务接入周期从1月缩短至1周
资金安全与合规	双重实时风控 + 审计日志	拦截99%高风险交易，满足反洗钱监管要求
可维护性	模块分层 + 标准化数据模型	降低代码维护成本，问题定位效率提升50%

三、架构未考虑的潜在问题与优化建议

1. 数据一致性与事务管理

问题：跨层操作（如清算需求生成与任务分发）缺乏分布式事务保障，极端情况下可能导致数据不一致。
优化建议：
- 引入分布式事务框架：如Seata，确保“清算需求生成→任务分发→状态更新”的原子性。
- 补偿机制：定时对账任务修复差异（如未处理的清算需求）。
示例场景：
清算需求生成后MQ发送失败，事务框架自动回滚数据库状态。

2. 跨机房容灾与数据同步

问题：当前架构未体现多机房部署，单机房故障可能导致服务中断。
优化建议：
- 多活架构：数据库跨机房同步（如MySQL主从多机房部署）。
- 流量切换：通过DNS或负载均衡实现故障秒级切换。
示例场景：
主机房宕机时，流量自动切换至备机房，保障服务连续性。

3. 监控与日志体系完善

问题：架构中未明确全链路监控（如MQ积压、规则执行耗时）和日志检索能力。
优化建议：
- 集成APM工具：如SkyWalking监控服务链路，Prometheus+Grafana监控资源指标。
- 日志集中管理：使用ELK（Elasticsearch+Logstash+Kibana）实现高效检索。
示例场景：
清算任务处理延迟时，通过链路追踪快速定位瓶颈（如规则引擎性能不足）。

4. 安全机制的深化

问题：敏感数据（如银行卡号）加密存储和传输未明确设计。
优化建议：
- 字段级加密：使用AES-256加密存储敏感信息，传输过程强制TLS 1.3。
- 权限最小化：运营后台按角色隔离操作权限（如风控员仅能查看日志）。
示例场景：数据库泄露时，加密字段无法被破解，保障用户隐私。