中台其实最早是起源于军事领域，在二战时期的美军在各个战场上，看起来有打不完的弹药、耗不完的燃料、充足的食品补给、及时准确的情报……但其资源却在万里之遥的美国本土，这一切是如何做到的呢？

就是依靠庞大的中台体系，支持到世界各战场。前方战场上的一名士兵，平均就有12名人员支持，在战场-基地-本土形成前、中、后台的效率系统。

国内互联网最早实行中台战略的就是阿里。

由于阿里涉及的业务线非常多，在没有中台之前都是每个业务自己去做一套系统，但是每个业务系统都有相同的模块，例如订单系统、支付系统、商户系统、短信系统等。因此就导致各个业务线重复造轮子的现象，业务端不仅需要对业务模块进行优化和升级，同时也需要维护这些基础支撑服务。

用一句话概括：中台就是将所有业务的公共模块抽象出来，单独创建一个中台系统统一对这些公共模块进行维护，统一输出服务提供业务方使用，让业务方能够集中全力发展业务。

理解了中台的概念，那么就需要思考对于互联网公司，中台系统的搭建能够解决什么问题呢？

可以解决你的996问题

中台是独立于业务系统而又服务于业务系统的存在，业务系统的前台和后台是关联存在的，但是中台的定位就是出于整个公司层面，要服务于多条业务线。

因此通过建设中台系统，能够极大减少业务系统的工作量，提高业务端的工作效率，业务系统部门就不需要再为了这些基础服务而进行996了。

提高公司产品灵活性和市场竞争力

通过中台系统，业务只需要关系业务流程即可，轻装上阵，将重心配合市场方向去优化业务系统，对于市场上出现的新的业务模式和特殊需求能够更快的响应，帮助公司快速占领市场。

对于中台最直观的感受就是提高工作效率和减少人力成本，不仅仅减少业务开发部门，同时也减少商务部门、法务部门等相关职能部门，所有的外部基础服务统一中台管理，对于整个产品架构的梳理会更加清晰，在产品设计方面也会更加快速，部门分工也更加合理。

支付中台，首先咱们应该最关心的是中台这个关键词，因为实际每个业务都已经有支付能力了，但是由于每个业务对于支付的单独开发，导致资源的浪费，让业务将过多的精力用在基础支撑服务的维护和开发上，而无法集中精力去针对市场优化业务，不利于业务的沉淀和持续发展。

我认为当企业的业务线数量大，企业的主要业务线稳定情况下应该需要建立中台系统。

而建立企业的中台系统则需要首先调研企业的每个业务的场景和特点，然后对每个业务进行拆解，得到每个业务的组成模块，再分析出每个业务组成模块的一个合集，这样就能确定中台系统的定位和构成。

在设计之初需要确定业务，该业务的核心场景；

从核心场景往外剥离，确定哪些是基础服务；

确定基础服务与业务的系统分界；

确定好每个基础服务的分界后，需要对基础服务进行建模，以保证整个中台体系的兼容性和扩展性。

基于业务，拆分为面向支付业务和面向资金核算两套体系。

基于场景，例如依据支付流程等进行拆分。

基于技术实现，例如出于对系统的性能等考虑拆分。

通过上图，可以看出支付系统可以拆分为：收银台、交易核心、支付核心、渠道网关、账务系统、会计系统、清算系统、合规系统等。

收银台：主要应用于业务的提交结算场景，可以根据不同的业务配置不同的收银台模板。

交易核心：业务发起支付时，支付系统与业务方的前置模块，主要用于对业务的校验、接单、查询请求等处理。

支付核心：对于业务发起的交易进行支付处理，生成支付订单，可以根据不同的交易类型匹配不同的支付工具，支付核心根据渠道返回的支付结果，请求账务系统、清结算系统、数据中心、交易系统等逻辑处理。

渠道网关：主要是对接渠道，处理渠道报文，渠道接口请求，支付路由处理等。

账务系统：支付系统的账务处理中心，账务的冻结、解冻、出金、入金，根据不同的交易类型对账户进行记账，并将账务流水通知到会计系统，会计系统进行复式记账。

会计系统：会计系统可以作为公司的业财中台，主要是根据账务系统流水将业务数据转化为财务数据，如果公司有用友、金蝶等财务系统，可以将生成的会计分类同步到财务系统中。

清算系统：针对不同的业务类型，进行清分结算。

合规系统：对接反洗钱系统、反诈骗系统，保证支付安全合规。

由业务方发起交易，通过收银台或者API发起，进入到交易系统，交易系统请求支付系统，支付系统接收到支付请求向渠道网关发起，渠道网关请求银行或支付公司；支付系统接收到结果后异步通知数据中心、清结算系统和合规系统。

1）如何保证数据统一性？

支付系统最重要的就是数据的统一性，因为涉及到真实的资金情况，因此对于订单统一性的要求是最高的，否则会导致资损的情况产生。

我们可以针对每个业务设置一个业务代码，通过业务代码+订单号的方式，在每笔订单生成一个业务跟踪号。通过这个业务跟踪号能够将交易订单、支付订单、渠道订单、资金流水进行关联和约束，防止订单数据差异以及对整个订单生命周期的追溯。

每个系统的订单可以定义规则，例如：日期+系统代码+序号。

2）如何保证业务支付的稳定性和扩展性？

首先需要深入了解每个业务对于基础服务的应用场景，根据业务的应用场景包装出不同的交易产品（交易类型、例如充值场景、提现场景、担保场景等）。在支付核心系统中，通过支付能力的组合形成支付工具，根据支付工具在组合成不同的交易产品，例如通过鉴权+代扣的支付能力，可以组合成支付工具快捷支付，快捷支付可以与交易场景的充值对应。这样就能实现插件化开发，能够根据业务的需要完成不同的组合场景，提供支付系统的扩展性。

3）如何处理部分支付的异常流程？

例如用户的组合支付（红包、优惠券、支付宝支付）红包和优惠券扣款成功、支付宝支付失败，我们建立了一个异常管理组件，这种组合支付都需要报送到异常管理组件，通过异常处理组件的规则，对该异常情况发起反向退款流程。异常处理组件会向支付系统发起红包退款、优惠券退款，保证整体订单的状态一致性。

4）代付拆单，部分成功的情况

对于代付交易，如果拆单后，出现2笔子单成功，1笔子单失败，出现这种异常会将该异常子单发送到异常处理组件，异常处理组件发送到调度中心，可以重发；如果无法重发，可以人工支付后更新状态。