去哪儿支付系统自2011年搭建以来，在五年的时间里逐渐从一个高耦合的单一系统发展为众多子系统组成的高并发、高可用、支持多种交易支付业务的分布式系统。业务从最初的非代收到现在多种非代收、代收场景的支持，B2B业务的从无到有，支付方式从单一网银支付到现在银行卡、拿去花、代金券、红包、立减、积分、趣游宝等多种的组合，订单从单笔支付到多个订单同时支付和多次付款。下面对整体的演变过程进行简单的介绍。

1. 支付系统1.0

新的业务系统初建时，业务逻辑相对简单，业务量也比较小，为了能够快速实现功能，发布上线，大多数团队都会把所有的逻辑都耦合在一个系统。这对于初期业务的快速迭代是有一定好处的。毫不例外，支付交易系统也采用了这样的方式。如下图所示。

一个支付系统不例外包括几个重要组成部分：收银台、交易、支付、网关、账务。

收银台：用于展示支付详情、提供各种多样支付方式的选择

交易：收单规则和交易规则处理

支付：处理各种组合的支付方式，如银行卡、用户余额、信用付、拿去花、红包、代金券、立减、积分等

账务：用来记录所有交易、资金往来的明细，财务会计记账

网关：用于对接银行通道、第三方支付通道（微信、支付宝）

在业务量不大的情况下，这样的系统结构没有问题。随着更多业务的接入，各种复杂的功能逻辑加入，系统处理起来有点吃力，主要表现以下几个方面：

1、系统容灾能力：所有的功能都集中在一起，一但某个功能出问题，直接影响全局

2、系统扩容：在一个分布式系统中，决定系统性能的取决于最差的部分，整体扩容效果差

3、开发成本高：团队成员的增加，功能的复杂，多个项目并行时，开发效率极低

4、更多更复杂业务：结构不合理，不能满足业务发展需要

5、系统职责混乱：如收银台只是简单维护银行列表

在这样的一些背景下，2.0系统应运而生。

2. 支付系统2.0

2.0时代是支付交易系统快速发展的一个重要时段。在此过程中，不仅要从系统架构上进行服务化的拆分，而且需要支持更复杂的业务。

2.1 服务化拆分

2.1.1 网关拆分

首先对相对比较独立的网关进行拆分，网关在整个支付系统中属于底层基础服务，是比较重要的基础设施。对外能够提供怎么样的支付交易服务，很多都取决于网关能力的建设。

网关有一些显着特征，它是一个可高度抽象的业务。对外可以抽象到支付、退款、查询这些标准的服务。因此优先将这部分拆分，一是为了能够更好的打好基础，二是其能够独立的发展，三是这部分也相对好实施。

网关的拆分路由系统起到至关重要的作用，对于多通道支付的支持和智能化选择发挥着巨大作用。

2.1.2 账务系统的拆分

做交易支付业务，重要的一件事要记清楚账。记账可以很简单的记录来往流水，也可以更加专业的记财务会计账。在拆分前系统只是记录了交易流水，拆分后实现了更加专业和复杂的复式记账。

新账务系统的一个简单流程图：

2.1.3 会员系统的独立

会员系统与交易系统本身只是一个依赖关系，在交易支付系统看来只是一个业务系统。比如会员充值业务可以看做是一笔支付交易。为了摆正各自角色，对于会员部分从原有系统中独立出来。这样一来各自定位更加清晰明了，也方便了各自独立发展。现在的会员系统不仅仅只有一个余额，而且引入实名服务、各种资产管理、交易管理等。

2.1.4 基础服务的拆分

更多的系统拆分独立后，原有公用的某些功能会多次复制重复。为方便集中管理维护，通过对各系统公用逻辑更能的统一，提供集中的基础服务，如安全服务、加验签服务、通知服务、基础信息查询等，如下图中talos系统。

上述几个服务的拆分更多是为从业务方面或者技术驱动来考虑。而典型的交易支付过程是有一个时序过程的。比如下单->交易->收银台->支付->网关->银行。这样一个先后时序也是一个比较好的系统拆分方案。根据这样的一个时序，我们针对性的对每个阶段做了拆分（排除网关和银行部分），如下过程：

1、交易核心(Apollo)

关注于收单方式和交易类型。

收单方面系统已经支持单笔订单支付、批量订单支付。交易类型目前支持直接交易、担保交易、直接分账交易、担保分账交易、预授权交易等。在批量订单支付时各种交易类型可以进行混合。且分账交易同时支持多个账户。交易类型除了上面正向交易外，系统还支持很多后续流程交易、如预授权确认、预授权撤销、退款、担保撤销、二次分账交易等。

多种多样的交易源于各事业部业务的复杂性，比起标准化的支付系统，我们提提供了更多灵活方便的业务来支持。

2、支付核心(minos)

关注于支付方案的组合和执行。

支付方式：银行卡、支付宝、微信、拿去花、趣游宝、余额、积分、红包、代金券、会员红包、立减等多种方式支付。

支付组合：可以单一使用，也可以进行组合使用。组合场景区分资金类型，如银行卡、支付宝、微信每次只能选择一个，其它类资金可多个同时使用。

在有上面基础的支持下，对于同一批次交易订单可也进行多次的组合支付扣款，如酒店信用住付款、拿去花还款等业务场景。下图是支付核心（minos）在系统中的位置：

3、收银台

收银台直接面向用户，因此支付体验至关重要。据统计在支付环节放弃的订单占比还比较大。因此一个方便、简洁易用的收银台对于订单转换是有很大帮助的。目前系统支持的收银台主要有app(native)、app前置收银台、touch、PC预授权收银台、PC多单收银台、PC英文版收银台、PC标准收银台等。收银台在系统中的位置如下图所示。

无线端收银台：

PC端收银台：

4、API接入层

交易系统更多的服务是通过后台接口来完成的，这部分占到整体系统很大的业务比重。如支付后期的资金流转、逆向操作退款等。但也有一些是用来查询一些交易订单相关性的信息。在此背景下，对于api接入层采用读写分离方式处理。如下图ares系统，将底层的各dubbo服务包装提供各种查询类服务。Odin系统是可读写，更多的关注跟核心业务相关的写，如解冻、退款、撤销等。

截止目前，整体系统的一个大体结构如下图所示：

以上是去哪儿网支付系统架构演进过程中会的一些服务化拆分，关于在服务化拆分过程中遇到的一些问题与挑战，拆分过程中的DB处理、异步化，监控&报警等内容会在下篇中为大家介绍。

作者简介：吕博，去哪儿网金融事业部研发工程师，毕业于吉林大学，2012年加入去哪儿网。 致力于支付平台研发和支付环节的基础服务建设。

点击查看：吕博：去哪儿网支付系统架构演进（下篇）