每到雙11，如何保障系統高峯扛得住、長期平穩是每一個大促人必須面對的問題。在今年雙11以前，阿里雲在上海舉辦了一場線下交流，阿里大促和穩定性保障負責人、中間件專家、解決方案專家等將歷年總結的大促經驗分享給參會嘉賓，咱們選取了其中的精彩內容整理以下。前端
1、互聯網行業穩定性建設的觀察與思考
第一位分享嘉賓是阿里雲華東互聯網團隊的高級解決方案架構師江煵，他擁有十餘年的軟件開發經驗，近些年一直從事雲計算方向的開發和架構工做，主導過多個雲平臺、PaaS平臺的開發建設，對於雲和互聯網架構方面有比較深刻的理解和實踐，目前關注於容器、中間件、Serverless等雲原生的技術方向。數據庫
江煵在分享中提到，今年咱們在新聞裏聽到了不少比較大的宕機事件，宕機的緣由其實都很典型，刪庫跑路、被攻擊、沒有作好容量規劃或者彈性能力不足、系統更改等。宕機後果仍是比較嚴重，好比某SaaS服務商直接經濟損失是兩千多萬，當天市值下跌10億；某新能源車製造商網絡中斷事故當天市值下跌近數百億美圓。股價能漲回來，但對消費者的信心損害、對公司的品牌聲譽的影響等這些很難在短期內消除掉。後端
關於行業的穩定性建設現狀，很多企業穩定性建設上欠的帳仍是不少的，一些偏小且偏傳統的公司，可能都尚未高可用方面的準備。即便是中大型公司，在穩定性建設上仍是存在短板。緩存
穩定性建設相關的工做很難被看到、被承認或客觀評判，不出事故確實有多是運氣，而即便是發生事故，也有可能由於穩定性作的很好且已經避免了十起其餘重大事故。因此須要一些辦法來爲穩定性建設工做作一些定性甚至定量的評估，讓這方面的工做有目標、過程可跟進、結果能檢驗，因此這方面咱們作了一些探索和嘗試。網絡
這裏咱們提出了一個關於穩定性建設成熟度模型的設想，從11個維度，建議了兩種穩定性建設成熟度評估方法：一種是雷達圖模式，經過11個指標的打分，得出來一個總體分數；另外一個是等級模式，每一個指標維度根據建設的完善度給0~4分，咱們但願全部的公司應該至少達到基礎級以上，中大型公司能到發展級，行業頭部公司能到成熟級水平。架構
固然這個成熟度模型自己還不是特別完善，如今提出來給你們參考和探討，將來咱們會持續優化，不光但願給你們合理的評估參考辦法，更但願能對行業總體水位進行分析，讓各家對本身的穩定性建設在行業內的水位有所瞭解，便於制定合理的目標。併發
再給你們快速的介紹一些穩定性建設的一些思路，穩定性工做的本質無外乎是發現風險和消除風險的過程，風險來自於自己系統和產品遺留的潛在風險、長期使用致使的系統腐壞風險、新功能發佈和系統升級引入的風險、大促之類的活動帶來的風險等，咱們的穩定性工做就是讓這些風險可控。less
固然保障還有一大利器就是基於阿里雲的穩定性建設體系，阿里雲提供從資源到方法論全鏈路的穩定性產品和方案，咱們有在行業內排名前列的客戶，僅憑少許的SRE同窗，就能基於阿里雲的各類高可用能力，提供很是高效穩定完善的系統保障。運維
2、電商高可用架構演進和大促保障經驗分享
第二位分享嘉賓是阿里巴巴高可用架構團隊的高級技術專家中亭，他是多活容災&故障演練團隊負責人。2011年加入阿里，2015年擔任雙11負責人，目前負責阿里巴巴經濟體高可用領域的保障及商業化產品的輸出工做。異步
據中亭介紹，目前，高可用領域的技術產品經過兩個雲服務向外輸出，分別是PTS（性能壓測）和AHAS（應用高可用）。在阿里內部，準備一次雙11是一個很是複雜的超級工程，若是業務特別複雜，可能涉及幾十個甚至上百個橫縱型項目。不過從圍繞大促自己這個技術問題，須要解決的問題包括容量、架構、組織等。圍繞這三個問題，中亭介紹了高可用技術的演進歷史和技術選型，並給出了基於雲的高可用解決方案：
1. 阿里全鏈路壓測的完美複製
（1）經過壓測基礎環境改造得到線上生產環境的讀寫壓測能力；
（2）積累壓測基礎數據和業務流量模型經驗，後續可經過購買PTS資源包繼續進行常態化全鏈路壓測；
（3）對於重大活動能夠方便地提早預演，提早準備和應對。
2. 流量防禦
提供業務系統全方位可用性防禦，從網關防禦和應用防禦兩個層面、入口/應用/應用間/單機負載多維度，提高系統的高可用性，包括低成本接入，全方位防禦，多語言版本支持，秒級防禦能力。
3. 異地多活方案
多活解決方案=定製技術產品+諮詢服務+生態夥伴。
- 故障演練
混沌工程的專業技術和方案：遵循混沌工程實驗原理並融合了阿里巴巴內部實踐，提供了豐富故障場景實現，幫助分佈式系統提高容錯性和可恢復性。包括豐富演練庫（基礎資源、應用、雲產品）；場景化演練（強弱依賴、消息、數據庫等）；企業級實踐（紅藍攻防、資損演練等）。
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）快速部署應用，利用定時彈性能力，在活動開始前自動擴容，在活動結束後自動縮容回收資源，實現資源利用最大化，且整個過程無需人工干預。
4、全鏈路壓測最佳實踐經驗分享
第四位分享嘉賓是阿里雲智能解決方案架構師計緣，擁有12年IT領域行業經驗，在能源行業和互聯網ToB行業完整經歷和實踐了SOA架構、微服務架構、雲原生架構的轉型過程 ，對互聯網雲原生架構以及微服務管理、治理、架構高可用優化有着深刻理解，實戰經驗豐富，屢次幫助阿里雲的行業客戶對系統架構完成全面的雲原生改造。
據計緣介紹，大促活動、秒殺活動是最大化流量紅利的不二選擇，可是有不少企業依然享受不到流量紅利，根本緣由只有一個，那就是系統支撐不了大流量的衝擊。主要問題是系統的性能問題大多由不可預知的問題致使。
整個系統從前到後環節很是多，任何一個環節均可能成爲整個系統的瓶頸、短板、約束點。不一樣通信協議，不一樣數據格式，不一樣規範，讓整個分佈式系統架構變得異常複雜。另外，微服務架構下服務調用鏈路南北向和東西向都很是長，單個服務一旦出問題很容易發生「多米諾骨牌」或「雪崩」效應。
如今大多數產品對於用戶而言都是一個入口、一個App，但其實裏面的內容是由多個產品線組合而成的，給客戶呈現的是由很是多個零件協調組織運轉起來的產品。可是實際中，負責不一樣模塊、不一樣產品線的小組有本身的測試團隊，他們只爲某一個模塊或產品線的質量負責，當這些模塊組合起來後，會產生更多由於各類匹配、協做帶來的問題，所謂不能窺一斑而知全豹。這些不肯定的問題給咱們產品的用戶體驗、品牌效應、產品收益帶來巨大的挑戰。
咱們要解決根本的問題，就是要有方案和手段儘量全的識別這些不肯定的因素和問題。一個系統在整個運行的生命週期中無外乎兩個場景，瞬時流量洪峯場景和長期穩態場景。
**
1 . 瞬時流量洪峯場景**
這個場景其實對應的就是大促活動、秒殺活動的場景，咱們能夠在生產環境上作全鏈路壓測，最大限度的模擬用戶的真實流量，不斷施壓摸高，找出系統的性能約束點進行優化；而後反覆這個過程。在這個過程當中有兩個關鍵點，一是流量來源近似用戶真實流量，二是在生產環境上作壓測，這樣等於咱們製造出了真實的大促活動場景，來發現系統的不肯定問題。
2 . 長期穩態場景
將全鏈路壓測的方案固化，經過統一的控制檯，週期性進行故障演練，對版本發佈和配置變動後的質量兜底。因此經過流量洪峯場景來儘量多的識別不肯定因素，經過長期穩態場景常態化監測系統的不肯定因素，而後分析解決不肯定因素，達到對系統穩定性和高可用性的優化。
在施壓方面，阿里雲PTS產品基於全國邊緣節點、CDN模擬各個地域、各個運營商發起流量，能在段時間內發起幾十萬流量，而且能夠動態設置地域和運營商。在PTS的控制檯提供了可視化的方式可讓客戶很方便的建立業務場景，另外還集成了JMeter原生引擎，能夠快捷的導入JMeter腳本，進行壓測工具的無縫遷移。
在流量隔離方面，阿里雲提供無侵入的Agent方式，在不須要對業務系統作代碼改造的同時將流量隔離的能力搭載上去，經過在PTS流量管控控制檯進行接口Mock規則配置、影子表規則配置、壓測數據偏移量配置，來實現Agent對壓測流量和壓測數據的隔離。
總結
阿里巴巴目前已經實現全面雲原生上雲，並經過大規模使用包括容器服務ACK、消息隊列RocketMQ、微服務 EDAS、監控ARMS、性能測試PTS等在內的雲原生產品，得到成本、穩定性和研發運維效率提高的紅利。與此同時，雙11大促的業務場景也成爲阿里云云原生技術與產品優點的錘鍊場，爲阿里雲客戶創造更大價值。
原文連接 本文爲阿里雲原創內容，未經容許不得轉載。