支付渠道那些事
年初开始对公司的支付系统进行微服务架构改造。 之前有一系列文章介绍了改造的背景。 为什么要重构到微服务 重构中的天时地利任何 重构的准备工作 从这一篇开始,进入重构工作的正题了。 在支付系统中,支付网关和支付渠道的对接是最核心的功能。其中支付网关是对外提供服务的接口,所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型,后续就很少,也很难调整。而支付渠道模块是接收网关的请求,调用渠道接口执行真正的资金操作。每个渠道的接口,传输方式都不尽相同,所以在这里,支付渠道模块的作用,类似设计模式中的wrapper,封装各个渠道的差异,对网关呈现统一的接口。而网关的功能是为业务提供通用接口,一些和渠道交互的公共操作,也会放置到网关中。 初始架构 早期启动的时候,对接的渠道不多,所有渠道和网关都实现在一个项目中,部署在一起。采用SSH架构,支付网关实现为一个大Apache Struts Action类,在我们重构前,这个类有2000多行代码。实现时提炼了一个支付渠道对接的抽象类,用来封装渠道的差异。最终在这个系统中对接了有30多个渠道,类规模达到2000个。随着业务发展,问题越来越多。高峰期同时有5个渠道在并行开发,还有大量的其他渠道对接问题需要修复。多个人同时修改一个项目代码导致版本控制的工作骤增。上线频发引起服务中断也让业务方很不满。诸多问题,在前面的文章中都有描述。