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