【金融案例】马蜂窝支付中心架构演进

基础订单系统是连接交易业务线、支付中心和结算系统的桥梁，实现了业务和支付结算解耦。主要涵盖了业务创建订单、关单、支付、退款、回调通知等API模块。基础数据支持普通支付、合单支付、拆分支付、保险支付等多种场景的支付功能，各个系统的交互流程如下：

目前基础订单系统可支持如下两种特殊场景：

（1）一订单VS多商品

创建一个基础订单可以包含N个商品（商品信息包含商品名称、商品ID、单价、数量、折扣等，订单信息包含用户UID、手机号、支付金额、订单折扣等汇总基础信息），N个商品对应M个业务子订单(M≦N)，所有业务子订单的业务类型若一样则为普通模式，否则为搭售模式；每个业务订单对应一个对账单元（支付成功后会将支付信息同步给对账系统），一订单VS多商品的创单模式基本支持目前所有场景，包括未来可能的购物车模式。

（2）一订单VS多支付单

普通订单用户选择支付宝、微信等渠道会生成一个支付单；当金额超过5000元时可以选择拆分订单金额支付，此时会生成多个支付单；如果下单勾选保险就会走第三方合单支付，会生成两个支付单；同时拆分支付也会导致用户部分支付或者超额支付，监控会针对异常支付情况进行自动退款；大金额订单有10%以上的转换率提升,一订单VS多支付单模型更好的支持了马蜂窝的支付场景。

通道路由管理

通道路由主要包含两方面，一个是业务侧需要控制支付通道，一个是支付侧需要选择支付账户。

（1）支付账户管理

支付创建订单和处理回调等流程中，需要根据业务类型、支付方式和支付通道确定支付账号，早期版本这个对应关系是通过配置文件维护的。一个业务类型对应多个配置项，每新增一个业务需要增加多个配置，而且随着更多支付通道的接入，新增业务需要配置的信息也越来越多，不易维护。

经过优化，把现有的配置对应关系放到数据库中，数据表由业务类型、支付方式、支付通道唯一确定一个收款账号，支付账号的具体参数信息还是放在文件配置中。创建订单时根据业务类型、支付方式、支付通道查询收款账号，把账号信息记录到支付订单数据表，回调时直接从订单表查询支付账号。

（2）支付通道管理

目前对接了支付宝、支付宝国际、微信、京东支付、applepay、连连支付、银联2B等第三方通道，每一个通道下有多个支付产品。第三方通道的接口形式差异很大，但是都提供下单、退款、查询、支付通知、账单下载等标准功能。支付中心对这些支付通道做了一次封装，用一个抽象类作为基类，使用模版方法设计模式，在基类中定义了一个标准流程，具体的实现在通道各自的实现类中。客户类只需要关心基类的公共方法，和具体通道无关。

2.2.3支撑层

支撑层包含监控报警、日志管理、加签验签、配置管理、消息总线等模块。其中日志使用ELK进行收集管理，系统配置采用公司自研的分布式配置中心进行管理，消息总线也是使用公司二次封装的RabbitMQ进行消息分发及消费。

由于支付系统对可用性有极高要求以及支付数据的敏感性，支付中心独立实现了监控报警系统，下面将详细描述该监控报警系统的功能及设计思路。

监控系统

为保证监控的实时性及有效性，监控依赖的资源如数据库必须和业务库要进行隔离（避免鸡蛋放在同一个篮子里）。支付监控系统涵盖了API监控、服务性能监控、数据库监控等，能够提供统一的报警、分析和故障排除能力。从异常数据采集到故障问题主动发现及稳定性趋势分析，为支付体系优化提供数据支撑。

（1）监控后台

后台主要包含监控用户管理以及监控项创建管理，用户可以根据需求对应的监控项目，可配置的参数涵盖API请求地址、请求方式、可用性、正确性、响应时间等性能数据以及报警方式和策略；详细配置如下图：

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!