清算核心是什么？文章通过从系统业务流程、系统架构和领域模型、业务边界分析和系统边界分析四个方面来解析，一起来看看~
系统业务流程分析
第0步由产品层来实现各种接受提现请求的场景。
第1-1.2步骤归为支付层处理，支付层的核心是支付协议，前面讲支付核心时已经分析过，简单点说：一个支付协议可以=一个账务指令+一个清算指令。其中账务指令和清算指令，都是可以进行运行的最小单位。
第1-2.4步，本讲中称作清算平台，其中2.2和2.3承担的工作叫做通信前置，负责指令的发送，和接受指令的返回，在物理部署上他们将会是独立的通信前置机器。像使用文件这种人工提交的方式处理的指令2.2和2.3步骤则分别会被影射到文件生成器，和文件解析器上，也是清算系统和外部进行批量交互的核心组件。
第3步是清算层处理完毕后的收尾工作，让支付层知道最后的处理结果，对于先扣款的交易来说，这一步的影响仅仅在于两边记录的清算指令最终状态的一致性，对于以后可能出现的其他交易来说，这个状态可能会决定后续账务处理。
系统架构和领域模型
逻辑视图
部署视图
这里的mix系统职责是两块，一块是作为复杂支付渠道的业务产品，包括（网点支付、代金卡、COD、MotoPay），一块是划入支付层职责的转帐和分润业务。之所以要提出这个系统，是因为这些复杂支付渠道的业务逻辑被分散在多个系统中（支付系统、开发平台、银行网关），而这些在系统中的定位是通信前置，不应该包含这些逻辑。所以统一迁到mix系统中。
Mix系统的使用者有外部前置系统和收银台，外部前置系统提出复杂支付渠道请求时，外部前置做了基本的接口校验之后，所有逻辑处理由mix来负责。收银台是支付渠道的发起者，如果发起复杂支付渠道请求，也先转给mix来处理。
Mix系统作为复杂支付渠道的业务产品，但完成支付，最终还是调用支付核心来完成。与mix后端交互系统，目前只有支付核心。发起支付请求时，mix调用支付核心。支付核心支付完毕之后，业务分流给mix系统。
清算核心负责整体清算模型的运转，所有跟外部机构有清算需求的业务，都经过清算核心，包括前面提到的复杂支付渠道。
支付核心和清算之间的关系非常明确，支付核心调用清算核心进行清算请求，清算核心清算完毕之后，反馈给支付核心。
清算核心是负责整体清算模型，具体的清算指令发送，是由几个通信前置来完成的。
模型总览：
清算实体通用模型：
清算指令和清算文件是多对一的关系，核对并处理过的清算指令和清算文件处理结果是多对一的关系。以上都和清算通道接口是一对一的关系、即不论文件或者指令只有一个清算通道接口。
渠道类型：
渠道类型和其中一个维度通信类型是密切相关的。
渠道类型可以这样来划分：快捷、线下、信用卡、人工、银企互联、B2B、B2C、VISA，MIGS（国际支付）、COD、代金卡等
清算的各种模式也是和渠道类型分不开的，例如：渠道类型为快捷的，统统是使用的实时接口，银企互联则采用批量数据通过接口提交的模式，而线下类型则是批量数据生成文件来进行提交的。
支付机构内部渠道划分为以下几类：
银行卡类型：
清算类型：
清算指令的状态：
批量的指令有两种发送的实现模式：
落地为文件供结算人工下载，人工发送提交。
直接通过和银行交互的接口批量或者单笔发送出去。
核心的业务逻辑
充值文件内每笔清算指令金额和状态=充值清算文件处理结果内每笔清算指令金额和状态；
充退文件内每笔清算指令金额和状态=充退清算文件处理结果内每笔清算指令金额和状态。
业务边界分析
用例总图：
充值回导文件获取。
充值回导文件有两种获取方式：
一种是人工去银行网银系统去下载，并保存到本地硬盘，然后通过工作平台提供的上传功能进行上传。
第二种是人工或系统触发（系统自动触发会是固定时间点，或者有规律的时间段）并由系统通信前置与银行服务器进行交互拿到回导文件。
我们这里主要指的是第二种。
如上图，我们将会通过标准接口和通信前置交互获取到文件，实际保存动作由通信前置完成，保存完成后将文件路径返回给清算文件处理模块。通信前置获取到文件后，要把纯文件信息保存到数据库中。
在文件被解析成功后将数据导入SETTLE_BANK_RETURN表，同时将文件摘要信息保存到SETTLE_BANK_RETURN_BATCH表。
通信前置需要一定的缓存功能，比如：一些银行多种业务一个文件返回的，那么通信前置需要能区分出来，不要去请求银行多次。
充值回导文件解析：
见上图，我们要把解析脚本内容保存到数据库，直接读取数据库中的内容，这样方便管理和更新。
充值回导文件导入：文件解析完成后，需要把数据对象存储到数据库中，对于充值来说业务关键字段和提现一样：充值订单号和充值金额。
充值回导文件对账：
对账需要在导入后进行触发，可以是人工触发，也可以是系统自动触发，也可以在导入后立即系统自动触发对账。系统将提供接口供工作平台调用或者系统自己调用。
系统触发可以配置成一个定时执行任务，这样可以把实时要做的事情变成异步确保会做的事情，将使用到定时预约的系统功能，在定时查询中有讲这个工具。
通用的对账流程如下图：
银行通信前置：主要涉及到的工作是网银对指令的签名、校验签名以及报文服务费与清算核心的对接，还有获取对账文件的对接。
清算指令处理：
指令的清算结果状态：
指令类状态：批量的指令有两种发送的实现模式。
落地为文件供结算人工下载，人工发送提交。
直接通过和银行交互的接口批量或者单笔发送出去。
内部服务管理：
指令处理时序图：
系统边界分析
经过前期对业务上的一些认识，目前产品可以分为三大类：网银异步模式、直连模式、其它个性化模式。
网银异步模式包含：B2B、B2C、VISA、MIGS这些有支付机构和银行页面展示的，银行端需要用户输入账号密码进行支付的业务。
直连模式包含：网汇E、快捷这些通过某种协议只需要在网站确认就可以进行支付的业务。
其它个性化模式包含：MOTO、线下网点金融机构、信用卡还款、COD货到付款、代金卡、电话支付这些属于清算但是模型很复杂的业务。
直连模式：
网银异步模式：
