【金融案例】马蜂窝支付中心架构演进
|
副标题[/!--empirenews.page--]
(讯)为了更好地支持交易业务的快速发展，马蜂窝支付中心从最初只支持基础支付和退款的「刀耕火种」阶段，经历了架构调整的「刮骨疗伤」阶段，完成了到实现综合产品平台形态的「沉淀蓄力」阶段的演进。 目前，马蜂窝支付中心集成了包括基础订单、收银台、路由管理、支付通道、清算核对、报表统计等多种能力，为马蜂窝度假（平台、定制）、交通（机票、火车票、用车）、酒店（开放平台、代理商）等近20条业务线提供服务。本文将围绕支付中心整体演变过程中不同阶段的核心部分进行简要介绍。 支付中心1.0 初期为快速响应业务的支付、退款以及一些基础需求，支付中心主要负责接入支付通道（支付宝、微信、连连等），由各业务线分别实现收银台，然后调用支付中心进行支付。业务系统、支付中心和第三方通道的交互流程图如下：
各系统交互流程为： 业务线将订单信息封装后请求到支付中心 支付中心对订单信息简要处理后增加支付信息请求到第三方支付通道 第三方支付通道将支付结果异步回调到支付中心 支付中心将第三方响应的数据简易处理后同步通知到各业务系统 业务系统进行逻辑处理、用户通知及页面跳转等 业务发展初期，业务量较小，交易场景也比较单一，这样的设计可以快速响应业务需求，实现功能。但当业务复杂性不断提高，接入的业务也越来越多时，该架构就显得力不从心了。各业务线需要重复开发一些功能，并且支付中心不具备整体管控能力，开发维护成本越来越大。主要的问题包括：
为了兼顾对快速发展中的业务的需求响应和系统的高可用性，保证线上服务的质量，我们快速进行了架构调整，开始了向支付中心2.0的演进。 支付中心2.0 2.0架构将各业务的公共交易、支付、财务等沉淀到支付中心，并主要解决了以下三个主要问题： 建立基础订单、支付、财务统一体系，抽象和封装公共处理逻辑，形成统一的基础服务，降低业务的接入成本及重复研发成本； 构建安全、稳定、可扩展的系统，为业务的快速发展和创新需求提供基础支撑，解决业务「快」和支付「稳」之间的矛盾； 沉淀核心交易数据，同时为用户、商家、财务提供大数据支撑。 2.1核心能力 支付中心2.0是整个交易系统快速发展的重要时段。在此过程中，不仅要进行架构的升级，还要保证服务的稳定。 目前支付中心对业务提供的主要能力包括：
针对马蜂窝业务的特点，目前支持的核心交易场景包括：
2.2架构设计 演进过程中，首先是对相对独立，同时作为统一体系基础的网关进行模块化。支付网关对外抽象出支付、退款、查询这些标准请求，然后在网关基础上逐步梳理各支付通道，并逐步抽取出基础订单模块，解耦业务功能与支付功能，同时可支持复杂的业务场景。目前的系统功能整体架构如下：
如图所示，从架构上主要分为三个层次： 产品层：组合核心层提供的支付能力，对终端用户提供收银台、对运营财务人员提供运营财务系统 核心层：支付中心核心模块，包括基础订单、支付路由、支付通道等 支撑层：用来支撑整个系统的基础设施，包括监控报警、日志、消息队列等 2.2.1产品层 产品层主要包含消费者可见的收银台、支付管理后台和财务核算、对账的财会系统。本文重点介绍收银台的设计思路。 收银台 收银台包含H5收银台和PC收银台两部分： 移动端：
PC端：
如上图所示，收银台主要由三部分组成：订单基本信息（含订单号及支付金额）、订单详情（含日期信息、商品信息及基础信息）、支付方式（平台支付、信用支付等）。 由于收银台是整个支付中心面向用户的唯一入口，用户体验及安全性至关重要。为同时支持业务个性化和用户的一致性体验，收银台主要是通过定制化和配置化的方式实现。对业务同学来讲接入也非常简单，仅需通过订单号跳转至收银台页面，后续流程均由支付中心完成。 用户下单后到达收银台页面，收银台通过订单所属业务线、支付金额、是否合单等信息，展示可用的支付通道。同时风控系统会从商品、订单、用户行为等维度进行监控，屏蔽高风险的支付渠道。支付渠道出现故障时可在收银台暂停展示。 （1）定制化 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
