Quantcast
Channel: iThome
Viewing all articles
Browse latest Browse all 31433

【DevOps Summit焦點】百度貼吧DevOps經驗大公開,撐住每日30億拜訪次數的關鍵

$
0
0

蔚為中國最大社群論壇的百度貼吧(簡稱貼吧),每天訪問次數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分鐘。在百度貼吧的經驗中,陳建森也得出了兩大心得。他表示,如果想要實現自動化,標準化、規範化是關鍵。此外,自動化系統也要能因應技術演進,持續發展,「確保業務不斷發展的同時,自動化系統仍然可繼續沿用。」


Viewing all articles
Browse latest Browse all 31433

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>