每年“雙 11”都是一場電商盛會，消費者狂歡日。今年雙 11 的意義尤為重大梢什，它已經(jīng)發(fā)展成為全世界電商和消費者都參與進來的盛宴。而對技術人員來說朝聋，雙十一無疑已經(jīng)成為一場大考嗡午，考量的角度是整體架構、基礎中間件玖翅、運維工具翼馆、人員等。
一次成功的大促準備不光是針對活動本身對系統(tǒng)和架構做的優(yōu)化措施金度，比如：流量控制应媚，緩存策略，依賴管控猜极，性能優(yōu)化……更是與長時間的技術積累和打磨分不開中姜。下面我將簡單介紹支付寶的整體架構，讓大家有個初步認識，然后會以本次在大促中大放異彩的“螞蟻花唄”為例丢胚，大致介紹一個新業(yè)務是如何從頭開始準備大促的翩瓜。
支付寶的架構設計上應該考慮到互聯(lián)網(wǎng)金融業(yè)務的特殊性，比如要求更高的業(yè)務連續(xù)性携龟，更好的高擴展性兔跌，更快速的支持新業(yè)務發(fā)展等特點。目前其架構如下：
整個平臺被分成了三個層：
運維平臺（IAAS）：主要提供基礎資源的可伸縮性峡蟋，比如網(wǎng)絡坟桅、存儲、數(shù)據(jù)庫蕊蝗、虛擬化仅乓、IDC 等，保證底層系統(tǒng)平臺的穩(wěn)定性蓬戚；
技術平臺（PAAS）：主要提供可伸縮夸楣、高可用的分布式事務處理和服務計算能力，能夠做到彈性資源的分配和訪問控制子漩，提供一套基礎的中間件運行環(huán)境豫喧，屏蔽底層資源的復雜性；
業(yè)務平臺（SAAS）：提供隨時隨地高可用的支付服務痛单，并且提供一個安全易用的開放支付應用開發(fā)平臺嘿棘。
邏輯數(shù)據(jù)中心架構
在雙十一大促當天業(yè)務量年年翻番的情況下，支付寶面臨的考驗也越來越大：系統(tǒng)的容量越來越大旭绒，服務器鸟妙、網(wǎng)絡、數(shù)據(jù)庫挥吵、機房都隨之擴展重父，這帶來了一些比較大的問題，比如系統(tǒng)規(guī)模越來越大忽匈，系統(tǒng)的復雜度越來越高房午，以前按照點的伸縮性架構無法滿足要求，需要我們有一套整體性的可伸縮方案丹允，可以按照一個單元的維度進行擴展郭厌。能夠提供支持異地伸縮的能力，提供 N+1 的災備方案雕蔽，提供整體性的故障恢復體系折柠。基于以上幾個需求批狐，我們提出了邏輯數(shù)據(jù)中心架構扇售，核心思想是把數(shù)據(jù)水平拆分的思路向上層提到接入層、終端， 從接入層開始把系統(tǒng)分成多個單元承冰，單元有幾個特性：
每個單元對外是封閉的华弓，包括系統(tǒng)間交換各類存儲的訪問;
每個單元的實時數(shù)據(jù)是獨立的，不共享困乒。而會員或配置類對延時性要求不高的數(shù)據(jù)可共享;
單元之間的通信統(tǒng)一管控寂屏，盡量走異步化消息。同步消息走單元代理方案顶燕；
下面是支付寶邏輯機房架構的概念圖：
這套架構解決了幾個關鍵問題：
由于盡量減少了跨單元交互和使用異步化凑保，使得異地部署成為可能。整個系統(tǒng)的水平可伸縮性大大提高涌攻，不再依賴同城 IDC；
可以實現(xiàn) N+1 的異地災備策略频伤，大大縮減災備成本恳谎，同時確保災備設施真實可用；
整個系統(tǒng)已無單點存在憋肖，大大提升了整體的高可用性因痛；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平臺進行快速切換岸更，有機會實現(xiàn) 100% 的持續(xù)可用率鸵膏；
該架構下業(yè)務級別的流量入口和出口形成了統(tǒng)一的可管控、可路由的控制點怎炊，整體系統(tǒng)的可管控能力得到很大提升谭企。基于該架構评肆，線上壓測债查、流量管控、灰度發(fā)布等以前難以實現(xiàn)的運維管控模式瓜挽，現(xiàn)在能夠十分輕松地實現(xiàn)盹廷。
目前新架構的同城主體框架在 2013 年已經(jīng)完成，并且順利的面對了雙十一的考驗久橙，讓整套架構的落地工作得到了很好的證明俄占。
在 2015 年完成了基于邏輯機房，異地部署的“異地多活”的架構落地淆衷「组“異地多活”架構是指，基于邏輯機房擴展能力吭敢，在不同的地域 IDC 部署邏輯機房碰凶，并且每個邏輯機房都是“活”的，真正承接線上業(yè)務，在發(fā)生故障的時候可以快速進行邏輯機房之間的快速切換欲低。
這比傳統(tǒng)的“兩地三中心”架構有更好的業(yè)務連續(xù)性保障辕宏。在“異地多活”的架構下，一個 IDC 對應的故障容災 IDC 是一個“活”的 IDC砾莱，平時就承接著正常線上業(yè)務瑞筐，保證其穩(wěn)定性和業(yè)務的正確性是一直被確保的。
以下是支付寶“異地多活”架構示意圖：
除了更好的故障應急能力之外腊瑟，基于邏輯機房我們又具備的“藍綠發(fā)布”或者說“灰度發(fā)布”的驗證能力聚假。我們把單個邏輯機房（后續(xù)簡稱 LDC）內(nèi)部又分成 A、B 兩個邏輯機房闰非，A 膘格、B 機房在功能上完全對等。日常情況下财松，調(diào)用請求按照對等概率隨機路由到 A 或 B 瘪贱。當開啟藍綠模式時，上層路由組件會調(diào)整路由計算策略辆毡，隔離 A 與 B 之間的調(diào)用菜秦， A 組內(nèi)應用只能相互訪問，而不會訪問 B 組舶掖。
然后進行藍綠發(fā)布流程大致如下：
Step1. 發(fā)布前球昨，將“藍”流量調(diào)至 0%，對“藍”的所有應用整體無序分 2 組發(fā)布眨攘。
Step2. “藍”引流 1% 觀察主慰，如無異常，逐步上調(diào)分流比例至 100%期犬。
Step3. “綠”流量為 0%河哑，對“綠”所有應用整體無序分 2 組發(fā)布。
Step4. 恢復日常運行狀態(tài)龟虎，藍璃谨、綠單元各承擔線上 50% 的業(yè)務流量。
支付寶在 2015 年雙十一當天的高峰期間處理支付峰值 8.59 萬筆 / 秒鲤妥，已經(jīng)是國際第一大系統(tǒng)支付佳吞。支付寶已經(jīng)是全球最大的 OLTP 處理者之一，對事務的敏感使支付寶的數(shù)據(jù)架構有別于其他的互聯(lián)網(wǎng)公司棉安，卻繼承了互聯(lián)網(wǎng)公司特有的巨大用戶量底扳，最主要的是支付寶對交易的成本比傳統(tǒng)金融公司更敏感，所以支付寶數(shù)據(jù)架構發(fā)展贡耽，就是一部低成本衷模、線性可伸縮鹊汛、分布式的數(shù)據(jù)架構演變史。
現(xiàn)在支付寶的數(shù)據(jù)架構已經(jīng)從集中式的小型機和高端存儲升級到了分布式 PC 服務解決方案阱冶，整體數(shù)據(jù)架構的解決方案盡量做到無廠商依賴刁憋，并且標準化。
支付寶分布式數(shù)據(jù)架構可伸縮策略主要分為三個維度：
按照業(yè)務類型進行垂直拆分
按照客戶請求進行水平拆分（也就是常說的數(shù)據(jù)的 sharding 策略）
對于讀遠遠大于寫的數(shù)據(jù)進行讀寫分離和數(shù)據(jù)復制處理
下圖是支付寶內(nèi)部交易數(shù)據(jù)的可伸縮性設計：
交易系統(tǒng)的數(shù)據(jù)主要分為三個大數(shù)據(jù)庫集群：
主交易數(shù)據(jù)庫集群木蹬，每一筆交易創(chuàng)建和狀態(tài)的修改首先在這?完成至耻，產(chǎn)生的變更再通過可靠數(shù)據(jù)復制中心復制到其他兩個數(shù)據(jù)庫集群：消費記錄數(shù)據(jù)庫集群、商戶查詢數(shù)據(jù)庫集群镊叁。該數(shù)據(jù)庫集群的數(shù)據(jù)被水平拆分成多份尘颓，為了同時保證可伸縮性和高可靠性，每一個節(jié)點都會有與之對應的備用節(jié)點和 failover 節(jié)點晦譬，在出現(xiàn)故障的時候可以在秒級內(nèi)切換到 failover 節(jié)點疤苹。
消費記錄數(shù)據(jù)庫集群，提供消費者更好的用戶體驗和需求蛔添；
商戶查詢數(shù)據(jù)庫集群痰催，提供商戶更好的用戶體驗和需求；
對于分拆出來的各個數(shù)據(jù)節(jié)點迎瞧，為了保證對上層應用系統(tǒng)的透明，我們研發(fā)一套數(shù)據(jù)中間產(chǎn)品來保證交易數(shù)據(jù)做到彈性擴容逸吵。
分布式數(shù)據(jù)架構下凶硅，在保證事務原有的 ACID（原子性、一致性扫皱、隔離性足绅、持久性）特性的基礎上，還要保證高可用和可伸縮性韩脑，挑戰(zhàn)非常大氢妈。試想你同時支付了兩筆資金，這兩筆資金的事務如果在分布式環(huán)境下相互影響段多，在其中一筆交易資金回滾的情況下首量，還會影響另外一筆是多么不能接受的情況。
根據(jù) CAP 和 BASE 原則进苍，再結合支付寶系統(tǒng)的特點加缘，我們設計了一套基于服務層面的分布式事務框架，他支持兩階段提交協(xié)議觉啊，但是做了很多的優(yōu)化拣宏，在保證事務的 ACID 原則的前提下，確保事務的最終一致性 杠人。我們叫做“柔性事物”策略勋乾。原理如下：
以下是分布式事務框架的流程圖：
實現(xiàn)：
一個完整的業(yè)務活動由一個主業(yè)務服務與若干從業(yè)務服務組成宋下。
主業(yè)務服務負責發(fā)起并完成整個業(yè)務活動。
從業(yè)務服務提供 TCC 型業(yè)務操作辑莫。
業(yè)務活動管理器控制業(yè)務活動的一致性学歧，它登記業(yè)務活動中的操作，并在活動提交時確認所有的兩階段事務的 confirm 操作摆昧，在業(yè)務活動取消時調(diào)用所有兩階段事務的 cancel 操作撩满。”
與 2PC 協(xié)議比較：
沒有單獨的 Prepare 階段绅你，降低協(xié)議成本
系統(tǒng)故障容忍度高伺帘，恢復簡單
其中關鍵組件異步可靠消息策略如下：
其中一些關鍵設計點：
若在第 2、3忌锯、4 步出現(xiàn)故障伪嫁，業(yè)務系統(tǒng)自行決定回滾還是另起補償機制；若在第 6偶垮、7 步出現(xiàn)異常张咳，消息中心需要回查生產(chǎn)者；若在第 8 步出現(xiàn)異常似舵，消息中心需要重試脚猾。第 6 步的確認消息由消息中心組件封裝，應用系統(tǒng)無需感知砚哗。
此套機制保障了消息數(shù)據(jù)的完整性龙助，進而保障了與通過異步可靠消息通訊的系統(tǒng)數(shù)據(jù)最終一致性。
某些業(yè)務的前置檢查蛛芥，需要消息中心提供指定條件回查機制提鸟。
針對上面的技術我特意整理了一下，有很多技術不是靠幾句話能講清楚仅淑，所以干脆錄制了一些視頻称勋，很多問題其實答案很簡單，但是背后的思考和邏輯不簡單涯竟，要做到知其然還要知其所以然赡鲜。如果想深入學習的朋友可以加我的 Java 架構群：650385180，我會在群里分享我從業(yè)多年的工作經(jīng)驗昆禽，也會把一些大型互聯(lián)網(wǎng)技術的視頻免費分享給大家蝗蛙，供大家下載。
螞蟻花唄是今年增加的一個新支付工具醉鳖，“確認收貨后捡硅、下月還”的支付體驗受到了越來越多的消費者信賴。跟余額和余額寶一樣盗棵，螞蟻花唄避開了銀行間的交易鏈路壮韭，最大限度避免支付時的擁堵北发。據(jù)官方數(shù)據(jù)披露，在今天的雙十一大促中喷屋，螞蟻花唄支付成功率達到 99.99%琳拨、平均每筆支付耗時 0.035 秒，和各大銀行渠道一起確保了支付的順暢屯曹。
螞蟻花唄距今發(fā)展不到一年狱庇，但發(fā)展速度非常快恶耽。從上線初期的 10 筆 / 秒的支付量發(fā)展到雙十一當天峰值 2.1w 筆 / 秒密任。支撐螞蟻花唄業(yè)務發(fā)展的技術體系經(jīng)過不斷演進、已經(jīng)完全依托于螞蟻金服的金融云架構偷俭。
在 2014 年 12 月浪讳，螞蟻花唄團隊完成業(yè)務系統(tǒng)優(yōu)化，按照標準將系統(tǒng)架設到了金融云上涌萤，依次對接了渠道層淹遵、業(yè)務層、核心平臺層负溪、數(shù)據(jù)層透揣，使得用戶對螞蟻花唄在營銷、下單和支付整個過程中體驗統(tǒng)一川抡。
2015 年 4 月淌实，螞蟻花唄系統(tǒng)同步金融云的單元化的建設，即 LDC猖腕，使得數(shù)據(jù)和應用走向異地成為了現(xiàn)實，具備了較好的擴展性和流量管控能力恨闪。在可用性方面倘感，與金融云賬務體系深度結合，借用賬務系統(tǒng)的 failover 能力咙咽，使得螞蟻花唄通過低成本改造就具備了同城災備老玛、異地災備等高可用能力。任何一個單元的數(shù)據(jù)庫出了問題钧敞、能夠快速進行容災切換蜡豹、不會影響這個單元的用戶進行螞蟻花唄支付。在穩(wěn)定性方面溉苛，借助于云客戶平臺的高穩(wěn)定性的能力镜廉，將螞蟻花唄客戶簽約形成的合約數(shù)據(jù)遷移進去，并預先寫入云客戶平臺的緩存中愚战，在大促高峰期緩存的命中率達到 100%娇唯。同時齐遵，結合全鏈路壓測平臺，對螞蟻花唄進行了能力摸高和持續(xù)的穩(wěn)定性測試塔插，發(fā)現(xiàn)系統(tǒng)的性能點反復進行優(yōu)化梗摇，使得大促當天系統(tǒng)平穩(wěn)運行。在之前的架構中想许，系統(tǒng)的秒級處理能力無法有效衡量伶授，通過簡單的引流壓測無法得到更加準確、可信的數(shù)據(jù)流纹。立足于金融云糜烹，系統(tǒng)很快通過全鏈路壓測得到了每秒處理 4w 筆支付的穩(wěn)定能力。
螞蟻花唄業(yè)務中最為關鍵的一環(huán)在于買家授信和支付風險的控制捧颅。從買家下單的那一刻開始景图，后臺便開始對虛假交易、限額限次碉哑、套現(xiàn)挚币、支用風險等風險模型進行并行計算，這些模型最終將在 20ms 以內(nèi)完成對僅百億數(shù)據(jù)的計算和判定扣典，能夠在用戶到達收銀臺前確定這筆交易是否存在潛在風險妆毕。
為了保證螞蟻花唄雙 11 期間的授信資金充足，在金融云體系下搭建了機構資產(chǎn)中心贮尖，對接支付清算平臺笛粘，將表內(nèi)的信貸資產(chǎn)打包形成一個一定期限的資產(chǎn)池，并以這個資產(chǎn)池為基礎湿硝，發(fā)行可交易證券進行融資薪前，即通過資產(chǎn)轉讓的方式獲得充足資金，通過這一創(chuàng)新確保了用戶能夠通過花唄服務順利完成交易关斜，并分流對銀行渠道的壓力示括。通過資產(chǎn)證券化運作，不僅幫助 100 多萬小微企業(yè)實現(xiàn)融資痢畜，也支撐了螞蟻花唄用戶的消費信貸需求垛膝。螞蟻小貸的資產(chǎn)證券化業(yè)務平臺可達到每小時過億筆、總規(guī)模數(shù)十億元級別的資產(chǎn)轉讓丁稀。
經(jīng)過這么多年的高可用架構和大促的準備工作吼拥，螞蟻金融技術團隊可以做到“先勝而后求戰(zhàn)”，主要分為三方面技術積累：“謀”线衫，“器”凿可，“將”。
“謀”就是整體的架構設計方案和策略桶雀；
“器”就是支持技術工作的各種基礎中間件和基礎組件矿酵；
“將”就是通過實踐鍛煉成長起來的技術人員唬复。
縱觀現(xiàn)在各種架構分享，大家喜歡談“謀”的方面較多全肮，各種架構設計方案優(yōu)化策略分享敞咧，但實際最后多是兩種情況：“吹的牛 X 根本沒被證實過”（各種框架能力根本沒經(jīng)過實際考驗，只是一紙空談）辜腺，“吹過的牛 X 一經(jīng)實際考驗就破了”（說的設計理念很好秋忙，但是一遇到實際的大業(yè)務的沖擊系統(tǒng)就掛了）撒强，最后能成功的少之又少辆琅。這些說明雖然架構上的“心靈雞湯”和“成功學”技術人員都已經(jīng)熟的不行滞诺，但是發(fā)現(xiàn)一到實踐其實根本不是那么回事。從此可以看出百匆，其實最后起決定作用的不是 “謀”方面的理論層面的分析設計砌些，最重要的是落地“器”和“將”的層面。有過硬高穩(wěn)定性的各種基礎設施工具的和身經(jīng)百戰(zhàn)被“虐了千百次”的技術人員的支撐才是最后取勝的關鍵加匈。而這個兩個層面的問題是不能通過分享學到的存璃，是要通過日積月累的，無數(shù)流血流淚趟雷中招鍛煉出來的雕拼，沒有近路可抄纵东。
而目前從業(yè)務和市場的發(fā)展形勢來看，往往就是需要技術在某個特定時間有個質(zhì)的能力的提升和飛躍啥寇，不會給你太多的準備技術架構提升的時間偎球，在技術積累和人員儲備都不足的時候，如何構建平臺能力辑甜，把更多的精力放在業(yè)務相關的開發(fā)任務中衰絮，是每個技術團隊的希望得到的能力 。
過去我們是通過某個開源或者商業(yè)組件來實現(xiàn)技術共享得到快速解決謀發(fā)展技術的能力的磷醋，但是隨著業(yè)務復雜性岂傲，專業(yè)性，規(guī)模的逐步變大子檀，這種方式的缺點也是顯而易見的：
1、很多組件根本無法滿足大并發(fā)場景下的各種技術指標乃戈；
2褂痰、隨著業(yè)務的復雜和專業(yè)性的提高，沒有可以直接使用的開源組件症虑；
3缩歪、“人”本身的經(jīng)驗和能力是無法傳遞的。
所以現(xiàn)在我們通過“云”分享的技術和業(yè)務的能力的方式也發(fā)展的越來越快谍憔，這就我們剛才介紹的“螞蟻花唄”技術用幾個月的時間快速的成功的達到“從上線初期的 10 筆 / 秒的支付量發(fā)展到雙十一當天峰值 2.1w 筆 / 秒匪蝙，快速走完了別人走了幾年都可能達不到的能力主籍。類似的例子還有大家熟知的“余額寶”系統(tǒng)。
這些都是建立在原來螞蟻金服用了 10 年打磨的基礎組件和技術人員經(jīng)驗的云服務上的逛球，通過目前基于這種能力千元，我們目前可以快速給內(nèi)部和外部的客戶組建，高可用颤绕、安全幸海、高效、合規(guī)的金融云服務架構下的系統(tǒng)奥务。
