【靠分散架構實現每秒20萬筆交易】中國支付龍頭142億次海量紅包派送關鍵大剖析

從創立後，每逢正月初八，過完年假的第一個開工日，騰訊高層總會站在廣東總部門口派發紅包，這個每年慣例，到了騰訊員工數千人時，還是如此，光是包紅包，秘書們就包到手軟。

為此，騰訊旗下負責支付業務的財付通，乾脆開發一套電子紅包系統，先在騰訊內部使用，發現效果不錯。2014年除夕時，更結合社交支付，推出微信紅包服務，一上線就火紅，第一年就收發了2千萬次紅包，今年的除夕夜更是創下歷史新高，春節期間一共累計達到142億次紅包的收發量。

9億多用戶的微信支付和8億多用戶的QQ錢包，是中國4大入口網站的騰訊旗下最知名的支付工具，也是驅動騰訊的兩架馬車。先前騰訊揭露了2017年春節微信支付發送紅包的數據，收發總量是驚人的142億次。而且，光是在除夕夜跨初一的凌晨，瞬間交易量就達到每秒20.8萬筆。跟紅包服務初次上線的2014年春節時期相比之下，當時利用微信發送紅包的總量只有2,000萬次，短短3年間，紅包收發總量整整翻了700倍！

電子紅包發送的玩法很多，不只是1對1的送紅包，還可以分搶，例如有人發出100元紅包到一個群組，能設定最先點擊的5個人，每人都能分道20元。而且這不是先記帳再事後撥款，而是搶到後立即入帳，可以用來發紅包給別人的即時金流撥款。

對支付系統更大的挑戰是「擴大效應，而且大約是1比5的倍率。」騰訊支付基礎平臺與金融應用線（FiT）平臺研發部技術營運總監程偉解釋，平均是1筆交易，參與的帳號數是5倍。這意味著，每秒完成20.8萬筆交易的同時，在微信支付和QQ錢包背後的支付平臺FiT，得每秒處理100萬個帳戶的付款、扣款處理。程偉日前來臺分享騰訊支付架構設計經驗時，透露了這個令人難以想像的爆量難題。

3年內從千萬筆膨脹到百億筆的爆炸性成長

程偉表示，2005年成立的財付通，在2015年升級為FiT，並且可大致將其發展的歷程分成3個階段。

2005年至2008年為初創時期，團隊規模還很小，在當時的支付性能約是最高每秒數百筆；2009至2012年則是快速發展期，技術或業務方面都是並駕齊驅的在成長，這是這時候程偉加入當時仍稱作財付通的FiT。他透露，這段期間內，騰訊推出了「QQ農場」的手機遊戲。當時在中國大陸是一款很熱門的遊戲，他們也順勢在QQ農場推出了「充話費送化肥」的活動，吸引更多人加入，將騰訊推向了高速成長的時期。

「在當時，全國移動支付的應用量，不會有上百、上千筆，更不可能是上萬人同時在做支付的事情。」程偉更說，QQ農場火熱時期，每秒30筆交易對系統來說已經是很高的負荷量了。也是那時候開始，騰訊開始從集中式的架構轉型為分散式架構，應付逐漸升高的支付需求。

2013年微信支付上線，成為騰訊蓬勃起飛的關鍵分水嶺。微信支付推出至今，每年的支付交易量呈倍數成長。以紅包發送量最高的春節期間來看，2014年紅包發送量2,000萬次；2015年直接翻5倍，來到10.1億次；2016年又成長了8倍，總量來到80.8億次；最後一次是2017年的142億次。

「技術層面來看，非常有挑戰性。」爆炸性的支付量成長，加上涉及金流、即時地交易，程偉指出，系統的性能、安全、穩定，是騰訊支付的三個關鍵。

系統必須可以應付瞬間的高流量，而且當用戶對支付服務的依賴性越來越高時，穩定性的需求就越來越高。

「系統的穩定性不能出現任何地抖動。」他舉例，去超商買東西，用戶排隊結帳，結果系統支付不了；或是，搭計程車，系統從用戶端扣款了，但是卻沒有發送通知給司機，雙方就會因為支付而陷入膠著。

面對即時性要求極高的支付場景，超過10億用戶的消費權益都掌握在騰訊支付手中，因此他們必須具備快速應變的處理能力，否則失去的不僅是用戶的信任，更是企業的社會價值、國際商譽。

更甚者，騰訊支付也不僅有社交性的支付交易，商業支付也在他們支援的範疇中，更凸顯出金融交易安全的嚴肅性。他指出，商業支付跟發紅包雖然都是支付交易，但兩者的維護等級與影響是完全不同層級的事，程偉表示，企業付款有可能單筆交易金額有可能動輒上億元。系統出錯，可能會導致企業用戶的支票無法兌現，影響很大。

對支付平臺而言，各種快速擴充縮編容量的能力、提高穩定性的能力、可以因應各種金融技術或新興場景的業務與技術能力等，這類確保穩定、安全和連續性的種種技術或能力，「都要在用戶按下Pay鍵時，像汽車潤滑油一樣，充斥到每一個零件上，讓高度複雜的支付系統，可以提供非常便捷的體驗。」他說。

紓緩騰訊支付的高速公路：分散式架構、多SET化

騰訊支付早期採取單一機房單機運作策略，就是在一臺大型伺服器設備來承載所有業務，包含用戶、訂單、商戶、交易單、充值單、提現單等都集中到單機上。不過，一旦用戶量需求增加，就無法擴充容量，毫無彈性可言。

等到QQ農場崛起，甚至是紅包發送服務的爆紅後，騰訊支付需要開始培養「快速擴縮容」的能力，程偉解釋，要有能力在一個月內從1萬臺擴充到20萬臺的擴充能耐，反之亦然。此外，應用場景也越來越多元，基金、證券、保險等，都是由FiT作為系統的支撐者。

因此，騰訊從2010年起，逐步轉型到分散式架構。可以單機房內無限擴容，把原本單機承擔的服務水平拆分到多臺機器上，也讓服務疊加可以相對容易。「當時從每秒幾十筆的能力，提升到上百、上千的每秒交易。」程偉說。

騰訊為了撐起超大流量交易，在支付平臺架構上分成四層，除了與用戶端AP或手機App串接的支付Gateway層外，採無狀態服務設計，其上就是訂單系統層，這屬於業務邏輯層，包括了用戶註冊、卡號、姓名身分證等資訊都在這一層進行驗證。或像是交易限額這類業務邏輯，也在這訂單系統層控管。最後一塊則可說是核心層，分為兩個部分：帳戶系統，以及串接全中國260多家銀行的銀行界接系統。

不僅如此，騰訊還有一套自己的解決思路：SET化。每一層系統，都會進行多SET化的部署，將一套系統分散部署到不同的SET實體群組上。SET是一套標準化的實體伺服器群組的作法，不是一種電腦叢集的概念。一個SET就是建立一個可以用來滿足執行一套應用系統所需的全部伺服器的標準化群組。

實際部署時，就按SET群組的數量來建置，如支付平臺，負責對外串連「支付Gateway」CGI介面層，就有不同用途SET群組，例如微信GGI/CAE介面的SET1和SET2（兩套），或是手機版QQ錢包的CGI/CAE介面也有2套SET。不同用戶的流量，就分散到不同的SET實體群組來處理。

確保服務的連續性，引入第三方伺服器做災難備援

即便已經做了各種防範措施，但仍會有不可抗的因素，能造成機房災難，例如大規模停電等。

因此，程偉表示，為了確保服務的持續可用性，光是A機房與B機房間彼此的災備還不夠。他們引入了第三方的仲裁伺服器（Third Server）。簡單來說，A機房與B機房是同時運作，各自承載了50%的用戶數，彼此間還有半同步的複製機制。而A、B兩邊機房的交易都會優先在C機房記上一筆。在C機房內則會有一份所有交易Log的壓縮檔。

當A機房出現問題時，B機房可以隨時備援，若是一旦連B機房備援都救不了火時，就可以啟動C機房所保存的數據。而且當A出現問題，B救援時，也可以從C進行查核，確認斷點資訊的完整性。

程偉特別指出，傳統銀行發生問題時，會瞬間凍結所有服務。但是他們利用這樣的方式，可以把影響的用戶數降到非常低。「A出現問題時，B是不受影響的，而且重新啟用A機房系統時，還大約有15分鐘的決策過程。」程偉解釋，為了將風險降到最低，系統不會馬上就恢復A機房的運作，而是在最短的時間內（平均15分鐘）先進行平行作業，並且再確認從對帳、會計、結算作業都能順利執行無誤，才會重新啟用A機房的系統。而這一連串作業都全面自動化，任何機器發生問題，系統也都能透過自動化維運機制自行修復或回復。

程偉強調，巨量的數據處理需要強大的維運平臺，而一套越好的維運平臺，一定會越來越邁向自動化、智能化，以及可視化的發展樣貌，一要減少人為介入，其次是能自動辨識所有問題也能自動處理，最後一項可視化就是要做到，讓一切部署、業務流程、指示與資源都透過視覺化的方式一覽無遺。