阿里架構師的述說：支付寶和螞蟻花唄的技術架構及雙十一實踐

javaxuexi123發表於2018-02-28
阿里架構
每年“雙11”都是一場電商盛會，消費者狂歡日。今年雙11的意義尤為重大，它已經發展成為全世界電商和消費者都參與進來的盛宴。而對技術人員來說，雙十一無疑已經成為一場大考，考量的角度是整體架構、基礎中介軟體、運維工具、人員等。
 
一次成功的大促準備不光是針對活動本身對系統和架構做的優化措施，比如：流量控制，快取策略，依賴管控，效能優化……更是與長時間的技術積累和打磨分不開。下面我將簡單介紹支付寶的整體架構，讓大家有個初步認識，然後會以本次在大促中大放異彩的“螞蟻花唄”為例，大致介紹一個新業務是如何從頭開始準備大促的。
架構
支付寶的架構設計上應該考慮到網際網路金融業務的特殊性，比如要求更高的業務連續性，更好的高擴充套件性，更快速的支援新業務發展等特點。目前其架構如下：
整個平臺被分成了三個層：
  1. 運維平臺（IAAS）：主要提供基礎資源的可伸縮性，比如網路、儲存、資料庫、虛擬化、IDC等，保證底層系統平臺的穩定性；
  2. 技術平臺（PAAS）：主要提供可伸縮、高可用的分散式事務處理和服務計算能力，能夠做到彈性資源的分配和訪問控制，提供一套基礎的中介軟體執行環境，遮蔽底層資源的複雜性；
  3. 業務平臺（SAAS）：提供隨時隨地高可用的支付服務，並且提供一個安全易用的開放支付應用開發平臺。
架構特性
邏輯資料中心架構
在雙十一大促當天業務量年年翻番的情況下，支付寶面臨的考驗也越來越大：系統的容量越來越大，伺服器、網路、資料庫、機房都隨之擴充套件，這帶來了一些比較大的問題，比如系統規模越來越大，系統的複雜度越來越高，以前按照點的伸縮性架構無法滿足要求，需要我們有一套整體性的可伸縮方案，可以按照一個單元的維度進行擴充套件。能夠提供支援異地伸縮的能力，提供N+1的災備方案，提供整體性的故障恢復體系。基於以上幾個需求，我們提出了邏輯資料中心架構，核心思想是把資料水平拆分的思路向上層提到接入層、終端， 從接入層開始把系統分成多個單元，單元有幾個特性：
  1. 每個單元對外是封閉的，包括系統間交換各類儲存的訪問;
  2. 每個單元的實時資料是獨立的，不共享。而會員或配置類對延時性要求不高的資料可共享;
  3. 單元之間的通訊統一管控，儘量走非同步化訊息。同步訊息走單元代理方案；
下面是支付寶邏輯機房架構的概念圖：
這套架構解決了幾個關鍵問題：
  1. 由於儘量減少了跨單元互動和使用非同步化，使得異地部署成為可能。整個系統的水平可伸縮性大大提高，不再依賴同城IDC；
  2. 可以實現N+1的異地災備策略，大大縮減災備成本，同時確保災備設施真實可用；
  3. 整個系統已無單點存在，大大提升了整體的高可用性；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平臺進行快速切換，有機會實現100%的持續可用率；
  4. 該架構下業務級別的流量入口和出口形成了統一的可管控、可路由的控制點，整體系統的可管控能力得到很大提升。基於該架構，線上壓測、流量管控、灰度釋出等以前難以實現的運維管控模式，現在能夠十分輕鬆地實現。
目前新架構的同城主體框架在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服務解決方案，整體資料架構的解決方案儘量做到無廠商依賴，並且標準化。
 
支付寶分散式資料架構可伸縮策略主要分為三個維度：
  1. 按照業務型別進行垂直拆分
  2. 按照客戶請求進行水平拆分（也就是常說的資料的sharding策略）
  3. 對於讀遠遠大於寫的資料進行讀寫分離和資料複製處理
下圖是支付寶內部交易資料的可伸縮性設計：
交易系統的資料主要分為三個大資料庫叢集：
  1. 主交易資料庫叢集，每一筆交易建立和狀態的修改首先在這⾥完成，產生的變更再通過可靠資料複製中心複製到其他兩個資料庫叢集：消費記錄資料庫叢集、商戶查詢資料庫叢集。該資料庫叢集的資料被水平拆分成多份，為了同時保證可伸縮性和高可靠性，每一個節點都會有與之對應的備用節點和failover節點，在出現故障的時候可以在秒級內切換到failover節點。
  2. 消費記錄資料庫叢集，提供消費者更好的使用者體驗和需求；
  3. 商戶查詢資料庫叢集，提供商戶更好的使用者體驗和需求；
對於分拆出來的各個資料節點，為了保證對上層應用系統的透明，我們研發一套資料中間產品來保證交易資料做到彈性擴容。
資料的可靠性
分散式資料架構下，在保證事務原有的ACID（原子性、一致性、隔離性、永續性）特性的基礎上，還要保證高可用和可伸縮性，挑戰非常大。試想你同時支付了兩筆資金，這兩筆資金的事務如果在分散式環境下相互影響，在其中一筆交易資金回滾的情況下，還會影響另外一筆是多麼不能接受的情況。
 
根據CAP和BASE原則，再結合支付寶系統的特點，我們設計了一套基於服務層面的分散式事務框架，他支援兩階段提交協議，但是做了很多的優化，在保證事務的ACID原則的前提下，確保事務的最終一致性 。我們叫做“柔性事物”策略。原理如下：
以下是分散式事務框架的流程圖：
實現：
  1. 一個完整的業務活動由一個主業務服務與若干從業務服務組成。
  2. 主業務服務負責發起並完成整個業務活動。
  3. 從業務服務提供TCC型業務操作。
  4. 業務活動管理器控制業務活動的一致性，它登記業務活動中的操作，並在活動提交時確認所有的兩階段事務的confirm操作，在業務活動取消時呼叫所有兩階段事務的cancel操作。”
與2PC協議比較：
  1. 沒有單獨的Prepare階段，降低協議成本
  2. 系統故障容忍度高，恢復簡單
其中關鍵元件非同步可靠訊息策略如下：
其中一些關鍵設計點：
  1. 若在第2、3、4步出現故障，業務系統自行決定回滾還是另起補償機制；若在第6、7步出現異常，訊息中心需要回查生產者；若在第8步出現異常，訊息中心需要重試。第6步的確認訊息由訊息中心元件封裝，應用系統無需感知。
  2. 此套機制保障了訊息資料的完整性，進而保障了與通過非同步可靠訊息通訊的系統資料最終一致性。
  3. 某些業務的前置檢查，需要訊息中心提供指定條件回查機制。
推薦一個Java高階技術進階群，助你成為一名優秀的架構師:
群號：688583154，可獲取免費的Java架構師學習資料，都是目前最主流的技術，講解框架的結構構造，底層原理，還有原始碼分析，效能優化這些知識點，有需要，想成為架構師的可以加一下。
螞蟻花唄
螞蟻花唄是今年增加的一個新支付工具，“確認收貨後、下月還”的支付體驗受到了越來越多的消費者信賴。跟餘額和餘額寶一樣，螞蟻花唄避開了銀行間的交易鏈路，最大限度避免支付時的擁堵。據官方資料披露，在今天的雙十一大促中，螞蟻花唄支付成功率達到99.99%、平均每筆支付耗時0.035秒，和各大銀行渠道一起確保了支付的順暢。
 
螞蟻花唄距今發展不到一年，但發展速度非常快。從上線初期的10筆/秒的支付量發展到雙十一當天峰值2.1w筆/秒。支撐螞蟻花唄業務發展的技術體系經過不斷演進、已經完全依託於螞蟻金服的金融雲架構。
 
在2014年12月，螞蟻花唄團隊完成業務系統優化，按照標準將系統架設到了金融雲上，依次對接了渠道層、業務層、核心平臺層、資料層，使得使用者對螞蟻花唄在營銷、下單和支付整個過程中體驗統一。
 
2015年4月，螞蟻花唄系統同步金融雲的單元化的建設，即LDC，使得資料和應用走向異地成為了現實，具備了較好的擴充套件性和流量管控能力。在可用性方面，與金融雲賬務體系深度結合，借用賬務系統的failover能力，使得螞蟻花唄通過低成本改造就具備了同城災備、異地災備等高可用能力。任何一個單元的資料庫出了問題、能夠快速進行容災切換、不會影響這個單元的使用者進行螞蟻花唄支付。在穩定性方面，藉助於雲客戶平臺的高穩定性的能力，將螞蟻花唄客戶簽約形成的合約資料遷移進去，並預先寫入雲客戶平臺的快取中，在大促高峰期快取的命中率達到100%。同時，結合全鏈路壓測平臺，對螞蟻花唄進行了能力摸高和持續的穩定性測試，發現系統的效能點反覆進行優化，使得大促當天系統平穩執行。在之前的架構中，系統的秒級處理能力無法有效衡量，通過簡單的引流壓測無法得到更加準確、可信的資料。立足於金融雲，系統很快通過全鏈路壓測得到了每秒處理4w筆支付的穩定能力。
 
螞蟻花唄業務中最為關鍵的一環在於買家授信和支付風險的控制。從買家下單的那一刻開始，後臺便開始對虛假交易、限額限次、套現、支用風險等風險模型進行平行計算，這些模型最終將在20ms以內完成對僅百億資料的計算和判定，能夠在使用者到達收銀臺前確定這筆交易是否存在潛在風險。
 
為了保證螞蟻花唄雙11期間的授信資金充足，在金融雲體系下搭建了機構資產中心，對接支付清算平臺，將表內的信貸資產打包形成一個一定期限的資產池，並以這個資產池為基礎，發行可交易證券進行融資，即通過資產轉讓的方式獲得充足資金，通過這一創新確保了使用者能夠通過花唄服務順利完成交易，並分流對銀行渠道的壓力。通過資產證券化運作，不僅幫助100多萬小微企業實現融資，也支撐了螞蟻花唄使用者的消費信貸需求。螞蟻小貸的資產證券化業務平臺可達到每小時過億筆、總規模數十億元級別的資產轉讓。
總結
經過這麼多年的高可用架構和大促的準備工作，螞蟻金融技術團隊可以做到“先勝而後求戰”，主要分為三方面技術積累：“謀”，“器”，“將”。
“謀”就是整體的架構設計方案和策略；
“器”就是支援技術工作的各種基礎中介軟體和基礎元件；
“將”就是通過實踐鍛鍊成長起來的技術人員。
 
縱觀現在各種架構分享，大家喜歡談“謀”的方面較多，各種架構設計方案優化策略分享，但實際最後多是兩種情況：“吹的牛X根本沒被證實過”（各種框架能力根本沒經過實際考驗，只是一紙空談），“吹過的牛X一經實際考驗就破了”（說的設計理念很好，但是一遇到實際的大業務的衝擊系統就掛了），最後能成功的少之又少。這些說明雖然架構上的“心靈雞湯”和“成功學”技術人員都已經熟的不行，但是發現一到實踐其實根本不是那麼回事。從此可以看出，其實最後起決定作用的不是 “謀”方面的理論層面的分析設計，最重要的是落地“器”和“將”的層面。有過硬高穩定性的各種基礎設施工具的和身經百戰被“虐了千百次”的技術人員的支撐才是最後取勝的關鍵。而這個兩個層面的問題是不能通過分享學到的，是要通過日積月累的，無數流血流淚趟雷中招鍛煉出來的，沒有近路可抄。
而目前從業務和市場的發展形勢來看，往往就是需要技術在某個特定時間有個質的能力的提升和飛躍，不會給你太多的準備技術架構提升的時間，在技術積累和人員儲備都不足的時候，如何構建平臺能力，把更多的精力放在業務相關的開發任務中，是每個技術團隊的希望得到的能力 。
推薦一個Java高階技術進階群，助你成為一名優秀的架構師:
群號：688583154，可獲取免費的Java架構師學習資料，都是目前最主流的技術，講解框架的結構構造，底層原理，還有原始碼分析，效能優化這些知識點，有需要，想成為架構師的可以加一下。
 
過去我們是通過某個開源或者商業元件來實現技術共享得到快速解決謀發展技術的能力的，但是隨著業務複雜性，專業性，規模的逐步變大，這種方式的缺點也是顯而易見的：1、很多元件根本無法滿足大併發場景下的各種技術指標；2、隨著業務的複雜和專業性的提高，沒有可以直接使用的開源元件；3、“人”本身的經驗和能力是無法傳遞的。
所以現在我們通過“雲”分享的技術和業務的能力的方式也發展的越來越快，這就我們剛才介紹的“螞蟻花唄”技術用幾個月的時間快速的成功的達到“從上線初期的10筆/秒的支付量發展到雙十一當天峰值2.1w筆/秒，快速走完了別人走了幾年都可能達不到的能力。類似的例子還有大家熟知的“餘額寶”系統。
 
這些都是建立在原來螞蟻金服用了10年打磨的基礎元件和技術人員經驗的雲服務上的，通過目前基於這種能力，我們目前可以快速給內部和外部的客戶組建，高可用、安全、高效、合規的金融雲服務架構下的系統。

相關文章