使用微服务架构重构支付网关

凤凰牌老熊 · 公众号 · Java · 2017-03-09 00:05

正文

请到「今天看啥」查看全文

支付网关承载大量的功能，实际上，它是将API网关和业务逻辑都混在在一起实现。签约、支付、代扣、验证，都在这一个类中实现，代码行数超过1000行，逻辑十分复杂。

除了风控是进程外调动，其他的服务都是进程内调用，通过springframework来管理各个service。

最终落地调用的支付渠道，是通过抽象的接口来对网关封装渠道的差异。

在这个系统中对接了有30多个渠道，类规模达到2000个。随着业务发展，问题越来越多。高峰期同时有5个渠道在并行开发，还有大量的其他渠道对接问题需要修复。多个人同时修改一个项目代码导致版本控制的工作骤增。上线频发引起服务中断也让业务方很不满。对支付网关的改进是一个循序渐进的过程。这里参考Arun Gupta的微服务六种设计模式，来描述我们所做的改进。

新网关设计 (Chain Pattern)

为了分解旧网关的功能，我们设计了新的网关。在处理流程上，将其分为三个步骤，采用的是chain模式。

链式模式，如上图所示，它调用服务A来获取结果，而服务A是通过服务B来交互，B则会和C有交互。整个过程类似同步的HTTP请求、响应处理。这其中每个阶段的调用，都是阻塞式的同步调用。每一步都会增加一些业务逻辑处理。

原支付网关难以维护的一个重要原因是其所承载的功能过多。我们首先根据用户的使用场景，将支付网关承载的功能，按照支付产品来进行切分。支付产品包括快捷支付、网银支付、外卡支付等。不同的产品，其对应的操作所使用的参数和流程也不一样。以快捷产品为例，新网关接收到请求后，根据用户所选择的支付类型，分发到快捷支付产品接口。快捷支付产品接口调用工行借记卡通道来执行支付，通道最终落地到工行接口的调用来实现支付。支付操作完成后，工行接口通知到通道，通道通知到产品，最终逆向传递到网关接口，并最终发送给调用方。在这里面，支付网关负责分发、验签等基本功能，支付产品负责参数校验、路由、生成交易记录等功能。最终的支付操作是落地到支付渠道去执行。