大促場景系統穩定性保障實踐經驗總結

簡介：

11月11日0點剛過26秒，天貓雙11的訂單建立峰值就達到58。3萬筆/秒，阿里雲又一次扛住全球最大規模流量洪峰！58。3萬筆/秒，這一數字是2009年第一次天貓雙11的1457倍。

每到雙11，如何保障系統高峰扛得住、長期平穩是每個大促人必須面對的問題。在今年雙11之前，阿里雲在上海舉辦了一場線下交流，阿里大促和穩定性保障負責人、中介軟體專家、解決方案專家等將歷年總結的大促經驗分享給參會嘉賓，我們選取了其中的精彩內容整理如下。

一、網際網路行業穩定性建設的觀察與思考

第一位分享嘉賓是阿里雲華東網際網路團隊的高階解決方案架構師江煵，他擁有十餘年的軟體開發經驗，近些年一直從事雲計算方向的開發和架構工作，主導過多個雲平臺、PaaS平臺的開發建設，對於雲和網際網路架構方面有比較深入的理解和實踐，目前關注於容器、中介軟體、Serverless等雲原生的技術方向。

江煵在分享中提到，今年我們在新聞裡聽到了很多比較大的宕機事件，宕機的原因其實都很典型，刪庫跑路、被攻擊、沒有做好容量規劃或者彈效能力不足、系統更改等。宕機後果還是比較嚴重，比如某SaaS服務商直接經濟損失是兩千多萬，當天市值下跌10億；某新能源車製造商網路中斷事故當天市值下跌近數百億美元。股價能漲回來，但對消費者的信心損害、對公司的品牌聲譽的影響等這些很難在短時間內消除掉。

關於行業的穩定性建設現狀，不少企業穩定性建設上欠的賬還是很多的，一些偏小且偏傳統的公司，可能都還沒有高可用方面的準備。即使是中大型公司，在穩定性建設上還是存在短板。

穩定性建設相關的工作很難被看到、被認可或客觀評判，不出事故確實有可能是運氣，而即使是發生事故，也有可能因為穩定性做的很好且已經避免了十起其他重大事故。所以需要一些辦法來為穩定性建設工作做一些定性甚至定量的評估，讓這方面的工作有目標、過程可跟進、結果能檢驗，所以這方面我們做了一些探索和嘗試。

這裡我們提出了一個關於穩定性建設成熟度模型的設想，從11個維度，建議了兩種穩定性建設成熟度評估方法：一種是雷達圖模式，透過11個指標的打分，得出來一個整體分數；另一個是等級模式，每個指標維度根據建設的完善度給0~4分，我們希望所有的公司應該至少達到基礎級以上，中大型公司能到發展級，行業頭部公司能到成熟級水平。

當然這個成熟度模型本身還不是特別完善，現在提出來給大家參考和探討，未來我們會持續最佳化，不光希望給大家合理的評估參考辦法，更希望能對行業整體水位進行分析，讓各家對自己的穩定性建設在行業內的水位有所瞭解，便於制定合理的目標。

再給大家快速的介紹一些穩定性建設的一些思路，穩定性工作的本質無外乎是發現風險和消除風險的過程，風險來自於本身系統和產品遺留的潛在風險、長期使用導致的系統腐壞風險、新功能釋出和系統升級引入的風險、大促之類的活動帶來的風險等，我們的穩定性工作就是讓這些風險可控。

當然保障還有一大利器就是基於阿里雲的穩定性建設體系，阿里雲提供從資源到方法論全鏈路的穩定性產品和方案，我們有在行業內排名前列的客戶，僅憑少量的SRE同學，就能基於阿里雲的各種高可用能力，提供非常高效穩定完善的系統保障。

二、電商高可用架構演進和大促保障經驗分享

第二位分享嘉賓是阿里巴巴高可用架構團隊的高階技術專家中亭，他是多活容災&故障演練團隊負責人。2011年加入阿里，2015年擔任雙11負責人，目前負責阿里巴巴經濟體高可用領域的保障及商業化產品的輸出工作。

據中亭介紹，目前，高可用領域的技術產品透過兩個雲服務向外輸出，分別是PTS（效能壓測）和AHAS（應用高可用）。在阿里內部，準備一次雙11是一個非常複雜的超級工程，如果業務特別複雜，可能涉及幾十個甚至上百個橫縱型專案。不過從圍繞大促本身這個技術問題，需要解決的問題包括容量、架構、組織等。圍繞這三個問題，中亭介紹了高可用技術的演進歷史和技術選型，並給出了基於雲的高可用解決方案：

1. 阿里全鏈路壓測的完美複製

（1）透過壓測基礎環境改造獲得線上生產環境的讀寫壓測能力；

（2）積累壓測基礎資料和業務流量模型經驗，後續可透過購買PTS資源包繼續進行常態化全鏈路壓測；

（3）對於重大活動可以方便地提前預演，提前準備和應對。

2. 流量防護

提供業務系統全方位可用性防護，從閘道器防護和應用防護兩個層面、入口/應用/應用間/單機負載多維度，提升系統的高可用性，包括低成本接入，全方位防護，多語言版本支援，秒級防護能力。

3. 異地多活方案

多活解決方案=定製技術產品+諮詢服務+生態夥伴。

故障演練

混沌工程的專業技術和方案：遵循混沌工程實驗原理並融合了阿里巴巴內部實踐，提供了豐富故障場景實現，幫助分散式系統提升容錯性和可恢復性。包括豐富演練庫（基礎資源、應用、雲產品）；場景化演練（強弱依賴、訊息、資料庫等）；企業級實踐（紅藍攻防、資損演練等）。

三、秒殺最佳實踐和解決方案

第三位分享嘉賓是阿里雲智慧解決方案架構師鹿玄，他經歷過大型分散式系統的開發和維護，並在雲計算、雲原生等領域有多年從業經驗，對系統架構選型，問題排查和效能調優有著豐富的實戰經驗，致力於透過雲原生架構轉型來幫助阿里雲各行業客戶實現業務價值。

首先我們來看秒殺業務流程，流程比較簡單，一般就是下訂單減庫存：

秒殺系統的設計原則包括以下幾點：

1 . 熱點識別

透過營銷活動，賣家單獨報名等方式，提前收集資訊。

2 . 隔離原則

在前端頁面、應用層、資料層做好隔離。

3 . 將請求儘量攔截在系統上游。

傳統秒殺系統之所以掛，請求都壓到了後端資料層，資料讀寫鎖衝突嚴重，併發高響應慢，幾乎所有請求都超時，流量雖大，下單成功的有效流量甚小，比如某種商品只有1000的庫存，100w個人來買，實際上絕大部分的請求有效率為0。

4 . 讀多寫少的場景使用快取

秒殺是一個典型的讀多寫少的應用場景，比如某種商品只有1000的庫存，100w個人來買，最多1000個人下單成功，其他人都是查詢庫存，寫比例只有0。1%，讀比例佔99。9%，非常適合使用快取。

在秒殺場景中，從架構層面需要考慮的事情有以下幾點：

1 . 庫存快取

Redis作為大促期間庫存扣減的主要承擔方。商品ID作為Redis的KEY，將可用庫存=（總庫存-暫扣庫存）值作為Value。利用LUA指令碼的事務特性實現在Redis中“讀剩餘庫存後扣減”的邏輯

2 . 容量規劃

使用阿里雲效能測試工具PTS，模擬真實使用者請求，驗證全國使用者真實業務操作對服務端效能、容量和系統穩定性的影響，確保重大活動平穩支撐。

3 . 效能調優

利用ARMS提供的立體式監控能力，在壓測過程中實時監控應用及物理機各項指標，快速幫助開發人員定位排查問題，提升系統性能。

4 . 限流防刷

使用阿里雲應用高可用服務（AHAS） 實現限流降級，確保系統不被預期外的突發流量打掛。同時可配置熱點規則，超過一定量的閾值後，系統會讓購買熱點商品的流量排隊等待。例如購買同一商品，1s內呼叫超過100次請求後，則其餘請求進行等待

5 . 非同步解耦，削峰填谷

訊息佇列 RocketMQ 版是阿里雲基於 Apache RocketMQ 構建的低延遲、高併發、高可用、高可靠的分散式訊息中介軟體。訊息佇列 RocketMQ 版既可為分散式應用系統提供非同步解耦和削峰填谷的能力，同時也具備網際網路應用所需的海量訊息堆積、高吞吐、可靠重試等特性

6 . 彈效能力

對於有周期性促銷活動的使用者，可以使用Serverless 應用引擎（SAE）快速部署應用，利用定時彈效能力，在活動開始前自動擴容，在活動結束後自動縮容回收資源，實現資源利用最大化，且整個過程無需人工干預。

四、全鏈路壓測最佳實踐經驗分享

第四位分享嘉賓是阿里雲智慧解決方案架構師計緣，擁有12年IT領域行業經驗，在能源行業和網際網路ToB行業完整經歷和實踐了SOA架構、微服務架構、雲原生架構的轉型過程 ，對網際網路雲原生架構以及微服務管理、治理、架構高可用最佳化有著深入理解，實戰經驗豐富，多次幫助阿里雲的行業客戶對系統架構完成全面的雲原生改造。

據計緣介紹，大促活動、秒殺活動是最大化流量紅利的不二選擇，但是有很多企業依然享受不到流量紅利，根本原因只有一個，那就是系統支撐不了大流量的衝擊。主要問題是系統的效能問題大多由不可預知的問題導致。

整個系統從前到後環節非常多，任何一個環節都可能成為整個系統的瓶頸、短板、約束點。不同通訊協議，不同資料格式，不同規範，讓整個分散式系統架構變得異常複雜。另外，微服務架構下服務呼叫鏈路南北向和東西向都非常長，單個服務一旦出問題很容易發生“多米諾骨牌”或“雪崩”效應。

現在大多數產品對於使用者而言都是一個入口、一個App，但其實裡面的內容是由多個產品線組合而成的，給客戶呈現的是由非常多個零件協調組織運轉起來的產品。但是實際中，負責不同模組、不同產品線的小組有自己的測試團隊，他們只為某一個模組或產品線的質量負責，當這些模組組合起來後，會產生更多因為各種匹配、協作帶來的問題，所謂不能窺一斑而知全豹。這些不確定的問題給我們產品的使用者體驗、品牌效應、產品收益帶來巨大的挑戰。

我們要解決根本的問題，就是要有方案和手段儘可能全的識別這些不確定的因素和問題。一個系統在整個執行的生命週期中無外乎兩個場景，瞬時流量洪峰場景和長期穩態場景。

1 . 瞬時流量洪峰場景

這個場景其實對應的就是大促活動、秒殺活動的場景，我們可以在生產環境上做全鏈路壓測，最大限度的模擬使用者的真實流量，不斷施壓摸高，找出系統的效能約束點進行最佳化；然後反覆這個過程。在這個過程中有兩個關鍵點，一是流量來源近似使用者真實流量，二是在生產環境上做壓測，這樣等於我們製造出了真實的大促活動場景，來發現系統的不確定問題。

2 . 長期穩態場景

將全鏈路壓測的方案固化，透過統一的控制檯，週期性進行故障演練，對版本釋出和配置變更後的質量兜底。所以透過流量洪峰場景來儘可能多的識別不確定因素，透過長期穩態場景常態化監測系統的不確定因素，然後分析解決不確定因素，達到對系統穩定性和高可用性的最佳化。

在施壓方面，阿里雲PTS產品基於全國邊緣節點、CDN模擬各個地域、各個運營商發起流量，能在段時間內發起幾十萬流量，並且可以動態設定地域和運營商。在PTS的控制檯提供了視覺化的方式可以讓客戶很方便的建立業務場景，另外還集成了JMeter原生引擎，可以快捷的匯入JMeter指令碼，進行壓測工具的無縫遷移。

在流量隔離方面，阿里雲提供無侵入的Agent方式，在不需要對業務系統做程式碼改造的同時將流量隔離的能力搭載上去，透過在PTS流量管控控制檯進行介面Mock規則配置、影子表規則配置、壓測資料偏移量配置，來實現Agent對壓測流量和壓測資料的隔離。

總結

阿里巴巴目前已經實現全面雲原生上雲，並透過大規模使用包括容器服務ACK、訊息佇列RocketMQ、微服務 EDAS、監控ARMS、效能測試PTS等在內的雲原生產品，獲得成本、穩定性和研發運維效率提升的紅利。與此同時，雙11大促的業務場景也成為阿里云云原生技術與產品優勢的錘鍊場，為阿里雲客戶創造更大價值。

作者：中介軟體小哥

原文連結