信也支付系统的演进之路

前言

信也科技在随着业务的不断发展，内部很多系统都经过了不断的拆分以及重构。最早期由所有人共同维护的一个单体应用，逐步拆解为前端、中台、基础平台以及技术框架等功能职责分明的以微服务为主的微服务体系架构。其中经历了很多次在不影响业务的前提下的技术全部重构，甚至于整个技术平台的更新换代(比如，后端从net技术体系全部迁移到java技术体系)，而支付系统的演进在这整个过程中，非常具有代表性。

支付场景

由于不同于电商和其他互联网支付场景，再本身由于业务模式的原因，信也科技支付系统不承担此类（促销活动减免 | 券 | 红包等）复杂的支付下单逻辑；只是作为纯粹的支付端，从而造成了轻收银台的支付模式。内部支付系统主要包括的功能有网银支付、协议支付、银行卡提现。

• 网银支付时需要输入银行账号和交易密码等多个步骤才能完成支付。此支付方式后期已完全摒弃。
  • 支付流程

• 协议支付时只需输入对应的验证码或支付密码即可完成支付。
  • 支付流程

• 提现时，通过用户的银行卡信息，通过渠道提至自己的银行卡
  • 提现流程

早期方案

• 前端提供简单的收银台功能
• 服务端提供订单创建、报文加解密&简单的配置路由功能
  

痛点

1. 无法做到灵活路由渠道，根据渠道的稳定性自动切换渠道
2. 协议支付场景下，现有基于用户绑定的银行卡，无法满足不同企业主体的接入；比如非主营业务用户，无法关联用户信息时，无可用银行卡信息；比如不同的企业主体实现不同的清算与结算
3. 渠道对接报文解析&证书管理硬编码在支付系统中，新增三方渠道会存在比较长的开发周期，且每个三方渠道接入都是以相同的流程以及相似的代码接入，未进行有效的抽象
4. 无法针对不同的渠道分配不同系统资源，避免不同的渠道的资源相互影响，并且根据不同的渠道定制不同的限流策略 ……

问题域分解

• 系统无法灵活的路由、自动切换渠道功能。主要的问题在于缺少必要的决策数据，本身来讲，决定渠道稳定性的因素有业务上的以及网络上的；比如业务上，每个渠道每个银行的支付成功率可能会不一样，我们需要实时获取每笔订单返回的状态结果指标数据，实时分析后提供支付路由进行预判。网络上，可能存在不同的渠道服务的可用性不同，而导致支付成功率不同，所以我们也需要收集每笔报文请求的响应日志，给支付路由提供素材。
  • 需求拆解
    
    • 实时采集订单渠道响应的状态以及结果，并按渠道以及业务请求方分类
    • 实时采集报文请求响应日志，并按渠道以及业务请求方分类
    • 单独提供服务质量指标计算服务QOS(Quality of Service)
      
  • 用例分析
    

• 通过消息系统实时采集订单信息&渠道日志信息
• 基于事件驱动实时计算QOS指标
• 支付路由实时请求QOS服务提供的QOS指标
• 还包括静态配置的路由策略信息，此处不再展开说明……
• 协议支付场景下，现有基于用户绑定的银行卡，无法满足不同企业主体的接入；不同的企业主体，可以理解为渠道的不同签约商户，也就是我们需要区分不同的商家的鉴权签约信息，不基于用户维度进行建模。
  • 需求拆解
    • 存在商户的概念，并需要匹配不同的渠道签约信息
    • 一个商户可能对应多个不同的业务产品（内部统称为子商户）
    • 同商户下的签约信息，可以互通；不同的商户下的签约信息需要隔离
  • 业务模型重构

• 由基于用户的银行卡信息，变更为聚合商户信息的鉴权银行卡信息（基于三要素），且可以根据商户进行逻辑甚至物理隔离
• 还包含不同商户的清算以及结算的改造，此处也不再继续展开说明……
• 对网关进行抽象，隔离证书管理、渠道服务以及实现动态配置化的三方渠道接入。
  • 需求拆解
    
    • 证书需要单独管理，证书的更新能自动同步至支付系统中
    • 可以根据渠道的不同质量，执行不同的部署策略，比如稳定性不同，混合部署可能会造成渠道相互干扰
    • 支付流程本身就是固化的流程，不同的是加密方式、请求响应报文解析、状态码解析等；可以固化步骤，然后以动态脚本或者动态配置的方式实现渠道的动态接入
  • 业务用例

• 证书单独由后台运营人员维护，因为证书是否过期，以及变更，属于运营人员的日常对接工作
• 证书通过深度存储提供的查询服务，被超级网关同步拉取，无需进行系统发版
• 抽象超级网关系统，承载请求三方的流量分发，请求&回调报文的动态装配，并推送实时的请求处理报文信息至MQ ……

业务域划分

按照现有业务场景，可以直接划分为如下业务域

• 订单上下文：承接所有支付请求的业务订单，为整个支付系统的核心业务域
• 鉴权上下文：外部用户需要支付时，特别是协议支付场景下，确认支付前需要进行银行卡鉴权，核心业务域
• 商户上下文：管理外部商户信息，为订单上下文&鉴权上下文提供基础支撑
• 渠道网关下文：主要为三方支付请求(请求报文装配—请求支付—返回报文解析)提供标准化的处理逻辑，为订单上下文提供支撑
• QOS：依赖渠道网关上下文的处理信息，输出指标为支付路由提供业务支撑
• 支付路由上下文：提供支付路由决策，根据业务配置&QOS的健康指标，为商户订单提供最优的支付渠道，为订单上下文提供业务支撑
• 配置上下文：证书配置，渠道对接的逻辑配置；通过yaml，指定比如渠道的加密、解密、报文参数解析、状态码解析判断等代码逻辑配置信息，为渠道网关上下文提供基础支撑

现有系统架构

总结

支付业务一直就是个独立且非常标准化的场景，由于公司业务的不断调整，以及支付系统的服务对象以及不同的定位等因素；我们把原来的支付模块，升级为独立承载业务对接的一套系统，且提供对外输出，产出实际的技术价值。没有最好的架构，只有最合适的。特别是在业务不断变化的前提下，一定要基于现状以及问题域，提供对应的解决方案，从而实现有效的重构，这样才能实现技术的最大价值。