容量預估/規劃及故障演練

  古人云：「知己知彼，百戰百殆」

容量預估

  對於電商大促場景通常都須要進行容量規劃及故障演練。容量規劃，就是經過對複雜業務場景的分析，應用必定的技術手段，如壓力測試、來實現對資源合理擴容、有效規劃的過程。

  對於電商而言，通常的核心鏈路就是交易鏈路，簡易描述就是用戶可以成功登錄、而後能經過瀏覽商品詳情頁進行下單訂購，或者先將意向商品先加入購物車，以後經過購物車進行訂購結算，在這期間會進行各類優惠的價格處理、庫存判斷等，最後還要可以支付成功，這樣一個交易支付流程纔算完成。

 固然，當大促的峯值時刻時，場景又有可能不一樣，由於絕大部分用戶早已將意向商品加入購物車，且各類優惠券也已經申領成功，就等着那個時刻下單了。

以前進行傳統的預測方式通常是在測試環境下，針對場景進行數據模擬，須要開發、測試、運維等人員根據線上的場景，評估可能出現的狀況，這種方式更依賴於人的經驗。經常使用的工具包括Apache Benchmark、LoadRunner（收費）、Jmeter等，這種作法很是不許確，很難模擬出接近prod環境的場景和數據。

    如今中大型的互聯網公司廣泛採用全鏈路壓測的方式，如京東的ForceBot、阿里巴巴的全鏈路壓測平臺（其對應的雲產品PTS，價格仍是蠻貴的）。通常全鏈路壓測平臺在接入層的請求入口進行真實流量複製（如網易開源的TCPCopy），這樣開源簡化模擬數據帶來的成本，將複製的請求引入壓測環境，對壓測環境的服務進行施壓。另外若要加大壓力，開源經過調節TCPCopy的參數，將流量先蓄積（如經過MQ工具）。在DB一側經過影子庫及影子表進行隔離，影子表和生產表創建相同的表結構，經過打tag進行區分，便於隔離刪除。

  通常全鏈路壓測須要注意什麼呢？

  1.找到核心流程。作全鏈路壓測仍是須要巨大的成本，不可能作全，遵循80/20原則，這是壓測的目標

  2.選擇隔離方式。一種是進行環境的獨立隔離，但資源成本高，另外一種是和prod混合，這種方式真實性更高，節省資源，但隔離性很差

  3.縮小依賴服務範圍

故障演練

 提及故障，運維們都想起了背鍋俠，開發及運維同窗都懼怕故障，有的公司雖然制定了應對策略，可是這些策略在沒有測試的狀況下誰也不敢輕易啓動，懼怕引發更嚴重的故障。

  XX互聯網公司由於網絡緣由致使大規模故障，中斷幾個小時，是由於沒有災備嗎？可能不太可能。雖然他們作了災備，可是由於很長時間沒有測試過了，因此不敢切換。故障演練正式爲了解決「不敢切換」的問題。

  另外不是有了故障演練就敢切換，並且還要結合應急預案及應急指揮中心。

  Netflix開源了Chaos Monkey，Chaos Monkey是一個在生產環境隨機選擇並關閉服務的工具。隨後，阿里巴巴也開始進行了故障演練，阿里也有一個故障演練工具，叫：MonkeyKing，爲每一年的雙11 活動作準備，不過如今都基本不維護了，另外阿里也衍生出了ChaosBlade工具,最後集成到阿里云云產品AHAS中，MonkeyKing能夠模擬硬件故障、API故障、分佈式故障、數據庫故障等

   固然故障演練不只開源檢驗業務應用處理失敗的能力，也能夠用戶處理失敗的能力，也能夠用於當故障發生時，如何快速有效地發現並定位故障，通知相應運維人員進行處理，更重要的是，完善咱們的應急預案，避免有相似狀況發生。

最後，容量規劃及故障演練是一件很是重要的事宜，不是一我的承擔，有時須要整個開發團隊、運維團隊、DBA、測試、甚至還有運營團隊/客服/公關等一塊兒參與討論，同時制定應急預案，成立應急指揮中心（例如阿里的全球運行指揮中心GOC）