马蜂窝支付中心架构演进

640?wx_fmt=gif

点击上方“马蜂窝技术”,关注订阅更多优质内容

为了更好地支持交易业务的快速发展,马蜂窝支付中心从最初只支持基础支付和退款的「刀耕火种」阶段,经历了架构调整的「刮骨疗伤」阶段,完成了到实现综合产品平台形态的「沉淀蓄力」阶段的演进。

目前,马蜂窝支付中心集成了包括基础订单、收银台、路由管理、支付通道、清算核对、报表统计等多种能力,为马蜂窝度假(平台、定制)、交通(机票、火车票、用车)、酒店(开放平台、代理商)等近 20 条业务线提供服务。本文将围绕支付中心整体演变过程中不同阶段的核心部分进行简要介绍。

支付中心 

1.0  

初期为快速响应业务的支付、退款以及一些基础需求,支付中心主要负责接入支付通道(支付宝、微信、连连等),由各业务线分别实现收银台,然后调用支付中心进行支付。业务系统、支付中心和第三方通道的交互流程图如下:

640?wx_fmt=png

各系统交互流程为:

  1. 业务线将订单信息封装后请求到支付中心

  2. 支付中心对订单信息简要处理后增加支付信息请求到第三方支付通道

  3. 第三方支付通道将支付结果异步回调到支付中心

  4. 支付中心将第三方响应的数据简易处理后同步通知到各业务系统

  5. 业务系统进行逻辑处理、用户通知及页面跳转等

业务发展初期,业务量较小,交易场景也比较单一,这样的设计可以快速响应业务需求,实现功能。但当业务复杂性不断提高,接入的业务也越来越多时,该架构就显得力不从心了。各业务线需要重复开发一些功能,并且支付中心不具备整体管控能力,开发维护成本越来越大。主要的问题包括:

  • 维护成本高:各业务线需单独维护收银台,调用支付系统完成支付,需分别保证幂等、安全等问题

  • 容灾能力差:所有功能集中在一个大模块里,某个功能出问题,直接影响全部

  • 结构不合理:架构单一,不能满足复杂业务场景

  • 系统职责乱:收银台维护了收款方式及部分业务路由,缺乏统一的管控

为了兼顾对快速发展中的业务的需求响应和系统的高可用性,保证线上服务的质量,我们快速进行了架构调整,开始了向支付中心 2.0 的演进。

支付中心 

2.0  

2.0 架构将各业务的公共交易、支付、财务等沉淀到支付中心,并主要解决了以下三个主要问题:

  • 建立基础订单、支付、财务统一体系,抽象和封装公共处理逻辑,形成统一的基础服务,降低业务的接入成本及重复研发成本;

  • 构建安全、稳定、可扩展的系统,为业务的快速发展和创新需求提供基础支撑,解决业务「快」和支付「稳」之间的矛盾;

  • 沉淀核心交易数据,同时为用户、商家、财务提供大数据支撑。

2.1 核心能力

支付中心 2.0 是整个交易系统快速发展的重要时段。在此过程中,不仅要进行架构的升级,还要保证服务的稳定。

目前支付中心对业务提供的主要能力包括:

  • 9
    点赞
  • 46
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值