Qarch大会 | 携程支付引擎的重构

洪光明2016年加入携程，在金融事业部担任开发总监，目前主要参与和负责支付后台系统的重构。

大家好，我是来自携程金融事业部的洪光明，负责携程支付后台的开发工作。

 今天分享的题目是“携程支付引擎的重构”。下图是携程支付平台现有的系统架构： 

 和很多有一定岁数的系统一样，携程现有的支付系统经历多年发展之后，系统在处理日均百万笔的交易和年千亿级的交易流水的压力之下，越来越显得力不从心了。主要体现在： 

1. 迫于业务压力，缺乏统一的支付流程设计，没有统一的交易明细查询系统；

2. 没有独立的账务系统，严重依赖报表；

3. 业务实现使用了大量的存储过程，可扩展性和可维护性欠佳；

4. 现有的数据库设计难以支持业务的持续发展；

5. 系统间存在复杂的网状调用关系，难以支持新业务的引入，尤其是一些创新的金融产品的设计。

 重构的一个大的设计思想是：根据业务流程，分成支付计划和支付执行两大核心服务。 

 支付计划服务主要提供支付请求校验、支付收单、支付路由选择、风控检查、支付计划生成等职责；支付引擎服务主要提供支付计划的执行、支付渠道的连接、支付结果的通知等支付核心动作。 针对每种支付渠道（银行卡、第三方支付、礼品卡、钱包余额等），分别封装和提供独立的服务。 新支付系统的总体架构如下： 

 在新的支付系统架构下，一个典型的使用微信/支付宝进行支付的流程图如下，系统间的调用关系相比老的支付系统更加简单清晰。 

 接下来给大家介绍一下我们的清算对账系统。 清算对账系统主要功能是，对于通过多个支付渠道完成的交易和结算的资金，与我们自己系统的记账结果进行核对，以确保资金结算单的准确无误。对于出现差异的交易，能够第一时间发现并且介入处理。 我们的对账系统每天要完成将近百个不同支付渠道的对账工作，数据源包含自动获取对账单和运营人员手工上传两种，极大的提高了运营效率，很好的确保了资金安全。 

 支付业务的稳定性：由于业务需要，我们对于支付业务的稳定性有很高的要求。下图是过去一周的支付可用性数据： 

 我们会根据不同渠道的支付权重以及中断时长来计算总的支付可用性（ATP），在过往实践中，主要通过如下方式来提高支付可用性： 

1. 从架构层面：从一开始进行架构设计的时候，保持高的支付可用性就被考虑进来。例如，订单和支付分离，允许用户对同一个订单多次尝试支付。一些同步的支付方式转成异步来完成，以支持异常情况下的自动重试等。 

2. 从技术层面：采用分布式的服务体系、支持高可用的服务架构、消除单点故障导致的服务不可用，提高系统的容错性；

3. 从运维层面：建设完善的监控和报警设施，对于关键业务提供高准确性的预测基线，一旦系统出现异常能够第一时间发现，并且快速响应。

 以上是对携程支付引擎重构项目的一个大体的介绍，谢谢大家。 

去哪儿技术嘉年华去哪儿工程师内部学习交流平台。秉承务实、创新的宗旨，致力于促进公司内部各开发团队之间技术业务交流，促进个人以及团队能力提升，营造技术学习文化氛围。
2016年技术嘉年华分三个场次：Qmobile-移动端开发方向、Qdata-数据相关方向、Qarch-业务系统架构方向，分别在8月三个周六进行；我们也邀请了携程、艺龙的小伙伴共同分享交流。
本文根据Qarch上主题演讲内容编辑整理，方便更多小伙伴一起来交流学习。