【金融案例】马蜂窝支付中心架构演进
|
副问题[/!--empirenews.page--]
(讯)为了更好地支持买卖营业营业的快速成长，马蜂窝付出中心从最初只支持基本付出和退款的「刀耕火种」阶段，经验了架构调解的「刮骨疗伤」阶段，完成了到实现综合产物平台形态的「沉淀蓄力」阶段的演进。 今朝，马蜂窝付出中心集成了包罗基本订单、收银台、路由打点、付出通道、清理查对、报表统计等多种手段，为马蜂窝度假（平台、定制）、交通（机票、火车票、用车）、旅馆（开放平台、署理商）等近20条营业线提供处事。本文将环绕付出中心整体演变进程中差异阶段的焦点部门举办扼要先容。 付出中心1.0 初期为快速相应营业的付出、退款以及一些基本需求，付出中心首要认真接入付出通道（付出宝、微信、连连等），由各营业线别离实现收银台，然后挪用付出中心举办付出。营业体系、付出中心和第三方通道的交互流程图如下：
各体系交互流程为： 营业线将订单信息封装后哀求到付出中心 付出中心对订单信息扼要处理赏罚后增进付出信息哀求到第三方付出通道 第三方付出通道将付出功效异步回调到付出中心 付出中心将第三方相应的数据浅显处理赏罚后同步关照到各营业体系 营业体系举办逻辑处理赏罚、用户关照及页面跳转等 营业成长初期，营业量较小，买卖营业场景也较量单一，这样的计划可以快速相应营业需求，实现成果。但当营业伟大性不绝进步，接入的营业也越来越多时，该架构就显得力有未逮了。各营业线必要一再开拓一些成果，而且付出中心不具备整体管控手段，开拓维护本钱越来越大。首要的题目包罗：
为了分身对快速成长中的营业的需求相应和体系的高可用性，担保线上处事的质量，我们快速举办了架构调解，开始了向付出中心2.0的演进。 付出中心2.0 2.0架构将各营业的民众买卖营业、付出、财政等沉淀到付出中心，并首要办理了以下三个首要题目： 成立基本订单、付出、财政同一系统，抽象和封装民众处理赏罚逻辑，形成同一的基本处事，低落营业的接入本钱及一再研发本钱； 构建安详、不变、可扩展的体系，为营业的快速成长和创新需求提供基本支撑，办理营业「快」和付出「稳」之间的抵牾； 沉淀焦点买卖营业数据，同时为用户、商家、财政提供大数据支撑。 2.1焦点手段 付出中心2.0是整个买卖营业体系快速成长的重要时段。在此进程中，不只要举办架构的进级，还要担保处事的不变。 今朝付出中心对营业提供的首要手段包罗：
针对马蜂窝营业的特点，今朝支持的焦点买卖营业场景包罗：
2.2架构计划 演进进程中，起首是对相对独立，同时作为同一系统基本的网关举办模块化。付出网关对外抽象出付出、退款、查询这些尺度哀求，然后在网关基本上慢慢梳理各付出通道，并慢慢抽取出基本订单模块，解耦营业成果与付出成果，同时可支持伟大的营业场景。今朝的体系成果整体架构如下：
如图所示，从架构上首要分为三个条理： 产物层：组合焦点层提供的付出手段，对终端用户提供收银台、对运营财政职员提供运营财政体系 焦点层：付出中心焦点模块，包罗基本订单、付出路由、付出通道等 支撑层：用来支撑整个体系的基本办法，包罗监控报警、日记、动静行列等 2.2.1产物层 产物层首要包括斲丧者可见的收银台、付出打点靠山和财政核算、对账的财会体系。本文重点先容收银台的计划思绪。 收银台 收银台包括H5收银台和PC收银台两部门： 移动端：
PC端：
如上图所示，收银台首要由三部门构成：订单根基信息（含订单号及付出金额）、订单详情（含日期信息、商品信息及基本信息）、付出方法（平台付出、名誉付出等）。 因为收银台是整个付出中心面向用户的独一进口，用户体验及安详性至关重要。为同时支持营业本性化和用户的同等性体验，收银台首要是通过定制化和设置化的方法实现。对营业同窗来讲接入也很是简朴，仅需通过订单号跳转至收银台页面，后续流程均由付出中心完成。 用户下单后达到收银台页面，收银台通过订单所属营业线、付出金额、是否合单等信息，展示可用的付出通道。同时风控体系会从商品、订单、用户举动等维度举办监控，屏障高风险的付出渠道。付出渠道呈现妨碍时可在收银台停息展示。 （1）定制化 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
