文章目录
磁云数字：供应链金融-支付系统演进过程
业务背景介绍
支付系统1.0版本
1.0版本介绍
支付系统1.0版本只对接了中金支付一家资金机构。
从系统角度来看，还谈不上是一个支付系统。因为支付1.0版本是作为一个业务模块耦合在供应链金融系统中，为供应链系统提供资金机构开户、充值、提现、绑定结算卡、转账、电子回单等功能。
这个阶段，供应链金融系统采用 All in one 模式，即供应链金融系统属于单体结构。尽管从系统设计角度，将供应链金融系统划分出来了多个模块，但是从系统部署上依旧是单体结构。
1.0版本产品架构
因为，支付1.0版本是耦合在供应链金融系统中，所以这里的产品架构其实指的是供应链金融系统的产品架构。如下图：
1.0版本技术架构
1.0版本技术选型：Spring + SpringMVC + MyBatisPlus + Apache Shiro + JS。
这个阶段，应用系统采用三层架构的单体结构，三层架构即：视图层 + 业务逻辑处理层 + 数据访问层。
技术架构如下图：
1.0版本架构的优缺点：
- 优点：
- 易于开发
- 易于测试
- 易于部署
- 易于新人快速上手
- 缺点：
- 业务边界不清楚，高耦合性
- 系统复杂，牵一发而动全身
- 扩展性差
支付1.0版本适用于业务发展的初期，接入资金机构需要迅速响应公司业务需求，此时团队规模有限，项目工期相对较短，且项目任务多。
支付系统2.0版本
2.0版本介绍
为了提高供应链系统的高扩展性、易维护性，同时为了提高更多、更复杂的业务量，该系统于2019年4月份开始重构。
重构即将供应链金融系统从单体结构变成微服务架构，垂直划分业务模块边界，这个阶段将支付业务从该系统中正式剥离出来，形成一个可以独立支行的微服务。
2.0版本支付业务需求：
- 将支付业务从原供应链金融系统中剥离出来，形成独立运行的服务。
- 保证1.0版本支付业务稳定运行，生产环境无阻碍性 Bug。这一点主要是保证中金支付业务逻辑正常运行。
- 新增华夏银行 PDS 支付渠道，实现与中金支付一样业务逻辑。
- 支付系统私有化部署
2.0版本支付业务遇到的问题：
- 如何将1.0版本支付业务逻辑从原供应链金融系统中剥离出来
- 因为新增加了一个支付渠道，所以提出了支付网关的概念。那么，支付网关如何设计便是另外一个问题。
第一个问题其实是很多系统在重构时都会遇到的一个问题。
重构系统，并不是将原有的业务逻辑重新推翻，重新设计，重新开发，而是找准问题，并针对问题去一步一步的优化。
重构的目标是优先保证原支付业务可以稳定的支行，其次再去解决其它设计上的问题。
所以，在解决这个问题的途径上，就是将原来耦合在供应链金融系统中的代码给挪到一个独立的项目空间里，同时尽可能的处理一些设计上、开发上不合理的地方。
第二个问题，支付网关的设计比较复杂一点。
复杂的原因如下:
- 支付网关与系统网关上下文边界不知道如何划分。
- 因为不同资金渠道的报文格式不一致，所以支付接口与报文处理不知道如何设计 。
那这个问题的最终解决方案是将中金支付的实现复制一份，修改其中的业务逻辑来实现。当然，这种方式肯定是不合理的。
2.0版本产品架构
基于上述需求，支付系统2.0版本产品架构如下图：
2.0版本技术架构
2.0版本技术架构选型：SpringBoot 2.0 + Dubbo + MyBatis + RabbitMQ + MySQL + MongoDB + Vue
架构图如下：
支付2.0版本，使用SpringBoot 2.0构建微服务体系，使用Dubbo实现支付系统与业务系统远程调用，实现同步解耦，使用RabbitMQ消息队列实现了支付系统与业务系统异步解耦。
支付2.0版本的弊端如下：
- 支付业务逻辑抽象不足。相同的业务逻辑，中金支付渠道与华夏银行支付渠道同时实现两遍，
除报文格式不一致及资金渠道 API 不一致，其它逻辑均一样。如果业务逻辑发生变化，需要同时修改两份代码，不方便维护。 - 很明显，这个版本，并没有把支付网关抽象出来，而是对于同一个支付业务场景根据支付渠道的不同，提供了不同的 API，对于前端、后端开发者的工作量带来了影响。
支付系统3.0版本
3.0版本业务介绍
3.0版本支付新增加了兴业银行支付渠道，其余业务与2.0一样。因此，3.0版本的产品架构与2.0产品架构也是一致的。
3.0版本支付系统需要解决的问题：
- 支付网关的设计：因为又新增了一个支付渠道，所以必须统一支付系统 API，即为前端提供一套 API，而不是为每一个支付渠道都提供一套 API。
3.0版本支付网关是在支付渠道业务实现的上层提供了一个支付聚合服务层，在这一层通过支付渠道标识，来识别当前支付请求的支付渠道。
3.0版本技术架构
3.0版本支付提供了支付网关，但是设计上依旧不合理。在支付渠道实现层的设计是冗余的，缺乏抽象。如果支付业务场景发生变化，需要修改三个支付渠道业务逻辑。
支付系统4.0版本
4.0版本介绍
3.0版本之后，基于支付场景、业务需求对支付系统做了深层次的梳理与思考。
4.0版本支付重点在于优化、重构之前版本的产品架构和技术架构。
4.0版本支付系统会基于微服务+领域驱动设计来完善。
为什么选择领域驱动设计？领域驱动设计思想提供限界上下文、实体、值对象、聚合、聚合根、领域、子域等概念，这些对于复杂系统的设计、扩展有很好的引导作用，可以更好的实现服务间的高内聚与低耦合。
4.0版本产品架构
4.0版本技术架构
4.0版本开始初步具备支付系统的雏形，所以技术选型也会随着发生改变。
技术选型：SpringBoot 2.0 + SpringCloud Alibaba + MySQL + MongoDB
4.0版本技术架构如下图：
