去哪兒支付系統自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年加入去哪兒網。 致力於支付平臺研發和支付環節的基礎服務建設