管家婆论坛

马蜂窝支付中心架构演进

发布时间:2019-07-12

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

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

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

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

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

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

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

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

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

  演进过程中,首先是对相对独立,同时作为统一体系基础的网关进行模块化。支付网关对外抽象出支付、退款、查询这些标准请求,然后在网关基础上逐步梳理各支付通道,并逐步抽取出基础订单模块,解耦业务功能与支付功能,同时可支持复杂的业务场景。目前的系统功能整体架构如下:

  产品层:组合核心层提供的支付能力,对终端用户提供收银台、对运营财务人员提供运营财务系统

  产品层主要包含消费者可见的收银台、支付管理后台和财务核算、对账的财会系统。本文重点介绍收银台的设计思路。

  如上图所示,收银台主要由三部分组成:订单基本信息(含订单号及支付金额)、订单详情(含日期信息、商品信息及基础信息)、支付方式(平台支付、信用支付等)。

  由于收银台是整个支付中心面向用户的唯一入口,用户体验及安全性至关重要。为同时支持业务个性化和用户的一致性体验,收银台主要是通过定制化和配置化的方式实现。对业务同学来讲接入也非常简单,仅需通过订单号跳转至收银台页面,后续流程均由支付中心完成。

  用户下单后到达收银台页面,收银台通过订单所属业务线、支付金额、是否合单等信息,展示可用的支付通道。同时风控系统会从商品、订单、用户行为等维度进行监控,屏蔽高风险的支付渠道。支付渠道出现故障时可在收银台暂停展示。

  为支持统一收银台下各业务线不同模式、不同展示的特性,使用工厂类继承的模式实现各业务数据及展示样式。

  收银台主要属性分为展示模块和通道路由,其中重复及默认功能的模块由抽象类用模板的方式实现,子类使用默认方法或者重写父类方法即可达到自定义的实现。

  收银台展示实现类已经实现了一套默认的收银台,其中包含大多数必须的组件(如倒计时,头部定制,订单详情等)。

  一般情况下,各个业务线仅需简单添加特定的实现类,即可生成一个清晰又丰富的页面

  收银台的配置化主要根据各业务的属性(业务类型、品类等)对后续操作做一定的流程处理配置化,比如:

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

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

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

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

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

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

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

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

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

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

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

  接口监控可以针对固定host IP绑定以及设置超时时间,监控请求支持GET、POST两种方式,POST方式可以设置固定请求参数辅助,监控频率支持分钟、秒两种级别配置;响应数据模块可以校验HTTP code是否异常,配置响应数据类型,比较检测返回key值,针对DB监控还可以设置DB查询超时时间;报警模块目前支持短信和邮件两种方式,可以设置最小、最大报警阈值,超过最大阈值每隔最大报警数会触发一次报警,规避了故障期间短信轰炸问题。

  为了实现最快监控频率10秒,同时可以支持成千上万的监控项并行运行,支付监控采用了多进程管理的方式。父进程创建指定数量的子进程,每个子进程完成固定数量的监控任务退出任务,此时父进程实时监控子进程状态并创建新的子进程执行任务;父进程还可以接受外部信号完成服务重启以及停止,流程如下:

  执行监控项会根据监控配置进行接口请求以及返回数据分析处理,然后通过Redis计数方式按报警策略进行报警通知。日常监控短信示例:

  上文提到,我们采用模块化的方式来解耦业务功能与支付功能。在这个过程中,每引入一个模块就会涉及到系统交互问题,因此最核心的便是数据一致性问题。针对数据一致性问题需要引入事务,实时、延迟校验以及补偿机制保证数据的最终一致性。从架构看是很清晰的,但是对于整个改造过程是艰难的,犹如给飞行的飞机更换发动机,所以我们也把这个过程形容为一个刮骨疗伤的阶段。

  支付服务都是由第三方支付通道提供的,支付通道存在不稳定性。比如用户用支付宝支付了一笔订单,由于各种原因,支付中心没有收到支付成功的通知,用户又用微信再次付款,导致重复支付。

  为了解决这个问题,支付中心采用定时扫描的策略,主动发现重复支付单并自动执行退款,不需要人工参与。退款流程中,退款单需要经过申请、审核、调用退款接口等流程,在调接口环节,可能会发生失败。调用失败的退款单,会根据退避算法发起重试,逐渐加大重试间隔,直到次数超过限制。失败单数量超过阈值、或者有订单处于失败时间超过阈值时会触发报警。自动处理不了的退款单可以人工检测,或线下退款。

  目前,马蜂窝支付中心已经具备支持多业务、多场景、多支付方式的能力,但想要实现一个真正意义上「百花齐放」的平台,还有很多地方需要改进和完善。

  即将到来的支付中心3.0将以微服务的思想把单体应用按照业务进行解耦,会逐渐从一个高耦合的单一系统演变为众多子系统组成的高并发、高可用、支持更多交易支付场景的分布式系统。微服务化拆分后,在系统结构上将更加清晰,但对于整体系统的开发管理和维护也将带来更大的挑战。

  伴随马蜂窝「内容+交易」的战略升级,支付中心也会探索更多的支付方式和能力,持续为各业务线赋能。4685本港台开奖结果


友情链接:
Copyright 2018-2021 主页 版权所有,未经授权,禁止转载。