每分鐘訪問10w+，11種策略教你保持億級流量網站穩定性！

穩定性在大型網站執行中至關重要，面對每分鐘 10 萬次的網路訪問，稍有不慎就會引起重大故障。今天這篇文章一起討論下億級流量網站在穩定性方面的一些做法，希望對您有幫助。

一、基礎策略

1.1、配置化

配置化就是把很多業務流程相關的資料統一放在一個配置平臺上，從程式碼中抽離出來，使得程式碼僅處理通用的業務邏輯。配置化之後，程式碼擁有處理所有場景的能力，通過配置資料來決定線上執行時具體操作什麼樣的資料。

配置化的設計使得我們能夠對線上進行快速更改，做到實時的增加、變更和刪除，對於快速處理問題有很好的效果。

1.2、業務開關

業務開關就是針對具體一個流程的開關，通過開關的開啟和關閉可以實時控制處理邏輯。開關可以有多種型別，常用的有以下幾種。

Boolean 型別：是否使能某個流程，如開啟和關閉某個校驗；

Number 型別：業務對應的數字配置；

String 型別：業務對應的文字配置；

Collection 型別：業務對應的集合開關，如指定特定型別的業務啟動或關閉流程；

Map 型別：業務對應的對映開關，如指定特定型別的業務進行特定型別的處理。

1.3、部署策略

面對每分鐘達 10 萬次的訪問流量，系統的部署是個很大的挑戰。我們採用按機房、按機器分組進行分批次的部署策略，也就是在部署過程中，新版本與老版本共存，同時提供服務，整個的部署過程是一個逐步替換的過程。

灰度部署逐步提高新版本在服務中的比例，分流線上使用者進行灰度測試。如果發現機器日誌有異常或有使用者反饋服務問題，可以第一時間進行新版本回滾，避免產生更大範圍的影響。

1.4、錯誤處理

在軟體架構中要對錯誤處理有一套統一的流程和規範，對錯誤碼進行分類處理，做到根據統計到的錯誤碼能夠快速判斷錯誤型別。要做到這一點，錯誤碼需要約定好統一的格式，比如 CHK 開頭表示校驗失敗、THD 開頭表示第三方服務錯誤、SYS 表示當前系統錯誤，REQUIRED 結尾表示必填項未填、INVALID 結尾表示資料錯誤、EXCEPTION 結尾則表示出現異常。

1.5、日誌收集

程式執行一定會產生日誌，日誌是排查線上問題的第一手原始資料。準確完整地記錄下有意義的日誌，才能進行有效的分析。比如基於日誌，我們可以統計服務呼叫量並分析成功率，可以明確地看到錯誤資訊，包括哪些使用者出錯、出錯的原因是什麼，並可以建立線上問題報警機制。

日誌需要按照統一的格式列印，儲存在一個統一的日誌分析服務中，做到實時記錄、實時搜尋。

二、線上監控策略

2.1、鏈路跟蹤

分散式系統的一個難題，就是如何跟蹤處理鏈路。通常情況下，我們會在鏈路的起點為每一個請求生成一個唯一識別碼，比如 UUID，並在以後的每一個處理節點都記錄下識別碼並傳播給下一個處理節點。

基於這樣的唯一識別碼，我們可以從海量日誌中完整地還原出一個請求在鏈路上的處理過程，以及輸入輸出資料，進行全鏈路分析。

2.2、異常監控

對 Java 丟擲的異常進行處理，列印到日誌中，可以建立起異常監控。在異常監控中，我們重點關注異常發生的次數、棧資訊、變化趨勢。

通過異常監控，可以快速定位線上問題，直接根據棧資訊找到異常發生的地點。如果是第三方服務的異常，比如分散式呼叫超時，也能夠快速分析並定位。

2.3、機器監控

機器監控則是重點關注機器的 CPU、記憶體、網路使用情況，JVM 的執行緒數量、記憶體使用、Full GC 次數等。流量洪峰到來時，伺服器承壓，很可能出現 CPU、記憶體不足等情況，也可能導致 JVM 記憶體不足進行 Full GC，進而引起服務崩潰。伺服器執行狀況如此重要，不能不重視。

三、面對流量洪峰的策略

3.1、服務降級

服務降級是指在特定情況下，比如雙十一、雙十二期間，當流量超過系統服務能力時，跳過特定的處理流程。比如在一個賣家下單後，我們可能需要進行風險評估、資料校驗等一系列流程，當發生服務降級時，就跳過了資料校驗邏輯，來保證服務的穩定性。

服務降級是面對流量洪峰保證使用者體驗和預防系統崩潰的有效手段。比如圖片內容的校驗通常都是比較耗時的操作，面對流量洪峰取消這樣的校驗可以避免使用者的長時間等待、降低對下游鏈路的衝擊，確保服務穩定。

3.2、服務限流

服務限流是指，根據服務的處理能力提前預估出一個閾值，當流量大於該閾值時直接放棄處理直接返回錯誤。服務限流是應對流量峰值時，系統進行自我保護的重要措施。比如雙十一零點下單峰值、餘額寶九點搶購峰值、活動結束商品編輯峰值，都需要進行相應的限流來保護系統。

在分散式部署中，基於 dubbo、Spring cloud 或 HSF 的資料統計功能，很容易推算出系統平時的流量壓力。藉助於全鏈路壓測，可以很容易看到系統在流量峰值下的具體表現。因此，服務限流的實施並不困難。

3.3、故障容災

單機系統的容災能力幾乎為零，一旦服務崩潰就馬上變成不可用。分散式系統通過服務多活，可以不間斷提供服務；藉助於 nginx、Apache 進行負載均衡可以進一步提高可用性。

實際上，即便進行了負載均衡和服務分散式部署，系統仍然面臨容災問題。現在的大型服務，比如淘寶、天貓、微信、京東都進行了異地多活的部署。異地多活部署的主要目的，在於通過多機房提供服務，來降低單機房故障帶來的影響，提高容災能力。

四、總結

這篇文章大概整理了一個億級流量網站在穩定性方面需要注意和做好的點，關於穩定性還有很多問題值得探討和深思。

歡迎工作一到五年的Java工程師朋友們加入Java填坑之路：860113481

群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用”沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！