劉慎寶 :京東集團財務系統架構設計之路

【IT168&ITPUB專稿】本文根據劉慎寶老師在2018年10月17日第十屆中國系統架構師大會(SACC2018)現場演講內容整理而成。

講師簡介：

京東集團高階架構師，10+年網際網路研發專家。2010年入職京東並歷經幾乎所有618和雙11挑戰。精通高併發服務搭建和業務建模，曾多次主導京東財務系統架構升級和資料庫升級，主導結算魔方重構，訂單臺賬最佳化、價保最佳化等重大研發專案，對財務系統有深刻理解。

正文：

不管是6.18，還是雙11,對於財務系統來說，壓力都非常大。電商大促，意味著每分鐘幾十萬訂單需要去支付、對賬，然後才能進行生產，進行發票列印、資金結算，最終生成財務憑證。在財務系統支撐業務員執行過程中，京東走過了很多坑，希望這些經歷，能幫助更多企業未雨綢繆。

京東的財務系統大概分三個階段：京東分別用V1.0、V2.0和V3.0來歸納。

V1.0：業務領先，系統跟隨

V1.0的時候，用八個字來形容，那就是“業務領先，系統跟隨”。在2010年之前，京東業務主要聚焦在3C品類 。那個時候，網際網路業務剛剛起步，主要以業務為中心，系統起到支撐業務的作用。對於財務系統來說，最大的需求就是快速搭建、迎合需求。這個時候的框架，用的是.NET的平臺，語言用的C#，用membercache解決靜態資料的問題，應對促銷流。動態資料的讀取問題，用資料庫複製方式來解決。

V1.0階段很快成為過去。2012年起，京東全品類擴張，結算型別更加多元化。京東財務系統也就進入了V2.0階段。

V2.0：野蠻成長，系統林立

這一階段的主要特色是“野蠻生長，系統林立”。京東財務的整個系統全部拆分成多個系統，系統之間相互關聯。

為什麼會形成這種特點?根源在於業務快速擴張和架構的大調整。

“站在巨人的肩膀上”，V2.0之後，京東財務系統選擇了開源框架。從.NET的平臺切換到Java平臺。

當時的系統是怎樣一種現狀呢?系統林立。以結算系統為例，當時的京東有38條業務線，有20個結算系統。

當時訂單量以幾十倍的速度在增長，新上線了圖書業務，和以前業務相比，新業務完全不同，體現在三點上。

首先，銷售方式不同。包括實體書和電子書。在3C時代，京東只銷售實體商品。

其次，採購方式不同。圖書分供應商採購、總供應商結算，跟以前的邏輯完全不同，之前的結算系統沒有這樣的流程。

其三，結算方式不同。以前京東採購商品入庫，然後結算。現在是由廠商配送，京東除了跟供應商結算貨款外，還要結算安裝費、售後服務費、售後維修相關的內容。

為了保持原有業務系統穩定增長，又要滿足新業務系統快速發展需求，京東的做法是，來一個新業務建造一套新系統。

系統越來越多，研發和維護的成本越來越大，該怎麼面對未來的成本壓力，未雨綢繆-開啟平臺化整合。

進入2015年，業界有一個很出名的平臺結構，那就是中心化結構。上層是例項，中間有中間層，底層是各種DB。中間層負責資料的儲存、轉化、查詢。到設計的時候，讓程式設計師專注於業務邏輯開發，不操心底層業務邏輯，大大提高了研發效率。

這種模式在特定階段下很完美，確實能達到效果，但是我們沒有采用!

在業務量恆定的情況下，中心化的結構沒有問題，但是如果業務量持續增大，每天訂單量增加到5000萬，這樣的架構就會出現問題。首先，這種中心化的結構，它的中心點就是最大的瓶頸點，在大資料互動的時候容易出現問題。比如：以現在2000萬的訂單量計算，如果要積累一年的資料，底層的資料庫得有多少?如果按照500個資料庫來算，任何一個故障，所有中間層就會卡死，系統拒絕服務，導致全域性性的事故發生。

1、 資料庫硬體出現問題

2、 區域性資料庫過熱

V3.0：涅槃演化，歸納統一

從2015年以後，京東財務系統進入第三階段，即“涅槃演化，歸納統一”的平臺整合階段。

“不要把所有雞蛋放在一個籃子裡“，形象的闡釋了系統搭建要保證穩定的分散式思想，但是這種分散式設計架構存在中心集中資料查詢成本問題 ，即要找出所有的“壞雞蛋”，需要去每個“籃子”挨個尋找。如果底層分佈太細，就會帶來另外的成本壓力。

總結來看，其實不管是哪種架構設計，都歸為兩類：一個是中心化思想，另一個是分散式思想。中心化思想它有利於資料統計，有利於資料彙總;但是分散式思想有利於分解資料風險。

如何把這兩種架構思路統一，集裝化部署?

京東財務的處理原則是，分佈化拆分。雙維度拆分，縱向和橫向。縱向按照生產熱度切分為生產資料和生產完畢的資料。這樣生產資料已經是很小的一部分了，將生產資料再橫向切分到N個計算中心裡，每個計算中心之間是相互獨立的。這樣即使有問題，也是其中某一個點有問題，不影響全域性。

計算中心的架構方式即為集裝化部署，一套程式碼，研發一次，測試一次，多次部署，大大降低研發成本。

集裝化，最基本的原則其實就是打包，把所有的例項DB快取統一打包成一個整體，它可以集中部署，部署之後就就可以向外提供服務。並且，可以實時上線，增加線上的服務流量;流量下降後，可以實時下線。資料在計算中心只做流轉，流轉結束後，計算中心就清空。

回到之前的話題，京東財務如何解決資料彙總的問題?如何快速找出全部的“壞雞蛋”?涉及到計算中心的一個特性：對下負責。簡單理解，透過資料自動驅動，把所有的資料自動流轉到下游。比如：出現壞資料，某個訂單有問題，或者出現支付異常的情況後，訂單會自動同步到異常處理平臺。因為，異常處理的資料畢竟這佔少數，這部分業務可以統一管理，簡言之將壞雞蛋自動彙總到一個籃子中。

另外，計算中心還有另外一個特性：對上負責。何為對上負責?對上就是指以服務介面方式註冊到接單中心，提供服務，從而支援動態擴容縮容屬性。

關於計算中心，還有一個插曲：京東價保系統的大促最佳實踐。

價保，即在價保週期之內，你京東有促銷降價，只要到點一下“申請價保”，系統就把差價退給你。大促期間的全週期價保，秒殺的巨大流量直接轉移到價格系統的申請量。且計算邏輯更復雜，如計算你的商品的價保額，要取以前的下單商品金額，然後按照新的促銷規則重新計算，再進行虛擬賠付、退款，每個系統都要互動，這中間的複雜性，是秒殺系統的幾十倍。

價保系統的大流量併發處理和高計算能力，由兩個計算中心群組成，第一個計算中心群是接單中心，負責對外接單;第二計算中心群是價格計算中心，負責呼叫各個不同的系統去核算可退金額。

下面我們來看一下使用集裝化的計算中心構建的財務整體架構圖

訂單、拆分、商品、配送、倉儲的資料，透過FDS資料轉接層，然後下面對應每一個模組，包括支付對賬、發票、清結算、資金、逆向。然後，最下面是抽象出來的各種平臺，包括業務監控中心、流量監控中心、規則引擎中心、GPU計算中心等。對應各大銀行進行清算。

以業務監控中心為例，所有的業務都會反映在資料上，反之透過資料變化可以實時生成業務監控報表，採集資料資訊可以來源於DB、ES、MQ、快取等，規則直接指令碼配置即可生效。如：監控支付系統是否出現支付異常，只要將訂單下單的訊息數量和對賬數量對比，如果差值過大，就一定是中間支付出了問題。

如何跟外部打交道呢?如果有介面，就透過財務介面來對接;如何沒有介面，就透過RPA對接。

在京東財務系統架構圖中，下面重點分享三個，即FDS、清算和RPA。

首先，FDS為什麼會產生?從業務端看，我們在京東下單，消費者付錢，收貨，這是一個整體過程。但在京東內部，被分為三個業務線，叫做“三流分離”，即資訊流、資金流和物流。

資訊流： 訂單相關使用者資訊和商品資訊;

資金流： 負責訂單收多少錢，應收多少，應付多少;

物流： 倉庫、運輸、配送。

三流相互獨立，但是京東財務系統環節，需要所有的資料資訊，只能三流集中後才能進行業務處理。比如：一個訂單要參與結算，需要這個訂單的資料，包括商品類別，屬於哪個供應商，商品的價格是多少，他採購價是多少……涉及到資訊流和資金流，並且還要確認這個訂單在多久以後才會參與結算，即物流。三流集中的就是由FDS系統來對接完成。

FDS其實就是一個資料處理平臺，是把上面資料全部接下來之後，透過一定規則配置，清理成一定的計費資料，然後再流入清結算系統。訂單資料經過清理，產生EBS中間表的資料，這樣就可以匯入EBS中間表。

其次是清結算。FDS把基本明細資料處理後，輸入清結算進行結算。結算系統從V2.0時代的20個系統，被歸納為一個平臺，叫做結算魔方。結算魔方的最佳化經過了三個階段，即平臺化、功能積木化、流程模組化。

在做結算的時候，京東遇到一個難題是，結算的牽扯的數量太大。如果每天按照500萬訂單來算，一年下來有多少資料?十年呢?京東的結算支援全生命週期防重，保證只要使用者提交過一次結算，絕不能提交第二次結算。

在資料體量小的時候很簡單，建立一個資料防重表就可以解決。但是在數量巨大的時候，還要保證效能高效，還要考慮硬體成本和研發成本，怎麼解決?我們的解決方案是補償性防重。

補償性防重?結算資料拆分為準生產資料資料和結算完畢歷史資料。

第一階段： 準生產資料資料實現防重

用關係型資料庫即可實現，降低研發成本，並且能保證介面效能，且組成計算中心可以橫向擴充套件排程。

第二階段： 二階段補償防重

結算曆史資料儲存在大資料平臺，降低儲存成本，而且方便後續分析

如果第一關防重過了，這時後臺啟動，自動去校驗歷史資料。如果歷史資料校驗確實在歷史當中存在，已經被結算了，那這個單子會被打回來。

除了內部系統，還涉及到外部跟供應商系統互動。跟供應商對賬，以前如果量小的時候，很簡單，只要把銷售明細，以excel的形式給供應商，按照這個結算就可以了。

但是，如果量大了後，每天幾千萬，一個excel根本玩不轉。這個時候，財務要有一個統一對外介面，用ERP系統跟供應商系統對接，來確認要結算哪些單據，讓供應商在系統裡面直接透過統一的介面做系統之間的相互互動，這樣就可以實現供應商自服務結算。

結算完要報稅，常規的做法是會計人員去銀行下載報稅檔案，然後匯入。京東財務用RPA自動化的方式來解決。RPA是一個流程自動化機器人，可以實現CS端和BS端的自動呼叫。可支援二維碼，滑塊驗證很多特性，可以實現銀行對接，自動報稅等跨系統重複性的工作。

歸納這麼多，是希望把過去的經驗進行梳理，提供給更多公司使用。為此，京東把一些優質模組(比如結算、財務)抽象出來，做成一個針對中小企業的解決方案，這就是朋貝系統。它可以針對ToC收付款，也可以針對ToB清結算，還能進行資金持有、管理。也能進行開票、報稅，還能和政府系統打交道。其中，也附帶了機器人功能。

走到V 3.0階段，那麼京東財務的下一階段目標是什麼?

未來是何種情景，誰都無法準確判斷，但是網際網路發展其實有一定規律可尋，從桌上型電腦、Internet，到現在的移動網際網路、物聯網，未來的發展趨勢一定是連線一切，未來將各種資料統一接入系統，甚至政策資訊等等。 透過聯通各種資訊的資料，做到更精準的資金預測，來支撐無界零售。

所以，京東財務系統的VX.0時代的目標是 “聯通一切，智慧無界”。