[[200009]]

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

[[200010]]

阿里雙 11 的技術(shù)挑戰(zhàn)

雙 11 技術(shù)挑戰(zhàn)的本質(zhì)是使用有限的成本去實(shí)現(xiàn)***化的用戶體驗(yàn)和集群整體吞吐能力，用最合理的代價(jià)解決零點(diǎn)峰值，支撐好業(yè)務(wù)的狂歡。

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

并且經(jīng)過多年的發(fā)展，雙 11 技術(shù)實(shí)現(xiàn)鏈條中的變量不斷增加，如峰值的增量和系統(tǒng)架構(gòu)的變化、交易峰值的組成、拆單比、每個(gè)業(yè)務(wù)入口的訪問量等，這些變量也給系統(tǒng)帶來了不確定性。

回顧這八年的雙 11 零點(diǎn)之戰(zhàn)，它推動(dòng)了阿里的技術(shù)進(jìn)步、推動(dòng)了架構(gòu)優(yōu)化，加速了技術(shù)演進(jìn)和沉淀。

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

阿里雙 11 高可用架構(gòu)演進(jìn)

能力大促——3.0 分布式架構(gòu)

能力大促***個(gè)要求是解決擴(kuò)展性的問題。上圖是淘寶 3.0 分布式架構(gòu)，其意義在于讓淘寶從一個(gè)集中化應(yīng)用轉(zhuǎn)變?yōu)榉植蓟瘧?yīng)用。

在該架構(gòu)中對(duì)業(yè)務(wù)進(jìn)行了分層，同時(shí)在系統(tǒng)中***使用中間件、分布式調(diào)用、分布式消息、分布式數(shù)據(jù)庫;架構(gòu)底層沉淀了分布式存儲(chǔ)和緩存。

目前而言，大部分互聯(lián)網(wǎng)應(yīng)用都是基于這一架構(gòu)的，并且發(fā)展到現(xiàn)在，該架構(gòu)并無太大的變化。

隨著雙 11 業(yè)務(wù)量的增加，該架構(gòu)面臨著很多挑戰(zhàn)：

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

針對(duì)上述挑戰(zhàn)，我們采用了異地多活方案，具體從四個(gè)方面出發(fā)：首先建設(shè)異地單元機(jī)房，其次由于業(yè)務(wù)中買家維度數(shù)據(jù)遠(yuǎn)多于賣家維度數(shù)據(jù)，且賣家維度數(shù)據(jù)變化并非十分頻繁，因此可以將流量按用戶維度進(jìn)行切分。

此外，由于走向異地***的挑戰(zhàn)是網(wǎng)絡(luò)，為了減少異地調(diào)用的延時(shí)，必須實(shí)現(xiàn)業(yè)務(wù)在本單元的封閉性，減少遠(yuǎn)程調(diào)用，***，由于容災(zāi)的需求，數(shù)據(jù)層實(shí)時(shí)同步，保持最終一致。

異地多活架構(gòu)

上圖是異地多活架構(gòu)，可以看出，從 CDN 到阿里內(nèi)部的接入層都滿足單元化規(guī)則，根據(jù)當(dāng)前用戶的 ID，判斷流量的出口;在下游的層層中間件上以及數(shù)據(jù)寫入存儲(chǔ)時(shí)會(huì)對(duì)用戶請(qǐng)求進(jìn)行判斷，如出現(xiàn)異常，則報(bào)錯(cuò)，防止錯(cuò)誤的數(shù)據(jù)寫入。

賣家的數(shù)據(jù)部署在中心，單元的數(shù)據(jù)會(huì)同步到中心，中心賣家的數(shù)據(jù)也會(huì)同步到各個(gè)單元，但在各個(gè)單元內(nèi)只能對(duì)賣家的數(shù)據(jù)進(jìn)行讀操作。

那么異地多活的到底有什么意義呢?首先異地多活消除了 IDC 資源單點(diǎn)和容量瓶頸，其次解決了異地容災(zāi)問題，業(yè)務(wù)可以秒級(jí)快速切換。

此外，異地多活簡化了容量規(guī)劃，提升了伸縮性和可維護(hù)性。***，通過異地多活解決了可擴(kuò)展性問題，為后續(xù)架構(gòu)演進(jìn)打下堅(jiān)實(shí)基礎(chǔ)。

能力大促——容量規(guī)劃

對(duì)于上文提到的 3.0 架構(gòu)，單機(jī)器的極限能力乘以機(jī)器數(shù)，在下游依賴都充足的情況下，近似等于整個(gè)系統(tǒng)的能力。因此，當(dāng)前做容量規(guī)劃，首先需要評(píng)估應(yīng)用線上單機(jī)極限能力;再根據(jù)公式和經(jīng)驗(yàn)推演容量規(guī)劃。

目前，在阿里內(nèi)部進(jìn)行容量規(guī)劃時(shí)，面臨以下挑戰(zhàn)：

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

壓測方案

為了應(yīng)對(duì)上述挑戰(zhàn)，我們需要從全鏈條的角度出發(fā)進(jìn)行壓測和容量規(guī)劃。全鏈路壓測是在線上集群模擬真實(shí)業(yè)務(wù)流量的讀寫壓測，完成從網(wǎng)絡(luò)、IDC、集群、應(yīng)用、緩存、DB 以及業(yè)務(wù)系統(tǒng)上下游依賴鏈條的容量、性能壓力測試。

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

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

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

通過全鏈路壓測，打破了不可預(yù)知技術(shù)風(fēng)險(xiǎn)的限制，加速技術(shù)進(jìn)化;為新技術(shù)的嘗試和突破做好保底和驗(yàn)收的工作;做到了主動(dòng)發(fā)現(xiàn)問題而不是被動(dòng)等待、應(yīng)急處理;通過新的線上演練，為穩(wěn)定性的確定性打下堅(jiān)實(shí)基礎(chǔ)。

能力大促——限流降級(jí)

限流降級(jí)是能力大促的必要要求。在雙 11 開始前，盡管我們準(zhǔn)備了大量的機(jī)器和能力，然而在雙 11 零點(diǎn)到來時(shí)，真實(shí)業(yè)務(wù)量還是有可能大于我們的預(yù)期。

此時(shí)，為了確保我們的機(jī)器不超負(fù)荷運(yùn)作，我們采用了限流措施，超過機(jī)器極限的業(yè)務(wù)全部拒絕，避免系統(tǒng)因業(yè)務(wù)流量的突然過大而崩潰。

目前，阿里能夠做到從線程數(shù)、請(qǐng)求值、負(fù)載多個(gè)角度進(jìn)行限流，從而保障系統(tǒng)的穩(wěn)定。

分布式應(yīng)用是默認(rèn)下游應(yīng)用是不可靠的，對(duì)于一些弱依賴的請(qǐng)求，應(yīng)該進(jìn)行提前自動(dòng)降級(jí)。至于哪些應(yīng)用需要降級(jí)?需要降級(jí)什么?下游的依賴又是什么?這些問題都是通過依賴治理來解決的。

精細(xì)大促——依賴治理

在阿里內(nèi)部，依賴治理是通過中間件分布式鏈路跟蹤技術(shù)，完成系統(tǒng)架構(gòu)梳理;同時(shí)對(duì)海量調(diào)用鏈進(jìn)行統(tǒng)計(jì)，得到鏈路各個(gè)依賴系統(tǒng)的穩(wěn)定性指標(biāo);此外，結(jié)合業(yè)務(wù)用例識(shí)別強(qiáng)弱依賴，弱依賴可自動(dòng)降級(jí)提供有損服務(wù)。

精細(xì)大促——開關(guān)預(yù)案

精細(xì)化雙 11 控制的首要機(jī)制是開關(guān)預(yù)案。開關(guān)是讓系統(tǒng)切換不同功能表現(xiàn)的標(biāo)準(zhǔn)技術(shù)，可以無需變更代碼只推送配置控制系統(tǒng)行為，讓系統(tǒng)的后門標(biāo)準(zhǔn)化。

開關(guān)中心配置變更可以實(shí)時(shí)下發(fā)到集群，且操作行為對(duì)業(yè)務(wù)而言是原子性的。開關(guān)預(yù)案整合了一批業(yè)務(wù)開關(guān)、限流等操作，將多系統(tǒng)的后臺(tái)操作組裝批量執(zhí)行;實(shí)現(xiàn)了預(yù)案推送是有順序性的，保證業(yè)務(wù)切換的一致性和完整性。

精細(xì)大促——故障演練

統(tǒng)計(jì)學(xué)的數(shù)據(jù)顯示：當(dāng)服務(wù)規(guī)模大于一定數(shù)量時(shí)，硬件故障無法避免。因此，系統(tǒng)要面向失敗做設(shè)計(jì)，測試系統(tǒng)健壯性的***方法，就是不要用正常方式使服務(wù)停機(jī)。對(duì)應(yīng)線上系統(tǒng)，要實(shí)現(xiàn)容災(zāi)，首先需要實(shí)現(xiàn)背后工具體系的容災(zāi)。

由于線上故障是一種常態(tài)，系統(tǒng)負(fù)責(zé)人要具備快速發(fā)現(xiàn)和處理故障的能力，需要實(shí)戰(zhàn)機(jī)會(huì)來成長。另外，跨團(tuán)隊(duì)的流程也是需要加以重視，由于業(yè)務(wù)分布式的特性，出現(xiàn)故障時(shí)需要業(yè)務(wù)系統(tǒng)的上下游共同協(xié)作，這就對(duì)流程提出來嚴(yán)格的要求。

故障演練的實(shí)現(xiàn)方案

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

因此，后期我們對(duì)這一模型又進(jìn)一步抽象，將故障分為進(jìn)程內(nèi)的故障，如代碼死循環(huán)等;進(jìn)程外的故障，如磁盤讀寫速度變慢、網(wǎng)絡(luò)波動(dòng)等;分布式調(diào)用依賴的底層設(shè)施故障，如數(shù)據(jù)庫、緩存或者其他設(shè)施出現(xiàn)故障。

目前，阿里故障演練實(shí)現(xiàn)了業(yè)務(wù)零改造，可插拔式接入;多維度業(yè)務(wù)識(shí)別和故障注入，定量控制演練影響;沉淀通用故障模型，平臺(tái)化輸出演練能力。

從去年雙 11 開始，阿里開始使用線上統(tǒng)一演練環(huán)境，通過邏輯隔離，動(dòng)態(tài)擴(kuò)展邏輯環(huán)境，按需租賃，簡化測試步驟，使得演練結(jié)果更加真實(shí)。

同時(shí)多套環(huán)境互不影響，嚴(yán)格保證環(huán)境的穩(wěn)定和安全;支持用戶、業(yè)務(wù)、數(shù)據(jù)、流量特征的分流和隔離，提高了效率，賦能業(yè)務(wù)創(chuàng)新。

效率大促——流量調(diào)度

在線上集群中，如果個(gè)別機(jī)器發(fā)生故障，為了保證業(yè)務(wù)的整體穩(wěn)定性，需要對(duì)故障點(diǎn)進(jìn)行流量調(diào)度。

流量調(diào)度通過實(shí)時(shí)探測與監(jiān)控分布式環(huán)境中每一臺(tái)機(jī)器的狀況，如果機(jī)器發(fā)生故障，則使用分布式服務(wù)具有的自我隔離和自我修復(fù)能力，使用流量調(diào)度和負(fù)載均衡機(jī)制，通過關(guān)注局部用戶請(qǐng)求和用戶體驗(yàn)，提升整體可用性。

阿里雙 11 未來挑戰(zhàn)

盡管我們已經(jīng)采用了很多措施來保障雙 11 的穩(wěn)定性，但未來，依舊面臨著不少挑戰(zhàn)：

實(shí)現(xiàn)更加精細(xì)化、數(shù)據(jù)化、智能化的雙 11。

從容量確定性到資源確定性，從每個(gè)實(shí)例部署在哪里***、精確到每個(gè)內(nèi)核如何分配***。

更加精準(zhǔn)的分析、預(yù)測流量模型和業(yè)務(wù)模型，實(shí)現(xiàn)預(yù)測、引導(dǎo)相結(jié)合，逼近真實(shí)、增加確定性。

實(shí)現(xiàn)技術(shù)變量的采集、分析、預(yù)測，數(shù)據(jù)分析驅(qū)動(dòng)，自主決策處理，關(guān)鍵技術(shù)指標(biāo)的預(yù)估錯(cuò)誤系統(tǒng)做到自適應(yīng)，彈性處理。

在體驗(yàn)、成本和***吞吐能力方面找到新的平衡點(diǎn)。