【支付】支付路由设计

    近期需要做支付系统，这里对项目中的支付路由设计进行总结

一.支付路由出现的背景

     现在市面上具备支付牌照的公司越来越多，因此哪些公司对应着出现了越来越多的支付通道，往往公司会选择不同公司的支付渠道去对接，主要有以下优点

　 1.不同支付通道稳定性各有不同，在通道不稳定时，需要有备用的支付通道去切换；

     2.不同支付通道的费率有区别，相比与原生的支付宝和微信，费率有差别

　 3.公司内部往往有很多业务，例如业务A，业务B...等等，为了区分不同业务的营收，方便财务对账，需要根据不通业务指定不同的支付通道；

     4.公司内部业务往往有很多定制化需求，例如PC扫码聚合支付，或自定义支付收银台的需求，这种往往都需要接多种支付通道，或直接对接第三方支付通道线程的收银台，减少了自己封装收银台的时间成本，相比于原生的微信/支付宝 支付，更加满足公司现有的定制化的业务需求，对接速度也相对更快；

但是支付路由不是银弹，说完优点，再说缺点

     1.对接通道过多，支付系统变复杂，需要监控不同的通道的支付指标更多；

二.支付业务流程

　　以PC扫码支付为例，这里描述一下支付业务的流程

 　  核心接口就是接口order/pay,该接口由订单系统发起，调用支付系统发起对第三方支付通道的预支付，然后返回给前端预订单

　　由于整套支付路由并不在订单系统，全部都是支付系统来维护，因此客户端并不知道支付系统使用哪一套支付通道

　　基于以上原因，order/pay该接口需要除了常见的订单号，金额，商品信息以外，还需要提供以下参数用来给支付系统判断使用哪个通道

       1. 业务类型 busiType   (用来区分不同业务，后期可以根据业务使用不同的支付通道)

　　2. 支付类型 payType   (微信扫码/微信APP/支付宝扫码/支付宝APP/苹果内购/微信H5/支付宝H5/聚合码支付)

　　3. 客户端类型 fromType (iOS/Android/Web/QT)

　　
　　以上三个要素确定了，对应的表关系也就确定了，这里分了4个表

       1.业务类型表 app_info

　　2.支付通道表 channel_info 

　　3.通道和业务映射表 app_channel_info 

　　4.支付通道业务信息表 channel_busi_info

　　对应的表关系如下

　　整个支付路由的核心也就是channel_busi_info，通道from_type，pay_type字段以及子系统信息表的app_id字段就能确定调用order/pay接口时，使用哪一种支付通道(channel_id)

三.项目结构

account-api       --支付相关接口暴露
account-center    --账户中心
account-channel   --支付通道服务(核心)
account-clear     --支付结算服务
account-core      --支付相关公共包
account-dao       --数据库访问层，仅与数据库交互
account-pay       --支付服务(核心)

　　这里和支付路由相关的主要是account-pay服务和account-channel服务这两个服务，因此主要针对这两个服务的设计进行展开说明

　　account-pay：主要暴露具体的支付接口给订单服务，处理系统内部的业务逻辑，根据订单系统传递的参数选择不同的支付通道，然后调用account-channel传递通道id，channel_id 真正的发起预支付

　　account-channel: 主要与第三方交互，抽象出一个基类，不通的支付通道通过实现这个类进而具备相近的能力，例如，支付，退款，支付查询，退款查询等等

四. 具体实现细节

　　account-channel服务中，使用工厂+策略模式，通过account-pay服务中传递通道ID，channel_id选择不同的支付通道进行支付，类图如下

 　　execute():用于发起支付

 　　getPayType():用于获取当前通道的支付类型

 　　getCHannelEnName:用于获取当前通道的名称

备注

扫盲：https://www.sohu.com/na/421683471_120746823