[[200009]]

阿里巴巴中間件技術部的高級技術專家周洋(中亭)從能力大促、精細大促和效率大促三個方面探尋雙 11 高可用架構演進之路，并對未來雙 11 的挑戰進行了展望。

[[200010]]

阿里雙 11 的技術挑戰

雙 11 技術挑戰的本質是使用有限的成本去實現***化的用戶體驗和集群整體吞吐能力，用最合理的代價解決零點峰值，支撐好業務的狂歡。

阿里做雙11已經有八年之久了，八年來雙11的交易額增長 200 倍，交易峰值增長 400 多倍，系統復雜度和大促支撐難度以指數級攀升。

并且經過多年的發展，雙 11 技術實現鏈條中的變量不斷增加，如峰值的增量和系統架構的變化、交易峰值的組成、拆單比、每個業務入口的訪問量等，這些變量也給系統帶來了不確定性。

回顧這八年的雙 11 零點之戰，它推動了阿里的技術進步、推動了架構優化，加速了技術演進和沉淀。

阿里的技術演進是一個螺旋向上的過程，整體高可用演進可以分為三個階段：能力大促、精細大促、效率大促，下面來一一分析。

阿里雙 11 高可用架構演進

能力大促——3.0 分布式架構

能力大促***個要求是解決擴展性的問題。上圖是淘寶 3.0 分布式架構，其意義在于讓淘寶從一個集中化應用轉變為分布化應用。

在該架構中對業務進行了分層，同時在系統中***使用中間件、分布式調用、分布式消息、分布式數據庫;架構底層沉淀了分布式存儲和緩存。

目前而言，大部分互聯網應用都是基于這一架構的，并且發展到現在，該架構并無太大的變化。

隨著雙 11 業務量的增加，該架構面臨著很多挑戰：

• 系統的可用性和故障恢復能力，以前集中化架構，出現問題回滾即可;現在由于涉及到眾多分布式系統，快速排查和定位問題變得十分困難。
• 分布式改造之后，單個系統存放在特定機房里，隨著業務發展，機器數目的增加，機房應用層水平伸縮瓶頸、數據庫鏈接等都成了挑戰。
• IDC 資源限制，單個城市已經不足以支撐業務的增長規模。
• 容災問題，單地域 IDC 單點、網絡、臺風、電力等導致高風險。
• 國際化部署需求，可擴展性再次成為瓶頸。

針對上述挑戰，我們采用了異地多活方案，具體從四個方面出發：首先建設異地單元機房，其次由于業務中買家維度數據遠多于賣家維度數據，且賣家維度數據變化并非十分頻繁，因此可以將流量按用戶維度進行切分。

此外，由于走向異地***的挑戰是網絡，為了減少異地調用的延時，必須實現業務在本單元的封閉性，減少遠程調用，***，由于容災的需求，數據層實時同步，保持最終一致。

異地多活架構

上圖是異地多活架構，可以看出，從 CDN 到阿里內部的接入層都滿足單元化規則，根據當前用戶的 ID，判斷流量的出口;在下游的層層中間件上以及數據寫入存儲時會對用戶請求進行判斷，如出現異常，則報錯，防止錯誤的數據寫入。

賣家的數據部署在中心，單元的數據會同步到中心，中心賣家的數據也會同步到各個單元，但在各個單元內只能對賣家的數據進行讀操作。

那么異地多活的到底有什么意義呢?首先異地多活消除了 IDC 資源單點和容量瓶頸，其次解決了異地容災問題，業務可以秒級快速切換。

此外，異地多活簡化了容量規劃，提升了伸縮性和可維護性。***，通過異地多活解決了可擴展性問題，為后續架構演進打下堅實基礎。

能力大促——容量規劃

對于上文提到的 3.0 架構，單機器的極限能力乘以機器數，在下游依賴都充足的情況下，近似等于整個系統的能力。因此，當前做容量規劃，首先需要評估應用線上單機極限能力;再根據公式和經驗推演容量規劃。

目前，在阿里內部進行容量規劃時，面臨以下挑戰：

• 容量規劃的目的是從用戶登錄到完成購買的整個鏈條中，整體資源如何合理分配?
• 500+ 的核心系統、整個技術鏈條長、業務入口多、邏輯復雜。
• 鏈路瓶頸點較多，每年大促峰值都會出現一些問題，無法提前發現。
• 堆積木的容量規劃方法，前面失之毫厘后面謬以千里。
• 在能力評估時應該考慮的是一個處理鏈路而不僅僅是單一的應用。
• 缺乏驗證核心頁面和交易創建鏈條實際承載能力的手段。

壓測方案

為了應對上述挑戰，我們需要從全鏈條的角度出發進行壓測和容量規劃。全鏈路壓測是在線上集群模擬真實業務流量的讀寫壓測，完成從網絡、IDC、集群、應用、緩存、DB 以及業務系統上下游依賴鏈條的容量、性能壓力測試。

整體壓測通過自定義壓測工具，大流量來自機房外部，進而構造線上測試數據，且業務模型接近真實;全鏈路壓測隔離了測試數據和正常數據，兩者之間互不影響，并且全鏈路壓測時是對用戶體驗無感知、無影響的。

全鏈路壓測通過復用中間件的能力，具有超大規模的集群壓測能力，每秒千萬 QPS。同時將壓測引擎部署到全球各地的 CDN 上，實現了分布式部署壓測引擎，按照約定的時間發送壓測數據。

其次，壓測數據是基于線上真實數據進行了脫敏和偏移，數據模型與雙 11 極其接近。此外，實現了線程級隔離，無臟數據，壓力測試直接作用于線上集群，暴露問題更加精準。

通過全鏈路壓測，打破了不可預知技術風險的限制，加速技術進化;為新技術的嘗試和突破做好保底和驗收的工作;做到了主動發現問題而不是被動等待、應急處理;通過新的線上演練，為穩定性的確定性打下堅實基礎。

能力大促——限流降級

限流降級是能力大促的必要要求。在雙 11 開始前，盡管我們準備了大量的機器和能力，然而在雙 11 零點到來時，真實業務量還是有可能大于我們的預期。

此時，為了確保我們的機器不超負荷運作，我們采用了限流措施，超過機器極限的業務全部拒絕，避免系統因業務流量的突然過大而崩潰。

目前，阿里能夠做到從線程數、請求值、負載多個角度進行限流，從而保障系統的穩定。

分布式應用是默認下游應用是不可靠的，對于一些弱依賴的請求，應該進行提前自動降級。至于哪些應用需要降級?需要降級什么?下游的依賴又是什么?這些問題都是通過依賴治理來解決的。

精細大促——依賴治理

在阿里內部，依賴治理是通過中間件分布式鏈路跟蹤技術，完成系統架構梳理;同時對海量調用鏈進行統計，得到鏈路各個依賴系統的穩定性指標;此外，結合業務用例識別強弱依賴，弱依賴可自動降級提供有損服務。

精細大促——開關預案

精細化雙 11 控制的首要機制是開關預案。開關是讓系統切換不同功能表現的標準技術，可以無需變更代碼只推送配置控制系統行為，讓系統的后門標準化。

開關中心配置變更可以實時下發到集群，且操作行為對業務而言是原子性的。開關預案整合了一批業務開關、限流等操作，將多系統的后臺操作組裝批量執行;實現了預案推送是有順序性的，保證業務切換的一致性和完整性。

精細大促——故障演練

統計學的數據顯示：當服務規模大于一定數量時，硬件故障無法避免。因此，系統要面向失敗做設計，測試系統健壯性的***方法，就是不要用正常方式使服務停機。對應線上系統，要實現容災，首先需要實現背后工具體系的容災。

由于線上故障是一種常態，系統負責人要具備快速發現和處理故障的能力，需要實戰機會來成長。另外，跨團隊的流程也是需要加以重視，由于業務分布式的特性，出現故障時需要業務系統的上下游共同協作，這就對流程提出來嚴格的要求。

故障演練的實現方案

前期，我們將阿里電商常見的故障進行畫像和分析，得到初步結論，按照 IaaS、PaaS、SaaS 層進行初步劃分，但這個模型無法完全通用，并非包含所有的故障。

因此，后期我們對這一模型又進一步抽象，將故障分為進程內的故障，如代碼死循環等;進程外的故障，如磁盤讀寫速度變慢、網絡波動等;分布式調用依賴的底層設施故障，如數據庫、緩存或者其他設施出現故障。

目前，阿里故障演練實現了業務零改造，可插拔式接入;多維度業務識別和故障注入，定量控制演練影響;沉淀通用故障模型，平臺化輸出演練能力。

從去年雙 11 開始，阿里開始使用線上統一演練環境，通過邏輯隔離，動態擴展邏輯環境，按需租賃，簡化測試步驟，使得演練結果更加真實。

同時多套環境互不影響，嚴格保證環境的穩定和安全;支持用戶、業務、數據、流量特征的分流和隔離，提高了效率，賦能業務創新。

效率大促——流量調度

在線上集群中，如果個別機器發生故障，為了保證業務的整體穩定性，需要對故障點進行流量調度。

流量調度通過實時探測與監控分布式環境中每一臺機器的狀況，如果機器發生故障，則使用分布式服務具有的自我隔離和自我修復能力，使用流量調度和負載均衡機制，通過關注局部用戶請求和用戶體驗，提升整體可用性。

阿里雙 11 未來挑戰

盡管我們已經采用了很多措施來保障雙 11 的穩定性，但未來，依舊面臨著不少挑戰：

實現更加精細化、數據化、智能化的雙 11。

從容量確定性到資源確定性，從每個實例部署在哪里***、精確到每個內核如何分配***。

更加精準的分析、預測流量模型和業務模型，實現預測、引導相結合，逼近真實、增加確定性。

實現技術變量的采集、分析、預測，數據分析驅動，自主決策處理，關鍵技術指標的預估錯誤系統做到自適應，彈性處理。

在體驗、成本和***吞吐能力方面找到新的平衡點。