多多色-多人伦交性欧美在线观看-多人伦精品一区二区三区视频-多色视频-免费黄色视屏网站-免费黄色在线

國內最全IT社區平臺 聯系我們 | 收藏本站
阿里云優惠2
您當前位置:首頁 > 互聯網 > 日800萬訪客、20萬RPS網站的5個9可用性架構

日800萬訪客、20萬RPS網站的5個9可用性架構

來源:程序員人生   發布時間:2014-09-06 13:40:05 閱讀次數:2780次

【編者按】AOL.com,American Online(美國在線),美國著名的新聞聚合網站,也是美國最大的互聯網服務提供商之一。當下,AOL.com的天訪問人次已超過800萬,月PV更達10億之巨。近日,Lead Squirrel創始人、AOL架構師兼工程團隊負責人、擁有10年架構經驗的Dave Hagler在HighScalability上撰文分享了AOL高可用性(99.999%)網站架構,以下為譯文:


CSDN推薦:歡迎免費訂閱《Hadoop與大數據周刊》獲取更多Hadoop技術文獻、大數據技術分析、企業實戰經驗,生態圈發展趨勢。


當下,AOL.com的架構已發展到第五代,也可以說是20年內重建了5次;現在使用的架構是在6年前設計,雖然整體保持不變,但組件的更新和添加卻從未停止。在6年的持續改進過程中,代碼、工具、開發、部署等環節都得到了充分的調優,也讓AOL.com在當下的數據洪流中屹立不倒。

AOL.com工程團隊一直保持在25人左右,包括了開發、測試及運維人員,公司的主要工作地點在Dulles和Virginia,也有一小部分在Dublin及Ireland。應對如此流量并將可用性保持在5個9從來都不是件容易的事情,在系統架構中我們使用了多種技術:Java、JavaServer Pages、Tomcat、Apache、CentOS、Git、Jenkins、Selenium和 jQuery等。

設計原則

關于架構的設計我們有著明確的思路,其中最重要的就是冗余一切,在系統中某個部分發生故障,或者需要離線維護時,有個備份無疑省時省力,而5個9的可用率要求每年不超過5分鐘宕機時間。

第二個原則就是AOL.com不能依賴任何共享基礎設施去交付頁面,即使某個系統或內容發生故障,AOL.com仍然需要維持著高可用。在這個架構設計后不久,AOL大部分的網絡內容都共享一個被稱為Big Bowl的基礎設施,這樣會存在一個非常致命的問題――不同內容之間的相互影響。為了解決這個問題,當下的AOL專門設計了不同內容之間的隔離,任何依賴AOL.com的內容都會被一個保護服務前移至一組更少的主機上,保護服務負責將調用聚集到下游系統。因此,取代從上萬個服務器上接收請求,下游系統可能只會從20個不同的服務器上獲取請求,響應同樣會被緩存來減少負載。同時,運維團隊還會對AOL.com備份外部數據庫。這樣一來,在整個系統中只有網絡和協議服務被共享。

物理基礎設施

AOL.com部署在3個不同的數據中心,兩個在Northern Virginia,一個在California,這些數據中心都由公司自主運營。雖然每個數據中心的規模都足以支撐整個AOL.com,但是AOL.com仍然堅持同時運行這三個數據中心,多冗余讓數據中心的離線維護變得簡單。

當請求接入時,負責跨數據中心負載均衡的Akamai GSLB將為用戶指向離他最近的數據中心。為靜態內容使用了Akamai CDN,一旦確定某個數據中心,進一部的請求(數據庫或者是服務)都會傳入這個數據中心。用戶的會話信息會保存在cookies里,并通過請求發送;因為不需要保存狀態,所以請求可以在任何服務器上被執行。


在數據中心上,請求會被發送給Netscaler組件,并通過負載均衡的方式將請求傳送給前端應用服務器,當下3個數據中心前端服務器的數量已接近700。鑒于所有前端都是虛擬服務器,運維人員可以根據需要快速的添加容量,每個服務器配備了2 個虛擬CPU、4GB RAM和80GB的磁盤空間。每個前端服務器都單獨運行了Apache和Tomcat,Apache會被請求發送給本地主機上的Tomcat,而Tomcat則負責大多數請求的處理,調用數據庫或者服務以及執行應用程序邏輯。

流量

AOL.com的流量遵循常見的互聯網使用模式――通常情況下流量不會有太大的變化,當然現實世界中發生大事件時除外。


每天流量最低的時候是早上3-6點,10點之前則是一個流量劇增期,會持續5個小時保持在20萬點擊每秒,在下午5點后降低。在一般情況下,工作日的流量會高于周末。


這些流量由個數據中心共同支撐,兩個東海岸的數據中心各負責40%,西海岸則負責剩余的20%,流量分布不均勻的原因歸結于用戶分布的不均勻,同時也因為加拿大、英國、法國等國家的用戶也被路由給了東海岸數據中心。

監視

所有的應用程序都運行在AOL數據中心,包括AOL.com,都由一個自主研發的工具監控,類似于Amazon的CloudWatch,已投入使用多年。監視工具會實時的收集軟硬件信息,并通過一個客戶端應用程序提供報告、圖及儀盤表,提供了主機、CPU、接口、網絡設備、文件系統、網絡流量、響應代碼、響應時間、應用程序度量等眾多信息。服務器端點更是每分鐘都進行檢查,并在超過基于可用性及響應時間設置的閾值時進行報警。


內容管理系統

大部分的AOL.com內容及許多的業務邏輯都來自Content Management System,CMS同樣是個自主研發系統,建立在相同的Java/JSP上,它的功能遠超越一般的CMS。編輯使用它來創建AOL.com上的可見內容,開發者使用它來配置應用程序;它同樣還是個儀表盤,讓編輯可以實時的了解頁面上所有部分的執行情況。

同樣,AOL的首頁遠不止單一域名 www.aol.com上的一個頁面。它其實由不同域名商的數十個版本組成,它們之間可能存在明顯或細微的區別。CMS允許這些不同的版本在同一個地方制作,任何一個版本都可以從相同層上的多個父類繼承不同內容,版本間的區別可以包括不同頁面上的品牌化Logo、不同ID造成的內容不同等等,比如因為國際化的和訪問設備造成的不同。


因此,內容管理系統減少了或者消除了手動的復制粘貼。比如,某個突發的事情只與美國相關,那么編輯只會在美國接口上呈現這個頁面,然后這個內容將傳播到美國網站的所有份數網站,同樣也可以實現為自助的傳播到下行網站。

在投放前,我們曾給這個項目進行了一定的嘗試。為了更好的測試,我們建立了多變量、多單元并行測試工具。持之以恒的進行測試,并找出優化的途徑。首先,我們選擇一定比例的測試受眾,他們將訪問一個不同的版本(可能只是按鈕顏色不同,也可能是完全不同的瀏覽體驗),通過瀏覽器cookie進行追蹤,通常往往會測試好幾周才會確定一個結果。

數據庫

AOL.com上的內容是高度動態的,因此需要為每次頁面訪問都制定數據庫和應用程序連接規則。除了在頁面上提示,CMS同樣包含了許多規則和條件內容,如果你在舊瀏覽器上,你可能會在頂部看到一個瀏覽器升級提示。因此,CMS數據需要足夠的快,有能力處理流量的爆發,并且一直可用。我們當下使用的是MySQL 5,區別于前端的虛擬服務器,數據庫服務器擁有更多的容量――16 CPU的物理服務器。

CMS數據庫使用了30個從副本,每個數據中心10個;同時,我們還會在一個數據中心建立主節點,同時還建立這個主節點的備份節點。除了主從設計之外,還會在每個數據中心設立1個中繼器(reapeater)――主節點的另一個備份,負責與整個數據中心的從節點通信,repeater的作用是減少跨數據中心的數據通信;同時,在這種情況下,如果主節點和其備份節點都宕掉,中繼器中的1個將會被指派為新的主節點。

應用程序通過1個HTTP接口訪問數據庫,AOL還為MySQL開發了1個Apache模塊。每個數據庫主機都有一個安裝了Apache模塊的Web服務器,它們負責管理數據庫的連接池,給GET請求做SQL查詢,結果則以XML格式返回。對于AOL.com這樣的Java應用程序,還會有一個Java客戶端,負責抽象HTTP調用并將XML解析成對象類型。

之所以使用HTTP數據庫接口有多個原因:首先,它讓客戶端可以更輕松的訪問數據庫,因為任何語言都可以做HTTP調用,開發者不必再去考慮MySQL客戶端驅動及連接池;其次,它有利于應用程序擴展――應用程序通過指定的URL訪問數據庫,URL對應負載局衡器的IP地址,當新的從節點加入時候,客戶端應用程序不需要進行重新配置。此外,使用HTTP接口還有利于監視。標準的Web服務器訪問日志和監視工具可以提供數據庫事務量、查詢次數及錯誤,然而在查詢包含了URL作為參數后,日志將變得更加明了;同時,因為Apache模塊中還加入了管理員接口,因此運維人員可以在任何瀏覽器上獲取數據庫狀態。

緩存

AOL的架構中多處使用了緩存,而在CMS中就有兩個級別的緩存。第一,CMS中訪問數據的Java代碼使用了內存緩存。鑒于CMS中的內容片都被版本化了,只要是新版本的話就不會有什么改動,因此數據可以被緩存來減少數據庫IO。這種緩存是在Tomcat實例級別,每700實例使用1個單獨的緩存。

但是為了得知是否有新的版本加入,我們仍然需要時常的查詢數據庫,這將帶來大量的數據庫IO,通常情況下返回的還是相同的結果。鑒于我們的數據庫查詢都由HTTP接口通過Apache模塊完成,使用Varnish Cache來緩存查詢將異常簡單。數據庫查詢都是非常簡單的HTTP GET請求,使用了URL做參數的完全SQL,因此Varnish顯著的減少了訪問數據庫服務器的流量。

Akamai CDN被用于緩存所有的靜態內容,除了靜態內容之外,AKmai每隔幾秒還會緩存AOL.com的靜態版本,這個副本被用于極端情況下的災難恢復――所有數據中心都不可訪問時,用戶將直接訪問這個副本的類容,直到數據中心恢復。

系統中最后一處緩存用于AOL.com前端JSP代碼,前端代碼的作用是從CMS收集眾多的頁面并將它們聚合到HTML。我們開發JSP標簽庫讓開發者可以緩存聚合HTML所需的任何部分,比如指定頁面的那個部分需要緩存只需要用<cache:cache> </cache:cache>這對標簽包含它們。


開發過程

大部分的時間,AOL團隊都遵循Scrum開發過程,但是也不乏因為業務需求需要加班加點的時候。大部分的網站修改都可以通過CMS完成,避開了建立或代碼開發過程。這種類型的更新每天可能發生數起至數十起,耗費的時間也是幾分鐘到幾天不等。

開發團隊會訂閱一份iPhone周刊來監視應用程序狀態,一旦發現異常數據,比如下游系統丟失,因為冗余策略雖然不會立刻影響到終端用戶,但是卻是在事情進一步惡化之前的提醒。除了應用程序方面,運維團隊在網絡、主機、數據庫問題上都建立了類似的機制,讓團隊可以應對任何狀況。

開發者在局部環境工作,大部分都使用裝有Netbeans或Eclipse的Macbook Pro筆記本。在開發過程中存在6個不同的生產環境――與生產環境配置相同,但是規模較小。

代碼在發布前需要經過嚴格的QA過程,同時鑒于AOL.com的多版本,測試環節所需要做的事情更加復雜(詳情見原文)。

回顧和展望

當下AOL.com的技術堆棧已非常成熟,鑒于系統的架構設計于6年前,部分設計在今天可能已經不是第一選擇,比如Java/Tomcat/JSP已經給Python和PHP應用讓路,Apache可能也會略遜于Nginx,同時NoSQL數據庫也帶來了更多的選擇,許多選擇已運用在AOL的其它系統中。

不能免俗的是,架構中帶來靈活和穩定的部分同樣阻礙了新技術的采用,然而這并不能阻礙我們給系統做出有益的改變,比如:從實體到虛擬機、添加Varnish Cache以及引入Jenkins。同時,我們現在還在重寫前端的HTML和CSS以清理歷史遺留代碼,同時也有助于多年前不可能關注的響應速度。總而言之,根據需求不停的演變架構以迎合產業的需求才是關鍵所在。

原文鏈接: How the AOL.com Architecture Evolved to 99.999% Availability, 8 Million Visitors Per Day, and 200,000 Requests Per Second(編譯/仲浩 審校/魏偉)

生活不易,碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
程序員人生
------分隔線----------------------------
分享到:
------分隔線----------------------------
關閉
程序員人生
主站蜘蛛池模板: 免费一级做a爰片久久毛片潮喷 | jjzz黄色| 亚洲永久 | 中文字幕第10页 | 白嫩美女一级毛片免费看 | 亚洲a视频 | 亚洲色网址 | 美国一级毛片在线 | 特级aa一级欧美毛片 | 欧美福利网址 | 免费麻豆国产一区二区三区四区 | 欧美福利专区 | 亚洲欧美另类视频 | 在线欧美a| 久久亚洲精品人成综合网 | 一级毛片一级毛片免费毛片 | 97精品伊人久久大香线蕉 | xxxxx日韩| 亚洲天堂在线视频播放 | 精品国产一区二区三区四区不 | 日韩亚洲欧美一区二区三区 | 最近中文字幕mv免费看 | xxfree性人妖hd | 欧美性一区二区三区五区 | 亚洲综合第二页 | 国产偷v国产偷v亚洲偷v | 免费一级欧美大片久久网 | 国产免费高清 | 人阁色第四影院在线观看 | 国产免费69成人精品视频 | 一区二区三区国产精品 | 在线视频 中文字幕 | 欧美网色 | 国产免费久久精品 | 日韩手机在线视频 | 日本欧美强乱视频在线 | 欧美精品超清在线播放 | 免费日本网站 | 极品久久 | 2020久久精品亚洲热综合 | 亚洲剧情在线 |