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

基本订单体系是毗连买卖营业营业线、付出中心和结算体系的桥梁，实现了营业和付出结算解耦。首要涵盖了营业建设订单、关单、付出、退款、回调关照等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哀求地点、哀求方法、可用性、正确性、相应时刻等机能数据以及报警方法和计策；具体设置如下图：

（编辑：湖南网）

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