每年一次的雙十一大促臨近，因此上周末公司組織了一次技術交流閉門會，邀請了電商、物流、文娛內容、生活服務等知名一線互聯網公司的技術大牛，一起探討了一些大促穩定性保障相關的技術話題。
我作為會議主持人，也和這些技術大牛交流了很多案例經驗，從他們身上汲取了很多新的思路和技術實踐。我將其中一些比較干貨的技術實踐案例整理了出來，供大家學習參考下。
PS：出於脫敏原因，部分內容我已經做了處理，但不影響閱讀。
大促典型場景及優化方案
1、雲資源穩定性保障
-
單雲模式存在一定穩定性風險，混合雲架構在容災方面效果更好；
-
核心鏈路梳理，可以將歷史大促或者峰值的訪問URL存儲起來，經過處理后作為核心鏈路參考；
-
驗證線上的性能容量搭建單獨的仿真環境，為了避免和線上不一致，可通過一套標准的腳本來進行檢查配置；
-
彈性伸縮容：設置動態擴縮容，超過固定的比例閾值，進行動態擴容（雙十一零點峰值時候慎用）；
-
雲資源保障方面，和雲廠商提前溝通，盡可能將沒有大促業務的公司服務器資源和自己公司放在同一個可用區或機房，避免資源共享&競爭導致的問題，同時邀請雲廠商駐場保障也是很有必要的；
2、電商場景的性能優化實踐
1）應用優化
-
火焰圖、鏈路追蹤分析是很好的問題分析助力工具；
-
利用監控，Arthas等工具探測鏈路在哪個方法/代碼塊耗時大，不斷壓測優化驗證；
2）業務優化(深庫存場景)
-
為了應對秒殺場景高並發，可以通過緩存+數據庫方式來解決；
-
90%庫存放緩存應對高並發；
-
10%庫存放數據庫應對超賣；
3）數據庫優化(深庫存場景)
-
阿里雲RDS有針對庫存更新的patch，可以到3000/s；
3、數據庫穩定性保障的SOP
- 數據庫的可用性底線：99.99%；
- 故障需要有嚴格的定義規則；
- 數據庫穩定性三板斧：
1）擴容：DB是有狀態服務，計算層便於擴容，將DB節點放到容器中，有需要擴容；
2）災備：對於大流量讀場景可通過流量切換方式，將部分流量遷移到備份集群分流；
3）巡檢：慢SQL是常見的問題，可通過自動監控和歷史數據分析，提供輔助式決策；
線上監控告警及容災預案
1、如何做好監控告警？
-
關鍵路徑收集；
-
容量指標限制；
2、除了基礎監控，還有哪些關鍵監控指標？
-
線程池監控；
-
預估指標-容量規划；
3、分布式集群架構，單節點對整體的影響是什么？
-
單節點可能是關鍵節點，少量報錯很難被發現，需要單點監控分析；
-
單節點出現問題可以T下線，通過日志等手段進行報錯分析，保留現場；
4、除了基礎監控，服務層會做哪些監控相關的事項？
-
數據庫層也需要做好監控；
-
比較好的實踐是雙機熱備，在數據同步方面需要有專門的保障機制；
5、高並發下，MySQL主備同步會有較大延遲，該如何處理？
-
采用MySQL的並行復制+寫操作不刷盤方式；
-
非交易業務的查詢放在備庫，降低主庫壓力；
-
梳理落地SOP機制，遇到問題時首先快速線上止血，解決故障；
-
存在主備延遲情況，可以開啟參數調整方式來處理(臨時開啟，快啟快關) ；
-
同城雙活架構下，可通過定時任務的方式自動檢測MySQL的雙0模式，定時改寫數據；
-
高並發下MySQL主庫往往寫壓力比較大，事務日志和binlog IO比較頻繁，導致備庫拉取binlog比較卡，較好的方式是通過降級延時方式做數據同步，保證最終數據一致性；
服務保護手段：限流降級熔斷隔離
限流
-
限流的目的是控制訪問應用的流量在系統承載范圍內；
-
在業務請求入口（網關）限流，避免內部互相調用放大流量；
-
限流是個演進狀態，從連接池、IP、指定SQL到更細的層級粒度做限流；
-
每個調用層都做限流，每個應用先保證自己可用，對其他依賴調用要做到“零信任”；
降級
- 降級：強依賴可以通過熔斷的方式做緊急處理，弱依賴提前主動降級；
- 預案：分為主動預案和緊急預案：
1）主動預案：提前進行風險識別，然后針對性的方案，可以降低已知的風險；
2）緊急預案：假設出現重大的問題，才需要決策是否啟用的方案（風險較大）；
3）預案平台：預案平台的目的是留痕，方便后續把預案恢復回來；
熔斷
- 熔斷下游強依賴的服務；
- 大促四板斧：關停並轉。
1）雙十一零點的前半小時， 做一個動態推送，把日志關掉；
2）真正流量來的時候，留一台機器來觀察錯誤和異常的日志；
隔離
- 隔離：核心業務和非核心業務做隔離；
- 身份識別和業務隔離：
1）RPC group分組：假設有100個節點，40個給核心業務(交易)，60個給其他業務；
2）業務身份：中台架構可通過業務身份把訂單秒殺等應用打上標記，便於隔離區分；
業務穩定性保障
-
涉及到交易訂單&優惠券等和錢有關場景，線上造特殊數據進行實時定制化校驗對賬；