和過去10年一樣,2019年天貓雙11又創(chuàng)造了一個(gè)全新的紀(jì)錄。
這個(gè)數(shù)字背后,是數(shù)代支付寶工程師們殫精竭慮、不斷突破技術(shù)難關(guān)。
對(duì)于技術(shù)人員來說,維持雙11全天24小時(shí)穩(wěn)定流暢固然不易,但最為考驗(yàn)的時(shí)刻當(dāng)屬零點(diǎn)剛過,人們操起手機(jī),刷新早已存好的購物車,點(diǎn)擊支付的那一刻!
11年,零點(diǎn)越來越平滑的雙11購物背后,支付寶有過哪些不為人知的技術(shù)探索,今天也特別放送。
一、從外部瓶頸說起
事情從一開始就顯得不是很順利。
2011年的雙十一,在高峰時(shí)期少數(shù)用戶無法付款,經(jīng)過調(diào)查發(fā)現(xiàn),這是因?yàn)樯贁?shù)銀行的網(wǎng)銀系統(tǒng)在壓力下出現(xiàn)故障。早年的支付寶交易,用戶點(diǎn)擊支付后需要從支付寶和銀行的接口去付款,而早年這個(gè)接口的性能很差,每秒只能支持幾十到上百筆交易,穩(wěn)定性也比較差,一旦流量上來,容易發(fā)生故障。
如果不解決這個(gè)問題,今后的每次大促都會(huì)出現(xiàn)無法付款的情況,極大影響用戶體驗(yàn)。但是,這個(gè)問題單靠技術(shù)是很難解決的,銀行對(duì)網(wǎng)銀系統(tǒng)的演進(jìn)有自己的規(guī)劃,支付寶無法去干涉它們的系統(tǒng)。
不過,聰明的運(yùn)營人員想出了一個(gè)變通的辦法。在2012年的雙十一,支付寶通過活動(dòng)吸引用戶先充值后付款,讓用戶先將錢充值到支付寶余額上,到雙十一直接從余額里面扣款就行,這樣,外部的瓶頸就被轉(zhuǎn)換到內(nèi)部了。這樣做效果非常顯著,付款失敗的問題大為緩解。
然而,外部的瓶頸始終存在,面對(duì)每年翻倍提升的流量峰值,支付對(duì)外部的依賴始終是一個(gè)隱患,不知道什么時(shí)候就會(huì)爆發(fā)。
解決這個(gè)問題最好的辦法,就是不通過網(wǎng)銀,讓資金在內(nèi)部的系統(tǒng)中流轉(zhuǎn),先充值后付款就是這個(gè)原理。那么,有沒有一個(gè)方法,吸引用戶把錢放到支付寶里呢?2013年6月,支付寶推出余額寶,歪打正著的解決了這個(gè)問題,到2014年底余額寶就吸引了1.85億用戶,在13年和14年的雙十一,交易峰值也分別實(shí)現(xiàn)了4倍和3倍的增長。
2018年5月,支付寶接入網(wǎng)聯(lián)清算平臺(tái),同時(shí)在這些年里,銀行也在大力提升自己的系統(tǒng)能力,中大型銀行的網(wǎng)銀系統(tǒng)支持的交易筆數(shù)已經(jīng)達(dá)到2萬筆/秒以上,外部問題基本得以解決。
解決了外部瓶頸之后,支付峰值的數(shù)字能有多高,就看支付寶的系統(tǒng)如何化解一年比一年更兇猛的流量洪峰。
二、容量規(guī)劃:三軍未動(dòng)糧草先行
事實(shí)上,支持交易筆數(shù)峰值面臨的首要問題,并不是設(shè)計(jì)一個(gè)完美支持橫向擴(kuò)展的架構(gòu),而是對(duì)可能的流量峰值進(jìn)行準(zhǔn)確估計(jì),然后安排對(duì)應(yīng)的機(jī)器和資源。如果不做估計(jì),可能發(fā)生兩種情況:預(yù)備資源過多,架構(gòu)過度設(shè)計(jì),造成資源浪費(fèi);預(yù)備資源過少,無法完美支持大促,造成部分支付排隊(duì)或失敗。每年雙十一備戰(zhàn),負(fù)責(zé)大促的決策團(tuán)隊(duì)會(huì)根據(jù)歷史數(shù)據(jù)、大促目標(biāo)來擬定一個(gè)交易數(shù)值,然后將這個(gè)數(shù)值拆解為各個(gè)系統(tǒng)所需要應(yīng)對(duì)的流量,從而進(jìn)行系統(tǒng)容量規(guī)劃。
雙11大促的場(chǎng)景指標(biāo)一般包括交易創(chuàng)建數(shù)、收銀臺(tái)展現(xiàn)數(shù)、交易支付數(shù)?？偟闹Ц赌繕?biāo)數(shù)已經(jīng)有了,運(yùn)維人員根據(jù)總tps/單機(jī)tps的算法計(jì)算出應(yīng)用在每個(gè)指標(biāo)下的單機(jī)能力,然后,參考?xì)v史活動(dòng)數(shù)據(jù),可以計(jì)算應(yīng)用在不同場(chǎng)景鏈路下的單機(jī)tps。
但是,這種做法人工干預(yù)較多,對(duì)于各個(gè)應(yīng)用的容量預(yù)估的粒度比較粗,后來,支付寶又建設(shè)了容量分析平臺(tái),可以進(jìn)行自動(dòng)化的細(xì)粒度的容量分析。
它的原理是,如果我們把一個(gè)鏈路理解為一個(gè)業(yè)務(wù),鏈路根節(jié)點(diǎn)可以理解為業(yè)務(wù)的源頭流量請(qǐng)求,每個(gè)鏈路上的節(jié)點(diǎn)(這里的節(jié)點(diǎn)包括應(yīng)用、DB、tair等)都能計(jì)算出該節(jié)點(diǎn)調(diào)用次數(shù)相對(duì)于根節(jié)點(diǎn)流量的系數(shù)。因此,當(dāng)業(yè)務(wù)源頭的QPS確定時(shí),就可以基于鏈路數(shù)據(jù),計(jì)算出每個(gè)節(jié)點(diǎn)的QPS。
2018年的雙十一,支付寶還建設(shè)了智能容量模型,不但可以根據(jù)業(yè)務(wù)流量進(jìn)行容量預(yù)估,還可以智能的產(chǎn)出應(yīng)用資源部署方案,使得在該方案下,部署單元在承載給定業(yè)務(wù)流量時(shí)的容量水平處于目標(biāo)范圍。
智能容量模型是支付寶對(duì)AIOps探索的一部分,也是對(duì)數(shù)據(jù)技術(shù)和人工智能在系統(tǒng)中落地實(shí)踐的一部分,這方面也是當(dāng)前支付寶技術(shù)探索的方向之一。
三、LDC與彈性架構(gòu):大促最強(qiáng)武器
對(duì)流量進(jìn)行預(yù)估并進(jìn)行合理的容量規(guī)劃之后,接下來就看我們的架構(gòu)是否能支持流量峰值了。
首先需要說明的是,流量高峰涉及到一個(gè)系統(tǒng)的方方面面,支付寶的整個(gè)系統(tǒng)極其復(fù)雜,而且面向toC和toB都推出了很多業(yè)務(wù),即使只關(guān)注核心支付系統(tǒng),也包括支付清算、賬務(wù)、核算等子系統(tǒng)。
系統(tǒng)部分組件由通用型的中間件提供支撐,如負(fù)載均衡中間件LVS/Spanner、阿里巴巴的分布式緩存中間件Tair等,其它則由支付寶自研的SOFAStack金融級(jí)分布式中間件負(fù)責(zé)。
支付峰值的本質(zhì)是一個(gè)高并發(fā)問題,互聯(lián)網(wǎng)公司解決高并發(fā)的思路是橫向擴(kuò)展水平拆分,用分布式的方式來應(yīng)對(duì)流量洪峰,支付寶也不例外。支付寶很早完成了服務(wù)化架構(gòu)和核心數(shù)據(jù)庫的水平拆分,成功應(yīng)對(duì)了前幾年的雙十一。
分布式系統(tǒng)示意圖
這個(gè)架構(gòu)的問題是,所有子應(yīng)用都需要訪問所有數(shù)據(jù)庫分庫,但是數(shù)據(jù)庫連接是有限的。當(dāng)時(shí)主流的商業(yè)數(shù)據(jù)庫,連接都不是共享的,就是說一個(gè)事務(wù)必須獨(dú)占一個(gè)連接。而連接卻又是數(shù)據(jù)庫非常寶貴的資源,不能無限增加。當(dāng)時(shí)的支付寶,面臨的問題是不能再對(duì)應(yīng)用集群擴(kuò)容,因?yàn)槊考右慌_(tái)機(jī)器,就需要在每個(gè)數(shù)據(jù)分庫上新增若干連接,而此時(shí)幾個(gè)核心數(shù)據(jù)庫的連接數(shù)已經(jīng)到達(dá)上限。應(yīng)用不能擴(kuò)容,意味著支付寶系統(tǒng)的容量定格了,不能再有任何業(yè)務(wù)量增長,別說大促,很可能再過一段時(shí)間連日常業(yè)務(wù)也支撐不了了。
這個(gè)問題迫在眉睫,從2013年開始,支付寶開始新一輪的架構(gòu)改造,實(shí)施單元化的LDC邏輯數(shù)據(jù)中心,雙十一的流量峰值,終于還是成功的扛下來了。
一個(gè)單元,是一個(gè)五臟俱全的縮小版整站,它是全能的,因?yàn)椴渴鹆怂袘?yīng)用;但它不是全量的,因?yàn)橹荒懿僮饕徊糠謹(jǐn)?shù)據(jù)。這樣,只要將數(shù)據(jù)分區(qū)增加單元,就可以提升整個(gè)系統(tǒng)的處理性能上限。
單元化示意圖
但是,并不是所有的數(shù)據(jù)都能拆分,比如部分底層數(shù)據(jù)是全局?jǐn)?shù)據(jù),所有單元的應(yīng)用都需要訪問。并且,支付寶經(jīng)過近十年建設(shè),有些架構(gòu)也并不能很好的拆分成單元。在這個(gè)前提下,支付寶設(shè)計(jì)了CRG的單元化架構(gòu),既能利用單元化的優(yōu)點(diǎn),也能支持現(xiàn)有的架構(gòu)。
RZone(Region Zone):最符合理論上單元定義的zone,每個(gè)RZone都是自包含的,擁有自己的數(shù)據(jù),能完成所有業(yè)務(wù)。GZone(Global Zone):部署了不可拆分的數(shù)據(jù)和服務(wù),這些數(shù)據(jù)或服務(wù)可能會(huì)被RZone依賴。GZone在全局只有一組,數(shù)據(jù)僅有一份。CZone(City Zone):同樣部署了不可拆分的數(shù)據(jù)和服務(wù),也會(huì)被RZone依賴。跟GZone不同的是,CZone中的數(shù)據(jù)或服務(wù)會(huì)被RZone頻繁訪問,每一筆業(yè)務(wù)至少會(huì)訪問一次;而GZone被RZone訪問的頻率則低的多。CZone是為了解決異地延遲問題而特別設(shè)計(jì)的。
CRG架構(gòu)示意圖
關(guān)于支付寶單元化和LDC的更多信息可查看這篇文章。
實(shí)施了LDC之后,系統(tǒng)容量實(shí)現(xiàn)水平擴(kuò)展,順利支持了2013年及之后的雙十一流量洪峰,并且系統(tǒng)不再受到單點(diǎn)故障限制,經(jīng)過完善之后還做到異地多活,最終形成了三地五中心的金融級(jí)架構(gòu)。
理論上,只要無限擴(kuò)展LDC的計(jì)算資源,就可以應(yīng)對(duì)無限大的流量,但是,這樣做的話,大部分機(jī)器只有在大促時(shí)才能派上用場(chǎng),平時(shí)就是閑置的,造成資源浪費(fèi)。最好能做到平時(shí)用少量資源支持常規(guī)流量,大促時(shí)經(jīng)過容量規(guī)劃,提前啟用部分空閑或第三方資源應(yīng)對(duì)高峰流量,這就是彈性架構(gòu)的由來。
2016年,支付寶開始為大促進(jìn)行彈性架構(gòu)的改造。彈性架構(gòu)基于業(yè)務(wù)鏈路,因?yàn)榇蟠贂r(shí)只有部分鏈路的流量激增,因此只需要針對(duì)大促關(guān)鍵鏈路進(jìn)行彈性擴(kuò)容即可。
彈性架構(gòu)涉及到多個(gè)層面的改造,首先是彈性機(jī)房和彈性單元,需要在LDC邏輯機(jī)房架構(gòu)上按照業(yè)務(wù)緯度繼續(xù)切片,保證單片業(yè)務(wù)可以獨(dú)立邏輯單元部署,并保持與非彈性單元的聯(lián)通性,并且可隨時(shí)彈出和回收。
其次是彈性存儲(chǔ),包括流水型數(shù)據(jù)和狀態(tài)型數(shù)據(jù)的彈性。流水型數(shù)據(jù)包括支付訂單,為了支持這些數(shù)據(jù)的彈性,創(chuàng)建了彈性位+彈性UID,然后路由根據(jù)彈性UID將訂單分配至彈性單元中進(jìn)行處理。狀態(tài)型存儲(chǔ)比如用戶的賬戶余額,進(jìn)行整體彈出,具體實(shí)現(xiàn)方式是通過DB層的主備切換,將主庫壓力分流至備庫。
然后是中間件層面的改造,包括路由、RPC、消息隊(duì)列、流量管理等等。應(yīng)用層面也需要進(jìn)行相應(yīng)的改造,因?yàn)槊總€(gè)彈性單元需要做到獨(dú)立邏輯單元部署,因此需要從服務(wù)到數(shù)據(jù)進(jìn)行梳理并剝離,同時(shí)添加彈性id等彈性邏輯處理。
除了這些之外,還需要對(duì)運(yùn)維平臺(tái)、壓測(cè)工具進(jìn)行相應(yīng)的改造。
2016年彈性架構(gòu)上線后,成功支撐了當(dāng)年雙十一,滿足大促要求和預(yù)定目標(biāo),節(jié)省了機(jī)房物理資源,成為應(yīng)對(duì)大促類流量洪峰最有力的武器。
彈性架構(gòu)里的彈性單元都是新增的集群,但其實(shí)還可以進(jìn)一步的提高資源利用率。方法就是離在線混部技術(shù),因?yàn)橛行┘菏怯米麟x線的大數(shù)據(jù)分析,但并不是全天24小時(shí)都滿負(fù)荷工作,當(dāng)沒有任務(wù)時(shí),集群資源利用率極低。如果將離線的應(yīng)用和在線的業(yè)務(wù)應(yīng)用部署在一起,讓大促高峰時(shí)段能夠利用這些資源,就可以減少大促期間采購的資源,進(jìn)一步節(jié)省成本?；觳考夹g(shù)需要運(yùn)維的分時(shí)調(diào)度配合,在不同的時(shí)段將資源分配給不同的應(yīng)用。
從2017年起,支付寶開始嘗試離在線混部和分時(shí)調(diào)度技術(shù),在大促時(shí)利用離線技術(shù)所使用的集群資源,大大提升了集群資源利用率。
四、百萬支付:解決數(shù)據(jù)庫擴(kuò)展瓶頸
2016年的雙十一,交易筆數(shù)峰值達(dá)到12萬筆每秒,這場(chǎng)高并發(fā)之戰(zhàn)仍在繼續(xù)。前面提到了很多應(yīng)對(duì)大促的技術(shù)手段,但其實(shí)漏掉了一個(gè)最重要的部分,那就是數(shù)據(jù)庫。在流量洪峰時(shí),受到壓力最大的就是數(shù)據(jù)庫。這是因?yàn)?在前臺(tái)我們看到是一個(gè)成功交易,但拆解之后,一個(gè)交易可能平均要產(chǎn)生數(shù)百甚至上千個(gè)請(qǐng)求,數(shù)據(jù)庫的壓力要遠(yuǎn)遠(yuǎn)大于我們所能看到的數(shù)字。
從最開始,數(shù)據(jù)庫就一直是支付寶系統(tǒng)的瓶頸之一,在之前,其實(shí)已經(jīng)配合架構(gòu)改造對(duì)數(shù)據(jù)庫做了諸多升級(jí),除了上面提過的彈性化的改造,還包括:
1. 分庫分表,將原有的交易賬戶庫分離為交易庫和賬戶庫,并通過分布式事務(wù)解決數(shù)據(jù)一致性問題。
2. 數(shù)據(jù)庫水平拆分,將所有的用戶按照1%粒度分為100份,配合單元化的邏輯隔離。
3. 數(shù)據(jù)庫讀寫分離、多點(diǎn)寫入、數(shù)據(jù)復(fù)制,通過這些方式,可以大大提升性能。
早年支付寶采用的商業(yè)數(shù)據(jù)庫能進(jìn)行的改進(jìn)是有極限的,為了成本考慮,不可能為了一年僅僅幾天的大促活動(dòng)去采購額外的數(shù)據(jù)庫系統(tǒng)和設(shè)備。
早在2014年的雙十一,支付寶自研數(shù)據(jù)庫OceanBase就開始承擔(dān)10%雙十一核心交易流量,隨后一步步承擔(dān)交易、支付、賬務(wù)等核心系統(tǒng)的100%流量,經(jīng)受住了極端條件下的嚴(yán)苛考驗(yàn)。
OceanBase從第一天開始,就計(jì)劃成為一個(gè)分布式的關(guān)系數(shù)據(jù)庫,也就是天然支持大規(guī)模和高并發(fā)的場(chǎng)景。但是,支付寶本身的用戶體量太大,再加上雙十一所面臨的的系統(tǒng)壓力太大,到2017年雙十一的時(shí)候,即使采用了額外的彈性庫,數(shù)據(jù)庫CPU壓力也接近上限,成為繼續(xù)擴(kuò)容的瓶頸所在。
2018年的雙十一,支付寶在內(nèi)部提出了百萬支付架構(gòu),意思是這套架構(gòu)可以支持百萬筆/秒量級(jí)的系統(tǒng)壓力。而這套架構(gòu)的核心,就是OceanBase 2.0分布式分區(qū)方案。
過去架構(gòu)下的DB擴(kuò)展,由于DB單機(jī)存在極限,且一個(gè)UID最多對(duì)應(yīng)一臺(tái)機(jī)器,所以這里的擴(kuò)展能力是通過DB新增集群,應(yīng)用加數(shù)據(jù)源來實(shí)現(xiàn)的。這就會(huì)帶來一系列的問題,比如應(yīng)用的內(nèi)存增長、多數(shù)據(jù)源導(dǎo)致彈出彈回費(fèi)時(shí)費(fèi)力、多個(gè)DB集群的日常維護(hù)成本高等。為解決這個(gè)問題,考慮讓DB也能像應(yīng)用一樣可以動(dòng)態(tài)擴(kuò)容,且必須突破一個(gè)UID最多一臺(tái)機(jī)器的限制,從而能達(dá)到應(yīng)用和DB同步擴(kuò)容,不用增加新DB集群就能達(dá)到新的容量支撐能力。
由此,基于DB的分區(qū)功能,將DB的擴(kuò)展性大大增強(qiáng),避免了必須增加集群來擴(kuò)容的尷尬。同時(shí)對(duì)應(yīng)用進(jìn)行了相關(guān)的升級(jí)改造,如全站流水號(hào)架構(gòu)的升級(jí),系列中間件的改造,以及任務(wù)撈取場(chǎng)景的改造等。
OceanBase分區(qū)架構(gòu)
傳統(tǒng)數(shù)據(jù)庫彈性架構(gòu),將數(shù)據(jù)進(jìn)行物理拆分到不同機(jī)器,業(yè)務(wù)在數(shù)據(jù)訪問/研發(fā)/后期維護(hù)及數(shù)據(jù)配套設(shè)施上非常繁瑣;同時(shí)拆分后資源很難快速回收,且數(shù)據(jù)拆分及聚合無法實(shí)現(xiàn)業(yè)務(wù)無損。相比于傳統(tǒng)數(shù)據(jù)庫的彈性架構(gòu),OceanBase 2.0架構(gòu)完全不侵入業(yè)務(wù),內(nèi)部通過分區(qū)實(shí)現(xiàn)數(shù)據(jù)分片的自組織及負(fù)載均衡,通過生成列及分區(qū)規(guī)則實(shí)現(xiàn)自動(dòng)路由,通過分區(qū)聚合(partition_group)消除分布式事務(wù)性能開銷以提升性能,從而實(shí)現(xiàn)無損線性伸縮。另數(shù)據(jù)分片間share_nothing的架構(gòu),實(shí)現(xiàn)分片故障隔離及單點(diǎn)故障消除的高可用架構(gòu)。
2018年雙十一,OceanBase 2.0成功上線,并支持了交易和支付的全部流量。并且,基于OceanBase2.0分區(qū)方案的這套架構(gòu)可以輕松擴(kuò)展到支持百萬級(jí)交易,關(guān)于應(yīng)對(duì)流量洪峰的戰(zhàn)役暫時(shí)告一段落。
五、技術(shù)保障:大促技術(shù)標(biāo)準(zhǔn)化
雙十一是新技術(shù)的演練場(chǎng),那么怎么確定這些技術(shù)能有效支撐流量高峰呢?特別在支付寶,涉及到人們的資金安全,一旦發(fā)生問題后果極其嚴(yán)重,更是要慎之又慎。
2014年,支付寶上線了全鏈路壓測(cè),成為系統(tǒng)化技術(shù)驗(yàn)證的神器;從2017年起,支付寶開始打造自動(dòng)化和智能化的技術(shù)風(fēng)險(xiǎn)防控體系;2018年的雙十一,大促中控上線,大促相關(guān)的技術(shù)開始走向標(biāo)準(zhǔn)化。
大促中控示意圖
大促中控也就是一站式的大促保障解決方案,它的目的,就是將之前大促的經(jīng)驗(yàn)沉淀下來,形成套路和規(guī)范,最終向無人值守方向發(fā)展,搞大促不需要技術(shù)人再熬夜了。
有了大促中控,可以進(jìn)行自動(dòng)化的無損壓測(cè),線上壓測(cè)能得到想要的結(jié)果的同時(shí),不影響正在進(jìn)行的業(yè)務(wù)。它的核心技術(shù)能力是對(duì)環(huán)境、機(jī)器、線程的隔離,以及在壓測(cè)異常時(shí)的智能熔斷。
壓測(cè)并不是萬能的,有些問題可能在壓測(cè)中難以暴露,從2018年起,支付寶還展開了紅藍(lán)攻防演練,為了在大促峰值出現(xiàn)異常時(shí),檢查應(yīng)急策略、組織保障、響應(yīng)速度是否到位,以及驗(yàn)證新技術(shù)的穩(wěn)定性是否達(dá)標(biāo)。
對(duì)于大促中的資金安全,支付寶自研了實(shí)時(shí)的資金核對(duì)系統(tǒng),實(shí)現(xiàn)峰值的資金安全實(shí)時(shí)驗(yàn)證,驗(yàn)證每一筆資金準(zhǔn)確無誤。
當(dāng)所有技術(shù)準(zhǔn)備就緒并不是就可以了,每次大促之前還有很多配置需要切換,一旦出錯(cuò)就會(huì)造成嚴(yán)重影響,因此支付寶打造了面向終態(tài)的技術(shù)風(fēng)險(xiǎn)巡檢能力,在大促前一天進(jìn)行成百上千的配置自動(dòng)化檢查,確認(rèn)所有系統(tǒng)進(jìn)入大促狀態(tài),確保萬無一失。
隨著時(shí)鐘漸漸指向零點(diǎn),大促一觸即發(fā)。
六、未來可期,我們一路同行
總結(jié)起來,雙十一流量峰值考驗(yàn)的是架構(gòu)的可伸縮性、數(shù)據(jù)庫的承載能力、運(yùn)維的強(qiáng)大調(diào)度能力,以及完善的技術(shù)保障能力。為了確保大促順利完成,需要做的技術(shù)準(zhǔn)備也遠(yuǎn)遠(yuǎn)不只文中提到的,諸如全鏈路壓測(cè)這樣的幕后功臣還有很多,由于篇幅所限,這里就不再一一介紹了。
支付寶也在持續(xù)更新著自己的技術(shù)裝備庫。今年的雙十一,支付寶也有幾項(xiàng)新能力得到實(shí)戰(zhàn)檢驗(yàn):OceanBase 2.2上線,該版本在TPC-C基準(zhǔn)測(cè)試中取得第一名,平穩(wěn)支撐了新大促;自研的Service Mesh 首次登上大促舞臺(tái),目前已經(jīng) 100% 覆蓋支付寶核心支付鏈路,是業(yè)界最大的 Service Mesh 集群。
點(diǎn)擊鏈接觀看《使命必達(dá)——OceanBase登頂TPC-C測(cè)試》https://v.qq.com/x/page/l3019boh97i.html
隨著普惠金融的落地,以及萬物互聯(lián)的發(fā)展,支付平臺(tái)面臨的流量壓力會(huì)進(jìn)一步提升?，F(xiàn)在我們看到的峰值,未來也許稀松平常;未來的峰值,也許比今天還要高幾個(gè)量級(jí)。支付峰值這場(chǎng)戰(zhàn)役仍會(huì)繼續(xù)下去,其中的技術(shù)也將不斷的更新進(jìn)化,未來雙十一的技術(shù)之戰(zhàn)將更加精彩。
