業務架構是一個新型的名詞，最早是業務端和系統架構，隨著業務的發展，業務的需求和系統之間需要架構做轉換。但是，所有的系統不穩定時期，往往是系統升級的時期，系統改造時產生的陣痛，京東支付在這方面的實踐經驗。

　　為何要業務架構變革

　　互聯網支付的發展從艾瑞的數據看，2015年整個支付交易規模11萬億，到2018年達到22萬億。盡管和銀行的規模相比有些低，但是互聯網金融和銀行金融區別：互聯網金融的特點是金額小，但是筆數多。銀行的手續費非常高，金額大去銀行，小金額不劃算。而互聯網的促銷時手續費非常低，幾分錢而已。這個金額下，交易的筆數遠超銀行，而且快速增長。2015-2018交易金額翻一番，交易的筆數也要翻番。系統的話互聯網金融系統和金額無關，而是和交易筆數相關，快速增長，是機遇和挑戰。

　　業務產品快速變化，之前是靠業務收單為主，并且計算手續費，非常簡單的業務模式，隨著2011年業務的發展，現在程度互聯網金融遠不是之前第三方支付，現在有銀行、保險、證券、基金等，因此互聯網金融都想涉足，業務的形態和流程的復雜度，必然會極速化的發展變化，而且要求用戶體驗達到極致。

　　京東小金庫背后是貨幣基金的業務，有更好的基金出來，會用小金庫購買收益率高的基金，購買行為系統要做業務流程，想貨幣基金立即贖回，在帳目上做應收款，然后做報收款等等。基金的流轉非常復雜。同時，需要提高研發的開發效率。互聯網的競爭是以天來計算，哪怕幾個小時，業務的規模和占據的契機完全不一樣。還要保證質量和可靠運行。

　　什么是業務架構變革

　　架構變革是架構變遷迭代重要的一環，如果系統架構不能解決問題的話，靠人為的調整很難滿足業務發展的需要。因此需要架構的變革。三個標準進行評估：一個是節約成本，同樣收益下。一個是提高研發效率，一個是滿足業務的發展。

　　

業務架構變革的痛點

　　1、影響廣，基礎設施架構變動，相當于核心系統的變革，必然對核心之上的業務產生影響。2、周期非常長，影響到外圍的變化，同時整個周期下新的業務不能中斷，老的系統需要維護，兩個系統并行的情況下，運營難度可想而知，而且成本非常大。3、新老系統的切換，之前業務小的話可以停機維護，在線的切換好一些。對于第三方支付來說影響更大，7*24，只能做在線切換，系統的切換一定是在線，而且是無縫的。

　　關于系統切換有一個形象比喻：高速公路上換輪胎。某銀行高管也曾經表示：不換核心等死，換了核心找死。架構的變革不是輕易就能變的。

系統切換的難點：

　　一個是平滑過渡，新老系統之間的兼容性一開始設計的時候就要考慮，保證業務處理的連續性，也要保證異常事件可退回。

　　二是資損控制，資金核算，冪等控制，數據的一致性。需要臨時的整合的數據一致性控制。一旦動到資金，要對核算的口徑保證一致。

　　舉例：央行業務架構變革，一代支付系統向二代系統變革。

　　

十年換一個核心，系統切換周期是五年。商業銀行從1999到2005年，做數據的大集中，從各個縣集中到省，再集中到數據中心。伴隨著銀行的核心，2009年已經不適用了，2009-2015銀行都在做核心系統的更新換代。

　　首先要有很強的變革目標：接入方式、清算方式等調整，之前是多點接入改成一點接入。

　　變革的特點：

　　最終，從架構看，從分散式的整合成二大支付系統，從三級管理到集中管理。

　　京東支付的架構實踐

　　當時為了收單業務，后來老的業務加入新的業務，做了打補丁的架構，彌補業務的需求，無法根本解決互聯網金融發展的業務需求。從2013-2014年開始了新的業務架構設計，把老的業務拆分和封裝，形成了新的業務架構。

　　業務的變革主要是針對核心的，涉及到上層應用的遷移，這是京東支付兩年內要完成的任務。

　　新平臺的架構目標

　　新支付平臺業務架構將各個產品線的公共交易、支付、財務等基礎服務抽象沉淀至基礎支付平臺，積累賬戶、會員、信用等企業核心數據，形成穩中靈變的總體業務架構思路，適應未來業務的發展需要。

　　目標1、基礎服務抽象與封裝、復用公共業務服務，逐步建立會員、賬務、會計、交易統一體系，抽象和封裝公共處理邏并下沉形成統一的基礎支付平臺，降低業務產品的復雜度及重復研發成本。

　　目標2、核心系統穩定性需求、解決既快又穩矛盾，基礎支付平臺做到安全、穩定、可擴展，為上層業務的快速發展與創新提供平臺支撐，從架構層面解決互聯網金融業務的“快”和支付行業的“穩”之間的矛盾。

　　目標3、提供完整的數據視圖、沉淀企業核心數據，沉淀企業核心數據，隨著業務數據不斷沉淀積累，這些數據是企業持續發展的源動力，同時也為用戶和業務提供大數據支撐。

　　收單業務，從最早的網管收到到快捷支付收單，整個業務的模式相對簡單，新平臺做收單交易的切換。

　　先切換賬務核心系統還是切換交易、業務系統?老的業務系統年久失修，很多系統不能動，無法做大的改造，最后決定不再原來系統上升級，而是從新做交易、業務、賬務的核心。第一個階段先切換業務和交易，保證賬務不受影響，切換的過程經歷了灰度切換，然后分業務進行切換，遇到問題回滾修復之后再切換。整整經歷了半年時間完成收單業務切換。

　　第二，會員交易切換，包括個人和企業、移動端的交易。新平臺要創建的支付產品，各個門戶要串接，業務要逐個切換。資金要成長，賬務系統承接會員交易的主要任務。對于結算人員還是看到老的賬務系統，交易和應用切到新平臺。

　　第三，賬務系統的切換。開始存在老的賬務在老的系統，比如退款交易還是在老系統中，數據沒有清零時，老系統想新系統同步，財務人員看到新系統，資金的核算、賬務的核算等。保證新系統的業務發生額是完整的，在這個前提下做賬務的清零。收支流水的一致性，逐步的驗證，最終實現了遷移。對于新平臺是完整的，收單、交易、支付、渠道、賬務處理等等，形成了一個閉環。整個過程沒有太大的震動，一步步切換，降低了風險。

　　系統切換后的成果

　　1、業務體系：統一客戶賬戶體系、支持業務流程的再造、核心平臺穩定可靠、快速響應業務需求、完善資金核算體系、提供完整數據視圖;

　　2、系統穩定性：有效提升支付交易成功率、支持日峰值交易千萬級以上、支持十億級會員賬戶處理、服務可用率達到 99.99%、核心業務系統0停機維護。

　　總結

　　架構變革的誤區：1、架構變更就是技術系統升級， 基礎架構是公司核心競爭力的重要組成，不僅是技術升級，更是業務流程變革；2、重新造輪子，忽略繼承發展，誤認為架構變革就是重新建全新的系統，忽略外部接口、歷史數據的繼承。3、忽視兼容性，無法平穩切換，影響業務的連續性和資金的安全性，造成業務中斷和資金損失。

　　架構變革的幾點建議：1、持續架構治理，不建議頻繁架構變革；2、一旦確定變革，盡早分階段規劃實施；3、不僅解決現有問題，需前瞻性放眼未來；4、關注系統切換過渡，保證業務連續性；5、沒有最好的架構，只有最合適的架構。

　　業務變革和IT的關系，傳統的銀行，業務部門和技術部門是兩個大部門，之間的交互靠工單報送需求，互聯網要求響應速度快，技術團隊需要有業務架構的角色，把技術和業務進行融合。

　　對于技術團隊，資源是稀缺的，需要合理的分解，分階段是為了降低成本，一旦出現問題降低代價。資源充足的情況下，階段可以重疊，同步進行，迭代式的發布。一個業務一個業務的切換，否則資源的投入非常大。分階段按業務劃分，過渡期的時間要盡量縮短。

作者介紹：阮森靈擁有15年金融行業支付清算業務架構經驗，獲得清華大學碩士學位，曾先后供職于人民銀行、支付寶、中信銀行，專注于互聯網+金融業務架構和規劃。擔任京東金融支付首席架構師，承擔新支付平臺業務架構規劃設計。

出處：http://www.wtoutiao.com/p/U42r4R.html

總結

以上是生活随笔為你收集整理的京东支付首席架构师“泄密”京东支付系统架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。