支付中心重构

我们之前版本的支付中心实现了不同支付方式统一的接口，但是后面向第三方请求的时候，只设计了单一配置，即只能以同一个账户和第三方支付公司发生交易，并且支付记录的保存并不完善，不能从支付中心直接查出来支付的总量。随着公司业务的扩大，我们来自不同产品线的支付需求要求支付账号可能是多个，也可能是跨公司主体的。为了更好的服务不同项目，我对原来的支付中心进行了重构。

1.支付中心采用一套统一的接口来对外提供服务，如果是需要调用分出来的支付服务，也是由支付主服务去调用，其他的业务系统只和支付主服务打交道。在架构层面对原来的springboot进行了升级，升级到了springcloud，为公司业务规模的扩大，提供了技术上的准备，但是与各个系统对接的时候还是采用http请求，这样当新上线一个产品的时候，支付中心不需要动。

2.对于原来的配置方式进行了更新，原来的账号配置采用的是properties文件方式，但是对于同一个支付方式有多个账号的情况，支持就不好。改为了采用yaml文件的方式进行配置，可以支持任何配置。对于业务系统的支付请求采用按照订单前缀的方式进行配置关联。主动通知的时候，也是通过订单前缀拿到内部服务的地址，通知给业务系统

3.某些支付方式采用jar方式提供加密解密服务，并且配置是采用相对路径来读取properties文件方式。只能把该支付方式从支付中心的主服务中拆出来，采用独立的服务来实现，一旦该种支付方式需要有多个账号提供服务的时候，通过打包不同配置的方式发布成不同的服务来实现。因为我们采用genkins来做版本发布，因此就需要把整个服务打包成jar包的形式。有些第三方支付提供的jar包读取父jar包中properties文件有问题，我直接改了第三方公司的jar包中的class文件来使之可以读取。

4.目前我们支付的服务分为2种类型，一种是银行卡扣款支付，需要传支付4要素，发送短信验证码验证支付的，另一种是微信支付的这种，两种差异比较大，因此从接口层就将他们拆开了，不同的支付类型调用不同的接口，能共用的尽量共用。在数据保存上，收款和付款用不同的数据库表来记录，银行卡四要素验证的和微信类支付的用不同的表来记录，退款和收款用不同的表记录。对于每一笔支付，记录下每一笔交易发生的时间，结果，对账结果。

这次支付中心重构本质上是组织的重构，将原来每开一个业务线就单独运行一个支付中心的方式重构为由独立的支付组来负责支付业务。当然不止支付中心，信用中心，api监控中心都是采用了类似设计，来将这些服务和业务系统分离出来。走的是大中台，小前台的模式，由专业的后援团队来为每个业务线提供支持。