每年一次的雙十一大促臨近，是以上周末公司組織了一次技術交流閉門會，邀請了電商、物流、文娛内容、生活服務等知名一線網際網路公司的技術大牛，一起探讨了一些大促穩定性保障相關的技術話題。
我作為會議主持人，也和這些技術大牛交流了很多案例經驗，從他們身上汲取了很多新的思路和技術實踐。我将其中一些比較幹貨的技術實踐案例整理了出來，供大家學習參考下。
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）業務身份：中台架構可通過業務身份把訂單秒殺等應用打上标記，便于隔離區分；
業務穩定性保障
- 涉及到交易訂單&優惠券等和錢有關場景，線上造特殊資料進行實時定制化校驗對賬；
轉載請注明出處，商用請征得作者本人同意，謝謝！！！