每年“雙11”都是一場電商盛會，消費者狂歡日。今年雙11的意義尤爲重大，它已經發展成爲全世界電商和消費者都參與進來的盛宴。而對技術人員來說，雙十一無疑已經成爲一場大考，考量的角度是整體架構、基礎中間件、運維工具、人員等。

一次成功的大促準備不光是針對活動本身對系統和架構做的優化措施，比如：流量控制，緩存策略，依賴管控，性能優化……更是與長時間的技術積累和打磨分不開。下面我將簡單介紹支付寶的整體架構，讓大家有個初步認識，然後會以本次在大促中大放異彩的“螞蟻花唄”爲例，大致介紹一個新業務是如何從頭開始準備大促的。架構

支付寶的架構設計上應該考慮到互聯網金融業務的特殊性，比如要求更高的業務連續性，更好的高擴展性，更快速的支持新業務發展等特點。目前其架構如下：

整個平臺被分成了三個層：運維平臺（IAAS）：主要提供基礎資源的可伸縮性，比如網絡、存儲、數據庫、虛擬化、IDC等，保證底層系統平臺的穩定性；技術平臺（PAAS）：主要提供可伸縮、高可用的分佈式事務處理和服務計算能力，能夠做到彈性資源的分配和訪問控制，提供一套基礎的中間件運行環境，屏蔽底層資源的複雜性；業務平臺（SAAS）：提供隨時隨地高可用的支付服務，並且提供一個安全易用的開放支付應用開發平臺。架構特性

邏輯數據中心架構

在雙十一大促當天業務量年年翻番的情況下，支付寶面臨的考驗也越來越大：系統的容量越來越大，服務器、網絡、數據庫、機房都隨之擴展，這帶來了一些比較大的問題，比如系統規模越來越大，系統的複雜度越來越高，以前按照點的伸縮性架構無法滿足要求，需要我們有一套整體性的可伸縮方案，可以按照一個單元的維度進行擴展。能夠提供支持異地伸縮的能力，提供N+1的災備方案，提供整體性的故障恢復體系。基於以上幾個需求，我們提出了邏輯數據中心架構，核心思想是把數據水平拆分的思路向上層提到接入層、終端， 從接入層開始把系統分成多個單元，單元有幾個特性：每個單元對外是封閉的，包括系統間交換各類存儲的訪問;每個單元的實時數據是獨立的，不共享。而會員或配置類對延時性要求不高的數據可共享;單元之間的通信統一管控，儘量走異步化消息。同步消息走單元代理方案；

下面是支付寶邏輯機房架構的概念圖：

這套架構解決了幾個關鍵問題：由於儘量減少了跨單元交互和使用異步化，使得異地部署成爲可能。整個系統的水平可伸縮性大大提高，不再依賴同城IDC；可以實現N+1的異地災備策略，大大縮減災備成本，同時確保災備設施真實可用；整個系統已無單點存在，大大提升了整體的高可用性；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平臺進行快速切換，有機會實現100%的持續可用率；該架構下業務級別的流量入口和出口形成了統一的可管控、可路由的控制點，整體系統的可管控能力得到很大提升。基於該架構，線上壓測、流量管控、灰度發佈等以前難以實現的運維管控模式，現在能夠十分輕鬆地實現。

目前新架構的同城主體框架在2013年已經完成，並且順利的面對了雙十一的考驗，讓整套架構的落地工作得到了很好的證明。

在2015年完成了基於邏輯機房，異地部署的“異地多活”的架構落地。“異地多活”架構是指，基於邏輯機房擴展能力，在不同的地域IDC部署邏輯機房，並且每個邏輯機房都是“活”的，真正承接線上業務，在發生故障的時候可以快速進行邏輯機房之間的快速切換。

這比傳統的“兩地三中心”架構有更好的業務連續性保障。在“異地多活”的架構下，一個IDC對應的故障容災IDC是一個“活”的IDC，平時就承接着正常線上業務，保證其穩定性和業務的正確性是一直被確保的。

以下是支付寶“異地多活”架構示意圖：

除了更好的故障應急能力之外，基於邏輯機房我們又具備的“藍綠髮布”或者說“灰度發佈”的驗證能力。我們把單個邏輯機房（後續簡稱LDC）內部又分成A、B兩個邏輯機房，A 、B機房在功能上完全對等。日常情況下，調用請求按照對等概率隨機路由到A或B 。當開啓藍綠模式時，上層路由組件會調整路由計算策略，隔離A與B之間的調用， A組內應用只能相互訪問，而不會訪問B組。

然後進行藍綠髮布流程大致如下：

Step1. 發佈前，將“藍”流量調至0%，對“藍”的所有應用整體無序分2組發佈。

Step2. “藍”引流1%觀察，如無異常，逐步上調分流比例至100%。

Step3. “綠”流量爲0%，對“綠”所有應用整體無序分2組發佈。

Step4. 恢復日常運行狀態，藍、綠單元各承擔線上50%的業務流量。分佈式數據架構

支付寶在2015年雙十一當天的高峯期間處理支付峯值8.59萬筆/秒，已經是國際第一大系統支付。支付寶已經是全球最大的OLTP處理者之一，對事務的敏感使支付寶的數據架構有別於其他的互聯網公司，卻繼承了互聯網公司特有的巨大用戶量，最主要的是支付寶對交易的成本比傳統金融公司更敏感，所以支付寶數據架構發展，就是一部低成本、線性可伸縮、分佈式的數據架構演變史。

現在支付寶的數據架構已經從集中式的小型機和高端存儲升級到了分佈式PC服務解決方案，整體數據架構的解決方案儘量做到無廠商依賴，並且標準化。

支付寶分佈式數據架構可伸縮策略主要分爲三個維度：

按照業務類型進行垂直拆分按照客戶請求進行水平拆分（也就是常說的數據的sharding策略）對於讀遠遠大於寫的數據進行讀寫分離和數據複製處理

下圖是支付寶內部交易數據的可伸縮性設計：

交易系統的數據主要分爲三個大數據庫集羣：主交易數據庫集羣，每一筆交易創建和狀態的修改首先在這⾥完成，產生的變更再通過可靠數據複製中心複製到其他兩個數據庫集羣：消費記錄數據庫集羣、商戶查詢數據庫集羣。該數據庫集羣的數據被水平拆分成多份，爲了同時保證可伸縮性和高可靠性，每一個節點都會有與之對應的備用節點和failover節點，在出現故障的時候可以在秒級內切換到failover節點。消費記錄數據庫集羣，提供消費者更好的用戶體驗和需求；商戶查詢數據庫集羣，提供商戶更好的用戶體驗和需求；

對於分拆出來的各個數據節點，爲了保證對上層應用系統的透明，我們研發一套數據中間產品來保證交易數據做到彈性擴容。數據的可靠性

分佈式數據架構下，在保證事務原有的ACID（原子性、一致性、隔離性、持久性）特性的基礎上，還要保證高可用和可伸縮性，挑戰非常大。試想你同時支付了兩筆資金，這兩筆資金的事務如果在分佈式環境下相互影響，在其中一筆交易資金回滾的情況下，還會影響另外一筆是多麼不能接受的情況。

根據CAP和BASE原則，再結合支付寶系統的特點，我們設計了一套基於服務層面的分佈式事務框架，他支持兩階段提交協議，但是做了很多的優化，在保證事務的ACID原則的前提下，確保事務的最終一致性 。我們叫做“柔性事物”策略。原理如下：

以下是分佈式事務框架的流程圖：

實現：一個完整的業務活動由一個主業務服務與若干從業務服務組成。主業務服務負責發起並完成整個業務活動。從業務服務提供TCC型業務操作。業務活動管理器控制業務活動的一致性，它登記業務活動中的操作，並在活動提交時確認所有的兩階段事務的confirm操作，在業務活動取消時調用所有兩階段事務的cancel操作。”

與2PC協議比較：沒有單獨的Prepare階段，降低協議成本系統故障容忍度高，恢復簡單

其中關鍵組件異步可靠消息策略如下：

其中一些關鍵設計點：若在第2、3、4步出現故障，業務系統自行決定回滾還是另起補償機制；若在第6、7步出現異常，消息中心需要回查生產者；若在第8步出現異常，消息中心需要重試。第6步的確認消息由消息中心組件封裝，應用系統無需感知。此套機制保障了消息數據的完整性，進而保障了與通過異步可靠消息通訊的系統數據最終一致性。某些業務的前置檢查，需要消息中心提供指定條件回查機制。

針對上面的技術我特意整理了一下，有很多技術不是靠幾句話能講清楚，所以乾脆找朋友錄製了一些視頻，很多問題其實答案很簡單，但是背後的思考和邏輯不簡單，要做到知其然還要知其所以然。如果想學習Java工程化、高性能及分佈式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java進階羣：694549689，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。螞蟻花唄

螞蟻花唄是今年增加的一個新支付工具，“確認收貨後、下月還”的支付體驗受到了越來越多的消費者信賴。跟餘額和餘額寶一樣，螞蟻花唄避開了銀行間的交易鏈路，最大限度避免支付時的擁堵。據官方數據披露，在今天的雙十一大促中，螞蟻花唄支付成功率達到99.99%、平均每筆支付耗時0.035秒，和各大銀行渠道一起確保了支付的順暢。

螞蟻花唄距今發展不到一年，但發展速度非常快。從上線初期的10筆/秒的支付量發展到雙十一當天峯值2.1w筆/秒。支撐螞蟻花唄業務發展的技術體系經過不斷演進、已經完全依託於螞蟻金服的金融雲架構。

在2014年12月，螞蟻花唄團隊完成業務系統優化，按照標準將系統架設到了金融雲上，依次對接了渠道層、業務層、核心平臺層、數據層，使得用戶對螞蟻花唄在營銷、下單和支付整個過程中體驗統一。

2015年4月，螞蟻花唄系統同步金融雲的單元化的建設，即LDC，使得數據和應用走向異地成爲了現實，具備了較好的擴展性和流量管控能力。在可用性方面，與金融雲賬務體系深度結合，借用賬務系統的failover能力，使得螞蟻花唄通過低成本改造就具備了同城災備、異地災備等高可用能力。任何一個單元的數據庫出了問題、能夠快速進行容災切換、不會影響這個單元的用戶進行螞蟻花唄支付。在穩定性方面，藉助於雲客戶平臺的高穩定性的能力，將螞蟻花唄客戶簽約形成的合約數據遷移進去，並預先寫入雲客戶平臺的緩存中，在大促高峯期緩存的命中率達到100%。同時，結合全鏈路壓測平臺，對螞蟻花唄進行了能力摸高和持續的穩定性測試，發現系統的性能點反覆進行優化，使得大促當天系統平穩運行。在之前的架構中，系統的秒級處理能力無法有效衡量，通過簡單的引流壓測無法得到更加準確、可信的數據。立足於金融雲，系統很快通過全鏈路壓測得到了每秒處理4w筆支付的穩定能力。

螞蟻花唄業務中最爲關鍵的一環在於買家授信和支付風險的控制。從買家下單的那一刻開始，後臺便開始對虛假交易、限額限次、套現、支用風險等風險模型進行並行計算，這些模型最終將在20ms以內完成對僅百億數據的計算和判定，能夠在用戶到達收銀臺前確定這筆交易是否存在潛在風險。

爲了保證螞蟻花唄雙11期間的授信資金充足，在金融雲體系下搭建了機構資產中心，對接支付清算平臺，將表內的信貸資產打包形成一個一定期限的資產池，並以這個資產池爲基礎，發行可交易證券進行融資，即通過資產轉讓的方式獲得充足資金，通過這一創新確保了用戶能夠通過花唄服務順利完成交易，並分流對銀行渠道的壓力。通過資產證券化運作，不僅幫助100多萬小微企業實現融資，也支撐了螞蟻花唄用戶的消費信貸需求。螞蟻小貸的資產證券化業務平臺可達到每小時過億筆、總規模數十億元級別的資產轉讓。總結

經過這麼多年的高可用架構和大促的準備工作，螞蟻金融技術團隊可以做到“先勝而後求戰”，主要分爲三方面技術積累：“謀”，“器”，“將”。

“謀”就是整體的架構設計方案和策略；

“器”就是支持技術工作的各種基礎中間件和基礎組件；

“將”就是通過實踐鍛鍊成長起來的技術人員。

縱觀現在各種架構分享，大家喜歡談“謀”的方面較多，各種架構設計方案優化策略分享，但實際最後多是兩種情況：“吹的牛X根本沒被證實過”（各種框架能力根本沒經過實際考驗，只是一紙空談），“吹過的牛X一經實際考驗就破了”（說的設計理念很好，但是一遇到實際的大業務的衝擊系統就掛了），最後能成功的少之又少。這些說明雖然架構上的“心靈雞湯”和“成功學”技術人員都已經熟的不行，但是發現一到實踐其實根本不是那麼回事。從此可以看出，其實最後起決定作用的不是 “謀”方面的理論層面的分析設計，最重要的是落地“器”和“將”的層面。有過硬高穩定性的各種基礎設施工具的和身經百戰被“虐了千百次”的技術人員的支撐纔是最後取勝的關鍵。而這個兩個層面的問題是不能通過分享學到的，是要通過日積月累的，無數流血流淚趟雷中招鍛煉出來的，沒有近路可抄。

而目前從業務和市場的發展形勢來看，往往就是需要技術在某個特定時間有個質的能力的提升和飛躍，不會給你太多的準備技術架構提升的時間，在技術積累和人員儲備都不足的時候，如何構建平臺能力，把更多的精力放在業務相關的開發任務中，是每個技術團隊的希望得到的能力 。

過去我們是通過某個開源或者商業組件來實現技術共享得到快速解決謀發展技術的能力的，但是隨着業務複雜性，專業性，規模的逐步變大，這種方式的缺點也是顯而易見的：1、很多組件根本無法滿足大併發場景下的各種技術指標；2、隨着業務的複雜和專業性的提高，沒有可以直接使用的開源組件；3、“人”本身的經驗和能力是無法傳遞的。

所以現在我們通過“雲”分享的技術和業務的能力的方式也發展的越來越快，這就我們剛纔介紹的“螞蟻花唄”技術用幾個月的時間快速的成功的達到“從上線初期的10筆/秒的支付量發展到雙十一當天峯值2.1w筆/秒，快速走完了別人走了幾年都可能達不到的能力。類似的例子還有大家熟知的“餘額寶”系統。

這些都是建立在原來螞蟻金服用了10年打磨的基礎組件和技術人員經驗的雲服務上的，通過目前基於這種能力，我們目前可以快速給內部和外部的客戶組建，高可用、安全、高效、合規的金融雲服務架構下的系統。