交易支付系统建设

        首先，聊一下我我的对于交易支付系统的理解，从用户的角度来讲，交易支付是密不可分的行为，可是对于系统来讲，交易支付应该是两个系统，有些系统建设时，甚至是没有交易系统的，直接由业务系统调用本地支付模块，或者第三方支付完成支付。这种设计在流量不大的状况，可能没什么问题，可是随着公司业务发展、规模扩大，这种方式无疑不利于后期的系统维护和扩展。而交易系统自己做为一个底层系统，应该统一抽象出完整的交易能力，供公司其余业务调用。统一业务收口，通常由交易系统、或者是收单系统负责，这里插一句，收单指的签约银行向商户提供的本外币资金结算服务，这里的收单是一个泛指含义。收单系统和交易系统的区别是，收单更多的是关注业务上的要素，而交易系统则更多去关心交易这件事。

        下图是我本身XJB画的，0.0 ...

        总体上看的话，一个完整的交易支付体系，包含了三个层次：

• 支付核心系统
• 交易系统：提供最基础的交易支付能力，充转提退：充值、转帐、提现、退款
• 帐务系统：提供帐户管理、记帐凭证、余额查询等
• 清算平台：提供清算、计费、对帐和差错的能力
• 资金管理平台：资金调拨、资金池管理等
• 收银台：支付渠道管理、支付工具选择、额度控制
• 会计系统：会计分录、科目汇总、发票系统等
• 支付支撑系统
• 渠道网关：签约、加密、验签、支付结果通知等
• 公共组件：
• 会员系统
• 风控系统
• 短信平台
• 监控平台
• 数据归集

        上面是整个交易支付系统的相关组件，不一样的业务能够根据本身不一样的业务来进行相应调整，可是核心系统不可或缺：

面向支付业务的话：交易核心、收银台、支付核心、渠道网关

面向资金业务：帐务系统、清结算系统、会计系统等

其余还会有一些基础组件，在此再也不赘述。

        这边会重点介绍一下支付业务相关的基础组件（由于本人一直从事这方面相关开发），后续也会介绍一些资金相关的系统建设（我会尽可能去了解哈~）。

        首先先说交易系统，交易系统对外提供交易能力，大的交易能力能够抽象为：充值、转帐、提现、退款，四种大的交易类型下，又能够区分出不一样的子交易类型，具体和业务相关联。抽象出交易能力的好处是，将业务和交易剥离，我就见过在交易逻辑中耦合大量业务逻辑的系统，不只代码维护起来十分的困难，并且也不便于后期扩展，从领域设计的角度来讲，交易域更关心交易相关的要素，而对外屏蔽业务相关。这样的好处是：面对于频发性的业务改动，交易系统始终提供统一的交易能力，能够适配各个业务的扩展。

        同时，为了交易数据总体的关联，建议统一订单模型抽象，整条链路关联到一个交易单上，该交易单全链路惟一，而且能关联到全部的交易、支付、用户等信息。这样就初步搭建起一个交易系统。