雙十二的時候咱們的一個重要業務崩盤了。api
緣由其實很簡單,就一句話,流程太大致使某個中間件接入層的HA proxy滿載,中間件不可用,整個業務基本癱瘓。架構
從測試的角度去總結一下,大概之後能夠有以下的改進。併發
咱們此次的事故是由於比較樂觀,可能技術方案評審的時候就開始盲目樂觀了。負載均衡
其實流量增加的速度有多是咱們難以去精確預估的,因此技術架構設計的時候咱們就要提早準備。高併發
對於測試同窗來講,你們能夠簡單記住下面一些要點。測試
降級。在大流量的狀況下,是否能經過一些機制讓服務降級,從而保護整個系統的穩定性。舉個例子,可能通常狀況下,用戶購買商品下一個訂單就能夠立刻看到訂單的詳情,可是在秒殺場景中,用戶可能在下單很長時間以後才能看到訂單,這就是一種服務降級的表現。架構設計
削峯。把流量的高峯削平,不讓突如其來的大流量對系統產生破壞性的影響。舉個例子,12306搶票的時間點是分散的,大概每一個小時搶一次,這就防止了一次性放出全部票致使全部用戶同時搶票帶來的流量高峯,這是一種業務上的削峯。設計
限流。這個很好理解。一些第三方api會限制每分鐘調用的次數就是這個道理。中間件
熔斷。高併發時,若是一些api沒法訪問後,能不能自動不去訪問這些有故障的api,從而保證主流程的順暢和穩定。容器
故障摘除。一些容器若是被擊垮,能不能動態去摘除這些節點,從而保證整個系統可用。
事故以前,咱們其實對整個架構能支撐的容量作了計算,結論是在當前架構下是能夠撐住雙12的峯值的。可是千算萬算卻沒想到中間件在接入層以前有HA作負載均衡。這個ha其實是單點,容量有限,若是提早了解該架構,而且進行擴容的話,事故大概也不會發生。
測試同窗在看架構的時候能夠先無腦關注單點問題。某個服務或中間件是否是單點?若是是,那麼單點掛掉以後對整個系統可用性會不會形成影響?搞清楚這個問題的答案對系統高可用很是關鍵。
問題總會有可能發生的,所以提早準備好預案很是重要。
此次事故發生以前,咱們並無準備應急預案,所以,當臨時發現了沒法動態擴容的HA單點時,咱們基本上只能眼睜睜的看着系統掛掉,什麼事情都作不了。
動態擴容屬於亡羊補牢,在問題發生時候的那幾秒,擴容每每是沒法迅速完成的,所以提早計算好容量纔是關鍵。
最後,下次的活動是在明年的雙十一,嗯,這個鍋要背一年了。
慚愧,慚愧。