【DevOps Summit焦點】百度貼吧DevOps經驗大公開，撐住每日30

william77

蔚為中國最大社群論壇的百度貼吧（簡稱貼吧），每天訪問次數30億人次，累積13年的貼文數量更達930億則，同時，因應行動裝置的發展，百度開始經營影像直播、電影及遊戲等服務，每天交付至正式環境的程式碼變更高達100次，對於工程團隊也是相當龐大的壓力。

蔚為中國最大社群論壇的百度貼吧（簡稱貼吧），每天訪問次數30億人次、API呼叫百億次，一日新增的貼文有4千萬則，累積13年的貼文數量已經高達930億則，百度資深研發工程師陳建森在今年DevOps Summit大會上透露，必須靠超過1萬臺伺服器，才能應付如此龐大的業務需求。
同時，因應行動裝置的發展，百度開始推出影像直播、電影及遊戲等服務，每天交付至正式環境的程式碼上傳次數，也高達100次，對於工程團隊產生相當大的壓力。貼吧已經從最原始的論壇，變成「功能複雜的產品。」
陳建森表示，為了應付龐大的業務需求，百度在北京、廣州及南京分別架設IDC機房，假如北京機房故障，可以將服務遷移至他處，「對容災、容錯都有幫助。」但只靠硬體建置還不夠，在軟體架構上還得配合才行，陳建森表示，百度採用LNMP架構（Linux、Nginx、MySQL、PHP），將系統拆分為微服務架構（Microservices），服務之間則透過HTTP協定互相溝通。最後，貼吧更將1萬臺伺服器內的系統全部容器化，總共達到5萬個Container的使用規模，而容器化不僅提升部署效率，「也讓系統水平擴展變得更加簡單。」他表示，微服務化也能讓各團隊維運系統的責任分工更明確，「業務開發速度能更快。」
但是，即使大幅導入微服務、Container技術及異地備援等機制，貼吧服務的穩定性仍然是個痛點。在2015年時，貼吧2015年核心服務穩定性為99%，每天出現的系統異常總共超過200次，而精準定位系統故障問題，也往往超過了30分鐘才能恢復正常。
陳建森解釋，因為伺服器規模過於龐大，只要幾臺機器出現異常，就足以讓百度的服務受到影響。再者，由於貼吧論壇的服務越來越龐雜，當系統出現異常狀況時，光是找出問題也相當耗時，只靠工程師「逐一排除異常的作法，還是會讓同樣的問題層出不窮。」百度想辦法找出新的作法才行。
建置線上服務自動保障系統，確保服務維持高可用性
加上貼吧底層子系統超過200套，也分散部署在三地的IDC機房，即使用光纖連線，還是會因距離過遠，而產生傳輸延遲的問題。
所以，為了讓系統更加穩定，百度著手建置線上服務自動保障系統，陳建森解釋，此系統的目標是確保服務維持高可用性，同時，也要讓維運作業盡可能自動化，具備排除系統異常的能力。不只如此，百度還希望打造貫穿兩者的一站式平臺，「讓這樣的系統也能變得更易用。」
而且這套自動保障系統，不只是用來排除故障，也因自動化，所以能快速解決問題，這套系統的設計核心是「在有限資源下，達到最佳的服務品質」，陳建森表示，百度用系統反應時間的數據，來定義這套自動保障系統所要維護的服務品質指標，所以，連帶也解決另一個百度最關心的系統反應時間延遲問題。
針對不同伺服器規模，訂定相異保護策略
陳建森歸納，系統發生異常時，往往從小部分模組開始，進而才擴散到整體架構中，因此，確保服務品質最關鍵的一環就是「確保系統模組的穩定性。」因此，貼吧鎖定了三大方向，藉以落實服務高可用性：資源調度、服務降級，以及過載保護。同時，百度也會針對問題規模大小，來提供不一樣的保護策略。
例如單臺伺服器上，線上系統會分配每個網頁請求的反應時間，萬一某模組回應請求的反應時間過慢、等待時間過長，「該請求會停止，系統會自動降級，確保系統不會發生故障。」同時，由於貼吧採取LNMP架構的設計，團隊也為Nginx、HHVM兩大核心元件，開發遠端程序呼叫（Remote Procedure Call，RPC）負載平衡模組，確保系統的穩定性。
萬一故障從單一伺服器逐漸擴散，進而影響了整體服務品質，貼吧也訂定了不同的對策因應。第一種方式是利用百度異地機房的備援架構，分散單一機房的流量壓力，藉此維持使用者的用戶體驗。
再者，當系統資源不足以應付用戶流量需求時，貼吧則透過頁面快取（pagecache）及業務降級解決。陳建森解釋，貼吧在使用者進行訪問介接層中，實作可水平擴展的Nginx模組，並且在json文件中，告知系統哪些頁面要存入快取。
當使用者的需求得到系統回應時，系統會將請求結果儲存在快取叢集中（cache cluster）。一旦請求失敗、後端系統失靈，Nginx模組則會從快取叢集中，讀取先儲存的內容，並且轉給使用者，「即使後端失靈，我們仍然可以提供服務給用戶」。另外，瀏覽次數較高的頁面，由於儲存快取的頻率高，讀取成功的機率也比較大。
同時，系統也會開始進行服務降級，限縮可以進行訪問的系統模組，降低資源消耗。最後，為避免過載，系統也開始針對異常流量，進行限流管理。
儘管自動化能大量減少異常發生，不過仍無法100%避免，面對龐大的系統，萬一每個系統問題都必須被排除，勢必會浪費大量的人力及時間。因此陳建森表示：「必須精簡問題，不將所有異常列入考慮」，已維持服務穩定性為最高優先。例如，某臺伺服器失靈，但是沒有對服務造成傷害，此時便不需要特別排除其故障問題。
架構革新讓系統異常次數陡降8成
透過一連串的架構革新，陳建森表示，目前，整體服務穩定度達到了99.95％，每天系統異常次數從200次，下降到30次，而定位系統異常的時間從30分鐘，更減少到10分鐘。在百度貼吧的經驗中，陳建森也得出了兩大心得。他表示，如果想要實現自動化，標準化、規範化是關鍵。此外，自動化系統也要能因應技術演進，持續發展，「確保業務不斷發展的同時，自動化系統仍然可繼續沿用。」