沈阳地图-共享马蜂窝付出中心架构演进

为了更好地支撑买卖事务的快速开展,马蜂窝付出中心从开端只支撑根底付出和退款的「刀耕火种」阶段,阅历了架构调整的「刮骨疗伤」阶段,完结了到完结归纳产品途径形状的「沉积蓄力」阶段的演进。

现在,马蜂窝付出中心集成了包括根底订单、收银台、路由办理、付出通道、清算核对、报表计算等多种才能,为马蜂窝休假(途径、定制)、交通(机票、火车票、用车)、酒店(敞开途径、代理商)等近 20 条事务线供给服务。本文将环绕付出中心全体演化过程中不同阶段的中心部分进行扼要介绍。

一、付出中心 1.0

初期为快速呼应事务的付出、退款以及一些根底需求,付出中心首要担任接入付出通道(付出宝、微信、连连等),由各事务线别离完结收银台,然后调用付出中心进行付出。事务系统、付出中心和第三方通道的交互流程图如下:

各系统交互流程为:

  1. 事务线将订单信息封装后恳求到付出中心
  2. 付出中心对订单信息扼要处理后添加付出信息恳求到第三方付出通道
  3. 第三方付出通道将付出成果异步回调到付出中心
  4. 付出中心将第三方呼应的数据简易处理后同步告诉到各事务系统
  5. 事务系统进行逻辑处理、用户告诉及页面跳转等

事务开展初期,事务量较小,买卖场景也比较单一,这样的规划能够快速呼应事务需求,完结功用。但当事务杂乱性不断提高,接入的事务也越来越多时,该架构就显得无能为力了。各事务线需求重复开发一些功用,并且付出中心不具备全体管控才能,开发保护本钱越来越大。首要的问题包括:

  • 保护本钱高:各事务线需独自保护收银台,调用付出系统完结付出,需别离确保幂等、安全等问题
  • 容灾才能差:一切功用会集在一个大模块里,某个功用出问题,直接影响悉数
  • 结构不合理:架构单一,不能满意杂乱事务场景
  • 系统责任乱:收银台保护了收款办法及部分事务路由,缺少共同的管控

为了统筹对快速开展中的事务的需求呼应和系统的高可用性,确保线上服务的质量,咱们快速进行了架构调整,开端了向付出中心 2.0 的演进。

二、付出中心 2.0

2.0 架构将各事务的公共买卖、付出、财政等沉积到付出中心,并首要处理了以下三个首要问题:

  • 树立根底订单、付出、财政共同系统,笼统和封装公共处理逻辑,构成共同的根底服务,下降事务的接入本钱及重复研制本钱;
  • 构建安全、安稳、可扩展的系统,为事务的快速开展和立异需求供给根底支撑,处理事务「快」和付出「稳」之间的对立;
  • 沉积中心买卖数据,一起为用户、商家、财政供给大数据支撑。

2.1 中心才能

付出中心 2.0 是整个买卖系统快速开展的重要时段。在此过程中,不只要进行架构的晋级,还要确保服务的安稳。

现在付出中心对事务供给的首要才能包括:

  • 途径付出:用户能够运用微信、付出宝等第三方途径来完结付出
  • 方便付出:用户供给银行卡信息,进行快捷付出
  • 协议付出:用户完结授权后,能够在不打断用户体会的场景下进行快捷付出
  • 信誉付出:用户能够挑选花呗等分期产品进行透付出出
  • 境外付出:用户能够挑选境外付出通道完结境外产品的购买
  • 线下付出:用户能够挑选 ToB 通道完结特定场景的付出

针对马蜂窝事务的特色,现在支撑的中心买卖场景包括:

  • 付出和退款:适用于一般产品的购买及退款
  • 拆分付出:适用于限额或金额较大场景
  • 合单付出:适用于稳妥等分账到不同收款账号的场景

2.2 架构规划

演进过程中,首先是对相对独立,一起作为共同系统根底的网关进行模块化。付出网关对外笼统出付出、退款、查询这些规范恳求,然后在网关根底上逐渐整理各付出通道,并逐渐抽取出根底订单模块,解耦事务功用与付出功用,一起可支撑杂乱的事务场景。现在的系统功用全体架构如下:

如图所示,从架构上首要分为三个层次:

  • 产品层:组合中心层供给的付出才能,对终端用户供给收银台、对运营财政人员供给运营财政系统
  • 中心层:付出中心中心模块,包括根底订单、付出路由、付出通道等
  • 支撑层:用来支撑整个系统的根底设施,包括监控沈阳地图-共享马蜂窝付出中心架构演进报警、日志、音讯行列等

2.2.1 产品层

产品层首要包括顾客可见的收银台、付出办理后台和财政核算、对账的财会系统。本文要点介绍收银台的规划思路。

收银台

收银台包括 H5 收银台和 PC 收银台两部分:

移动端:

PC端:

如上图所示,收银台首要由三部分组成:订单根本信息(含订单号及付出金额)、订单概况(含日期信息、产品信息及根底信息)、付出办法(途径付出、信誉付出等)。

因为收银台是整个付出中心面向用户的仅有进口,用户体会及安全性至关重要。为一起支撑事务个性化和用户的共同性体会,收银台首要是经过定制化和装备化的办法完结。对事务同学来讲接入也十分简略,仅需经过订单号跳转至收银台页面,后续流程均由付出中心完结。

用户下单后抵达收银台页面,收银台经过订单所属事务线、付出金额、是否合单等信息,展现可用的付出通道。一起风控系统会从产品、订单、用户行为等维度进行监控,屏蔽高风险的付出途径。付出途径呈现毛病时可在收银台暂停展现。

(1)定制化

  • 为支撑共同收银台下各事务线不同方法、不同展现的特性,运用工厂类承继的方法完结各事务数据及展现款式。
  • 收银台首要特点分为展现模块和通道路由,其间沈阳地图-共享马蜂窝付出中心架构演进重复及默许功用的模块由笼沈阳地图-共享马蜂窝付出中心架构演进统类用模板的办法完结,子类运用默许办法或许重写父类办法即可到达自界说的完结。
  • 收银台展现完结类现已完结了一套默许的收银台,其间包括大多数有必要的组件(如倒计时,头部定制,订单概况等)。
  • 一般状况下,各个事务线仅需简略添加特定的完结类,即可生成一个明晰又丰厚的页面

(2)装备化

收银台的装备化首要依据各事务的特点(事务类型、品类等)对后续操作做必定的流程处理装备化,比方:

  • 依据后端路由对收银台展现层做不同的处理,用户看到的可支撑的通道列表(微信、付出宝等),以及排序置顶打符号等
  • 满意不同场景、不同事务在同一种付出办法下收款到不同的收款账号
  • 依据场景不同,走不同的结算办法,以及结算途径等

2.2.2 中心层

付出中心中的中心模块,包括根底订单、付出路由、付出通道等。

根底订单

根底订单系统是衔接买卖事务线、付出中心和结算系统的桥梁,完结了事务和付出结算解耦。首要包括了事务创立订单、关单、付出、退款、回调告诉等 API 模块。根底数据支撑一般付出、合单付出、拆分付出、稳妥付出等多种场景的付出功用,各个系统的交互流程如下:

现在根底订单系统可支撑如下两种特别场景:

(1)一订单 VS 多产品

创立一个根底订单能够包括 N 个产品(产品信息包括产品名称、产品 ID、单价、数量、扣头等,订单信息包括用户 UID、手机号、付出金额、订单扣头等汇总根底信息),N 个产品对应 M 个事务子订单 (M≦N),一切事务子订单的事务类型若相同则为一般方法,否则为搭售方法;每个沈阳地图-共享马蜂窝付出中心架构演进事务订单对应一个对账单元(付出成功后会将付出信息同步给对账系统),一订单 VS 多产品的创单方法根本支撑现在一切场景,包括未来或许的购物车方法。

(2)一订单 VS 多付出单

一般订单用户挑选付出宝、微信等途径会生成一个付出单;当金额超越 5000 元时能够挑选拆分订单金额付出,此刻会生成多个付出单;假如下单勾选稳妥就会走第三方合单付出,会生成两个付出单;一起拆分付出也会导致用户部分付出或许超量付出,监控会针对反常付出状况进行自动退款;大金额订单有 10% 以上的转换率提高, 一订单 VS 多付出单模型更好的支撑了马蜂窝的付出场景。

通道路由办理

通道路由首要包括两方面,一个是事务侧需求操控付出通道,一个是付出侧需求挑选付出账户。

(1)付出账户办理

付出创立订单和处理回调等流程中,需求依据事务类型、付出办法和付出通道确认付出账号,前期版别这个对应联系是经过装备文件保护的。一个事务类型对应多个装备项,每新增一个事务需求添加多个装备,并且跟着更多付出通道的接入,新增事务需求装备的信息也越来越多,不易保护。

经过优化,把现有的装备对应联系放到数据库中,数据表由事务类型、付出办法、付出通道仅有确认一个收款账号,付出账号的具体参数信息仍是放在文件装备中。创立订单时依据事务类型、付出办法、付出通道查询收款账号,把账号信息记录到付出订单数据表,回调时直接从订单表查询付出账号。

(2)付出通道办理

现在对接了付出宝、付出宝世界、微信、京东付出、applepay、连连付出、银联 2B 等第三方通道,每一个td通道下有多个付出产品。第三方通道的接口方法差异很大,可是都供给下单、退款、查询、付出告诉、账单下载等规范功用。付出中心对这些付出通道做了一次封装,用一个笼统类作为基类,运用模版办法规划方法,在基类中界说了一个规范流程,具体的完结在通道各自的完结类中。客户类只需求关怀基类的公共办法,和具体通道无关。

2.2.3 支撑层

支撑层包括监控报警、日志办理、加签验签、装备办理、音讯总线等模块。其间日志运用 ELK 进行搜集办理,系统装备选用公司自研的分布式装备中心进行办理,音讯总线也是运用公司二次封装的 RabbitMQ 进行音讯分发及消费。

因为付出系统对可用性有极高要求以及付出数据的敏感性,付出中心独立完结了监控报警系统,下面将具体描述该监控报警系统的功用及规划思路。

监控系统

为确保监控的实时性及有效性,监控依靠的资源如数据库有必要和事务库要进行阻隔(防止鸡蛋放在同一个篮子里)。付出监控系统包括了 API 监控、 服务功能监控、数据库监控等,能够供给共同的报警、剖析和毛病扫除才能。从反常数据收集到毛病问题自动发现及安稳性趋势剖析,为付出系统优化供给数据支撑。

(1)监控后台

后台首要包括监控用户办理以及监控项创立办理,用户能够依据需求对应的监控项目,可装备的参数包括 API 恳求地址、恳求办法、可用性、正确性、 呼应时刻等功能数据以及报警办法和战略;具体装备如下图:

接口监控能够针对固定 host IP 绑定以及设置超时时刻,监控恳求支撑 GET、POST 两种办法,POST 办法能够设置固定恳求参数辅佐,监控频率支撑分钟、秒两种等级装备;呼应数据模块能够校验 HTTP code 是否反常,装备呼应数据类型,比较检测回来 key 值,针对 DB 监控还能够设置 DB 查询超时时刻;报警模块现在支撑短信和邮件两种办法,能够设置最小、最大报警阈值,超越最大阈值每隔最大报警数会触发一次报警,规避了毛病期间短信轰炸问题。

(2)监控中心

为了完结最快监控频率 10 秒,一起能够支撑不计其数的监控项并行运转,付出监控选用了多进程办理的办法。父进程创立指定数量的子进程,每个子进程完结固定数量的监控使命退出使命,此沈阳地图-共享马蜂窝付出中心架构演进刻父进程实时监控子进程状况并创立新的子进程履行使命;父进程还能够承受外部信号完结服务重启以及中止,流程如下:

(3)监控报警

履行监控项会依据监控装备进行接口恳求以及回来数据剖析处理,然后经过 Redis 计数办法按报警战略进行报警告诉。