大促场景系统稳定性保障实践经验分享
每到雙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大促的業務場景也成為阿里云云原生技術與產品優勢的錘煉場，為阿里云客戶創造更大價值。
阿里云專門成立了“互聯網架構升級實戰課”釘釘群，每周邀請一位阿里云專家在群內進行行業最佳實踐直播，每天分享行業前沿干貨，歡迎掃碼或釘釘搜索群號加入：35712134。
原文鏈接：https://developer.aliyun.com/article/778248?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的大促场景系统稳定性保障实践经验分享的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 玩转ECS第5讲 | 弹性计算安全组最佳
- 下一篇： 玩转ECS第6讲 | 弹性计算Regio