阿里雙十一背后的技術「淘寶網站體系架構」

淘寶雙十一當日要處理千億級的交易額，堪稱當今世界IT系統獨一無二的挑戰，其背后有著怎樣的技術架構和技術支撐體系？

雙十一背后的技術架構

按需伸縮：彈性混合云架構

每年淘寶都要應對雙11、新春紅包等活動的極高交易量。盡管單元化架構讓阿里具備應對峰值的能力，但要降低高峰期的資源投入，系統還需具備按需伸縮的能力。

阿里解決這個問題的方法是，活動前在云計算平臺快速申請資源，構建新的單元、部署應用與數據庫。然后將流量與數據“彈出”到新的單元，快速提升系統容量。當活動結束后，再將流量與數據“彈回”，釋放云計算平臺上的資源。

通過這種方式，可以大大降低資源采購與運行成本。彈性操作，需要在流量、數據與資源之間協調一致地操作，尤其是有狀態的數據的彈性操作最困難，既不能不中斷業務，又要保證數據的一致性。這些操作如果依靠運維人員人工執行則會十分復雜低效，因而需要架構、中間件與管控系統的支持。

云平臺是把海量機器資源，通過統一的資源管理，抽象為一個資源整體，在之上可按需動態申請硬件資源（如CPU、內存、網絡等），并且之上提供通用的操作系統，提供常用的技術組件（如Hadoop技術棧，MPP數據庫等）供用戶使用，甚至提供開發好的應用，用戶不需要關系應用內部使用了什么技術，就能夠解決需求（如音視頻轉碼服務、郵件服務、個人博客等）。

異地多活與容災：單元化架構

異地多活與容災架構的基礎是對系統進行單元化。每個單元可以認為是一個縮小規模的、包含從接入網關、應用服務到數據存儲的全功能系統。每個單元負責一定比例的數據與用戶訪問。

有以下關鍵特性：

自包含性：比如用戶的一次賬戶充值交易，涉及的所有計算與數據都在一個單元內完成。

松耦合性：跨單元之間只能進行服務調用，不能直接訪問數據庫或其他存儲。對于一些必須跨單元的交易處理，比如分屬于兩個不同單元的用戶之間的轉賬交易，跨單元的服務調用次數盡可能少，在業務與用戶體驗允許的情況下盡量異步處理。這樣，即使兩個單元之間相距上千千米，也可以容忍跨單元的訪問時延。

故障獨立性：一個單元內的故障，不會傳播到其他單元。

容災性：單元之間相互備份，確保每個單元在同城和異地都有可在故障期間進行接管的單元。數據在單元間的備份方式，阿里以OceanBase提供的多地多中心強一致方案為主。

通過異地多活，系統可以在全國范圍內任意擴展，服務器資源得到了充分利用，提升了系統應對地區級災難的能力。

金融級分布式數據庫：OceanBase

OceanBase（中文名“海鋇云”）是阿里巴巴/螞蟻金服集團自主研發的面向云時代的關系數據庫，它構建在普通服務器組成的分布式集群之上，具備可擴展、高可用、高性能、低成本及多租戶等核心技術優勢。OceanBase應用于螞蟻金服的會員、交易、支付、賬務、計費等核心系統和網商銀行等業務系統，并開始對外提供云服務。在剛剛過去的雙11，用戶每一筆支付訂單背后的數據和事務處理都由OceanBase完成。

從產品的角度看，云數據庫具備線性擴展、高可用、低成本等核心優勢，并內置多租戶支持，兼容MySQL，適合部署在云環境。相比傳統的IOE架構，OceanBase能夠將成本降低一到兩個數量級，并提供更好的擴展性及高可用能力。另外，OceanBase支持平滑遷移，無須業務改造，就可以將原先使用MySQL的業務遷移到OceanBase。

從技術的角度看，云數據庫采用無共享（Share-nothing）的分布式架構，如圖所示。

P1~P8：OceanBase將表格按照傳統數據庫分區表的方式進行分區，并將不同的分區自動調度到不同的服務器。為了實現高可用，P1~P8每個分區都會至少存儲三個副本，并且部署到不同的IDC機房。每個分區的副本之間通過Paxox選舉協議進行日志同步，跨分區事務通過兩階段提交協議實現。

ObServer：OceanBase后臺的數據庫工作機，用來存儲數據并執行用戶的SQL請求。ObServer之間無共享，每臺ObServer只會服務一部分分區。當集群容量不足時，只需要增加ObServer即可。

ObProxy：OceanBase代理服務器，用戶的請求首先發送到ObProxy，再由由ObProxy轉發給用戶請求的數據所在的ObServer。

RootService：OceanBase會動態地從集群中選出一臺ObServer提供總控服務，包括集群服務器管理、負載均衡等全局調度與管控操作。這個總控服務是一個集成在ObServer進程中的模塊，稱為RootService。

保障雙十一穩定的技術支撐體系

圖：螞蟻金服架構與技術體系

規模和場景是驅動技術發展的關鍵要素。支撐雙11最大的困難就在于零點峰值的穩定性保障。面對這種世界級的場景、獨一無二的挑戰，阿里建設了大量高可用技術產品，形成了全鏈路一體化的解決方案，用更加逼真和自動的方式，去評估、優化和保護整個技術鏈條，確保雙11的穩定性。

容量規劃

阿里有著非常豐富的業務形態，眾所周知的如淘寶、天貓、聚劃算、菜鳥等，每一塊業務背后都有幾十個甚至上幾百個與之對應的業務系統，每個業務系統都部署在多臺服務器上。在如此龐大的分布式系統架構下，該為每一個業務系統分配多少機器，什么時候需要加機器，什么時候需要減機器，該加多少機器，減多少機器，成為一大技術挑戰。

阿里采用CSP（ContinuouslyStable Platform）持續穩定性平臺，為線上應用穩定運行提供一系列的保障。CSP容量規劃平臺從業務流量的預測到機器資源的預估，提供了一整套系統化、自動化的解決方案，從容量的維度以最低的成本保障了阿里業務的穩定性。

全鏈路壓測

全鏈路壓測被阿里譽為大促備戰的“核武器”。

每年雙11前夕，全鏈路壓測都要組織好幾次，不斷地通過壓測發現問題進行迭代優化，全方位驗證業務的穩定性，阿里的業務系統也只有在經過了全鏈路壓測的驗證之后才有信心迎接雙11零點的到來。全鏈路壓測將大促穩定性保障提升到新的高度，是雙11、雙12等大促備戰最重要的“核武器”，并且隨著業務的發展不斷進化，持續發揮著不可替代的作用。

圖：全鏈路壓測生態

全鏈路驗證功能

全鏈路功能是阿里第一個基于大數據、基于電商交易鏈路規則建模，進行大促功能可用性驗證的項目。隨著智能化和智慧化的深入人心，全鏈路功能搭建并經過驗證的基礎能力，包括影子數據同步能力、規則模型分析歸類輸出能力、隔離環境提前驗證能力等，正在被越來越多的創新項目依賴和使用，成為創新的源泉。

自動化備戰

大促備戰通俗來講就是電商BU下的10多個作戰團隊（技術團隊）在雙11前期，通過完成幾十種工作序列，讓這個由幾百個應用系統、數據庫、中間件等所組成的龐大的電商體系能夠在雙11當天穩定地經受住零點大流量的考驗，讓大家在雙11期間順暢安心地買買買。

逐步將這些工作進一步抽象與串聯在一起，如圖所示。抽象與串聯簡單來說要做的就是要串聯備戰環節的公共節點，從全鏈路壓測鏈路模型的自動計算，全鏈路數據準備和流量發送的無縫銜接，應用容量的彈性伸縮，自動化預案執行和驗證，高可用業務保障等多個維度將大家共用的工作序列抽象出來，將其中人工的操作自動化，再沉淀為一種公共的基礎能力。這樣在每屆大促備戰中就能得以延續與演進，并且也能在日常工作中運用起來，就不是原來的各技術團隊相互之間的多樣化與定制化的工作了。

自動化備戰項目：

實時業務審計

BCP（Business Check Platform），實時業務審計平臺，是一個用來實時檢測線上系統產生的數據是否正確的系統。試想一下，一個用戶剛剛在雙11活動下了一單，付完款。但有可能由于網絡突然出現閃斷，導致他“已付款”這個狀態的數據并沒有傳輸過來。如果是以往，有可能呈現給買家的就是“交易失敗”的狀態。但現在，BCP能在這個問題被消費者發現之前，就開始報警，并且轉交技術人員處理。從而可能讓用戶感受不到“交易失敗”曾經出現過。

故障演練

故障演練的基本要求是故障模擬要真實，具有通用性，故障影響要可控，實施成本要低。

由近十個業務部門參與，數百個演練場景設計，數十次大大小小的演習，發現并解決了大量的問題。在對故障做了全面的分析之后，發現除了系統功能類bug和人為失誤故障，剩余的故障主要為技術缺陷導致。技術缺陷型的故障原因主要分布在網絡、磁盤、進程、CPU、數據庫、中間件等諸多大類。故障演練的場景主要就是圍繞這幾個大類來細化：

故障演練策略主要從故障重現、故障演練、故障突襲三個角度切入，滿足不同系統或人的需求。

故障突襲：一種以黑盒測試的模式驗收穩定性的演練策略。宏觀上，可以通過機房斷網、斷電的演練，推進架構的改進和成熟。微觀上，也可以在大家不知情的情況下搞一些小破壞，觀察系統的問題發現、自愈能力，故障處理流程是否合理，或制造更多的機會來鍛煉新人的問題處理能力。

系統自我保護體系

系統保護體系主要由5大子系統構成：限流、自動降級、流量調度、負載保護和預案，每一個子系統對應一種典型的系統保護場景。

限流：通過限流讓系統工作在最高吞吐量的水位上，防止系統被擊垮。限流策略根據請求的被動響應和主動發起分為兩種：當請求被動響應時，請求的發起方通常是用戶，這種情況下將啟用“洪峰限流”策略；當請求為主動發起時，一般情況下為定時任務的執行頻度或者消息的消費速度，這種情況下將啟用“回調限流”策略。回調限流的實現通過漏桶算法來解決，水（請求）先進入漏桶里，漏桶以一定的速度出水，當水流入速度過大時會直接溢出，通過這種方式來調節請求的處理速度。

自動降級：整個下單鏈路上不是所有環節都是下單的必要條件。例如，下單時，店鋪的“相關物品推薦”、商品評價，這些對于下單這一場景來說都是錦上添花的事情。當弱依賴環節出現不可用的情況，將弱依賴自動降級，可保障核心環節的穩定可靠，在實際的生活中類似于“棄車保帥”的策略。自動降級需要對鏈路進行強弱依賴梳理，了解這個鏈路上哪些環節是可以降級的。通過監控可以知道每個調用的響應時間、線程數、異常，這樣在調用鏈路中，如果一個環節不可用對于發起調用的應用來說，是可以自動感知并且探測到的。一旦探測到某個弱依賴不可用，將促發自動降級，讓業務請求依然可以往下執行。

流量調度：流量調度，就是要屏蔽所有機器的軟硬件差異，根據機器的實時服務能力來分配機器的實時流量。實時服務能力好的機器，多分配流量；實時服務能力差的機器，減少流量分配；實時服務能力不可用的機器，遷移流量。

負載保護：當大部分機器的系統負載處在一個比較危險的情況下，會自動對外部的流量進行限制，減少外部流量進來，緩解系統的壓力，自動進行負載保護。負載保護使得系統的每臺機器都具備自我保護的能力，當限流閾值設置得不合理或者出問題的機器數超過了流量調度的機器數上限之后，單機的自我保護策略成為保命的稻草。

預案：如果因為系統保護或者其他狀態而影響到大量用戶的體驗，會啟動另一個策略——執行預案：提前準備好在各種不同的緊急情況下應該如何面對的方案。

-=end=-

本文主要參閱2017年出版的《盡在雙11：阿里巴巴技術演進與超越》中國工信出版社、電子工業出版社。

并參閱知乎文章：《淘寶系統這么牛，網站系統用的什么框架技術？如何演變的？》