# AOL.com 體系結構如何發展到 99.999％的可用性，每天 800 萬的訪問者和每秒 200,000 個請求 > 原文： [http://highscalability.com/blog/2014/2/17/how-the-aolcom-architecture-evolved-to-99999-availability-8.html](http://highscalability.com/blog/2014/2/17/how-the-aolcom-architecture-evolved-to-99999-availability-8.html)  *這是 AOL 的 [Dave Hagler](http://www.linkedin.com/in/hagler) 系統架構師的特邀帖子。* AOL 主頁每天收到超過 **800 萬名訪客**。 與《美國早安》或電視上的《今日秀》相比，每天的觀看者更多。 每月提供的網頁瀏覽量超過十億。 自 1996 年以來，AOL.com 一直是主要的互聯網目的地，并且仍然擁有大量忠實用戶。 **AOL.com 的架構是第 5 代**。 在過去的 20 年中，它已經從頭開始進行了 5 次重建。 當前的體系結構是 6 年前設計的。 零件已升級，并在此過程中添加了新組件，但總體設計仍保持完整。 經過 6 年的持續改進，對代碼，工具，開發和部署過程進行了高度調整，使 AOL.com 體系結構經過了測試，并且非常穩定。 工程團隊由開發人員，測試人員和運營人員組成，**總共約有 25 人**。 大多數人在弗吉尼亞州的杜勒斯，在愛爾蘭的都柏林有一個較小的團隊。 通常，使用的技術是 **Java，JavaServer Pages，Tomcat，Apache，CentOS，Git，Jenkins，Selenium 和 jQuery** 。 在該堆棧之外還使用了其他一些技術，但是這些是主要組件。 ## 設計原則 有一些重要的總體原則可以驅動體系結構。 首先，所有都有**冗余。 即使出現故障或需要維修時，仍然存在冗余。 要求有 5 個 9 的可用性，每年大約需要 5 分鐘的停機時間。** 第二個原則是 AOL.com **不應依賴任何共享基礎結構**來傳遞其頁面。 如果其他 AOL 屬性或系統出現故障，則 AOL.com 需要保持正常運行。 一段歷史：在開發此體系結構時，大多數 AOL Web 屬性只有一個共享的基礎架構，稱為 Big Bowl，這是一個反復出現的問題，其中一個屬性會影響其他屬性。 結果，當前的 AOL.com 專門設計為通過隔離自身來解決此問題。 對 AOL.com 的任何依賴都以保護服務為前提，該保護服務將對下游系統的調用集中在較小的服務器上。 下游系統沒有從數千個服務器接收請求，而是從大約 20 個不同的服務器獲得呼叫。 并且響應被緩存以進一步防止不堪重負。 此外，外部數據庫被復制以提供給 AOL.com 自己的副本，并由其自己的運營團隊進行管理。 關于唯一共享的組件是網絡和身份驗證服務。 另一個原理是**緩存用于優化性能，但不是系統以**規模運行的要求。 該基礎結構的大小可在不進行緩存的情況下承受全部流量，同時仍可確保足夠的冗余度以容忍中斷。 緩存是一種獎勵，但不是必需的。 ## 物理基礎架構 在 3 個數據中心中為 AOL.com 服務。 其中兩個位于北弗吉尼亞州，一個位于加利福尼亞州，均由 AOL 擁有和運營。 所有 3 個數據中心都在積極地為流量提供服務，但是每個數據中心的大小都使其能夠自行處理全部流量。 這樣可以使一個數據中心脫機以進行維護，并且在發生故障的情況下仍具有冗余數據中心。 收到請求后， **Akamai GSLB 處理整個數據中心**的負載平衡，并將用戶定向到最近的一個。 Akamai CDN 用于靜態內容。 一旦進入數據中心，對服務或數據庫的任何進一步請求將保留在該數據中心內。 用戶會話信息保存在 cookie 中，并在請求中傳遞，因此任何服務器都可以為任何請求提供服務而不會保留任何狀態。  在每個數據中心內，Netscaler 設備接收**請求并將其負載均衡到許多前端應用程序服務器**之一。 所有數據中心大約有 **700 個前端服務器。 前端是虛擬服務器，操作員可以根據需要通過擴展其他服務器來快速增加容量。 前端的虛擬主機分別配置有 2 個虛擬 CPU，4GB RAM 和 80GB 磁盤空間。 每個前端服務器都運行 Apache 和 Tomcat 的單個實例。 Apache 將請求傳遞給在本地主機上運行的 Tomcat。 **Tomcat 處理大量請求**，調用數據庫和服務，并執行所有應用程序邏輯。** ## 流量 AOL.com 的訪問量出人意料地可預測，遵循與互聯網使用情況類似的模式。 重大世界事件將導致峰值，但否則模式將非常一致。 每天的流量從凌晨 3 點到 6 點是最低的，直到上午 10 點才急劇增加，**大約以 200,000 次點擊/秒的速度徘徊 7 小時**，然后在下午 5 點之后開始下降。 每天重復相同的周期。  在工作日中，到 AOL.com 的流量比周末高。 每周中沒有一個特定的工作日始終高于其他工作日。 換句話說，星期一與星期二或星期五沒有什么不同。 但是周末總是比工作日低。  流量分布在 3 個數據中心的 2,000 臺前端服務器中。 東海岸的兩個數據中心分別接收約 40％的流量**，而 20％的流量到達西海岸**。 分布不均是因為 Akamai 將用戶路由到最近的數據中心，并且在美國東部地區有更多的最終用戶。 此外，流向國際站點 aol.ca，aol.co.uk，aol.fr，aol.de 的流量都流向美國的東海岸數據中心。 ## 監控 AOL 數據中心（包括 AOL.com）中運行的所有應用程序均由自主開發的工具監視**，該工具已開發了多年，其功能類似于 Amazon 的 CloudWatch。 硬件和軟件指標可以實時收集和匯總。 客戶端應用程序提供報告，圖形和儀表板。 提供了主機，CPU，接口，網絡設備，文件系統，Web 流量，響應代碼，響應時間，應用程序度量標準和其他信息。 每分鐘檢查一次服務器端點，并在未達到可用性和響應時間的某些閾值時發出警報。**  ## 內容管理系統 AOL.com 的大部分內容以及很多業務邏輯都來自**內容管理系統**。 CMS 是基于相同的 **Java / JSP 技術堆棧**構建的本地應用程序。 它具有除典型 CMS 之外的許多功能。 編輯者使用它來創建您在 AOL.com 上看到的內容。 開發人員使用它來配置應用程序。 它還是一個指標儀表板，供編輯人員提供有關頁面上每個內容的性能如何的實時數據。 AOL 主頁不僅僅是一個頁面，而且位于單個域 www.aol.com。 它實際上由相同內容的數十個不同版本組成，它們在不同的域上，可能有許多可見或細微的差異。 CMS 允許在一個地方對主頁的這些不同版本進行編程，并從層次結構中的多個父級繼承特定版本的內容。 版本之間的差異可以很簡單，例如頁面上的不同品牌徽標，不同的跟蹤 ID，或者某些或全部內容可以完全不同。 例如，用作美國主頁（www.aol.com）的 AOL.com 版本可能與加拿大版本（aol.ca）不同，而加拿大版本可能與移動版本（m.aol。）不同。 com）。 還有供合作伙伴使用的品牌版本，例如 Verizon 的移動門戶。  這樣，**內容會滴入**，從而消除了對大量手動復制內容的需要。 以僅與美國站點相關的突發新聞事件為例。 編輯人員將在“美國”部分對突發新聞進行編程，并將其編入所有從美國繼承的網站。 如果由于某種原因突發新聞僅針對 Verizon 門戶，則編輯者可以在該級別進行編程，并將其下放到各個 Verizon 站點。 在將 **推廣給更廣泛的受眾**之前，我們**測試每個功能以查看其性能。 為了方便測試，CMS 中內置了一個多變量測試工具，該工具允許任意數量的測試單元并行運行。 我們會不斷測試不同的內容和設計元素，以優化體驗。 定義為訪問量百分比的測試受眾將獲得該網站的其他版本。 將用戶隨機放入測試單元中，并使用瀏覽器 cookie 進行跟蹤。 測試可能是按鈕顏色的微小外觀變化，可能是內容的不同布局，也可能是完全不同的體驗。 在應用結果之前，測試通常會運行數周。** ## 數據庫 AOL.com 上的內容是高度動態的，并且需要訪問數據庫并為每個頁面視圖應用規則。 除了您在頁面上看到的標記外，CMS 還包含許多規則和條件內容。 例如，如果您使用的是較舊的瀏覽器，則可能在頁面頂部看到“瀏覽器升級”標語。 因此，CMS 數據庫需要快速，能夠處理極端流量突發并且始終可用。 我們正在運行 **MySQL 5** ，并且與虛擬化的前端服務器不同，**數據庫服務器更大，具有 16 個 CPU 和額外磁盤空間的物理主機**。 CMS 數據庫有 **30 個從屬副本，每個數據中心**中有 10 個。 單個主服務器位于其中一個數據中心，而備用主服務器位于同一數據中心中，以防發生故障。 除了主服務器和從屬服務器之外，每個數據中心中都有一個與主服務器進行復制的中繼器，并且該中繼器在其數據中心中充當從屬服務器的主服務器。 中繼器的目的是減少跨數據中心的復制流量。 發生故障時，每個數據中心中都有一個備用轉發器。 如果主主機及其備份發生故障，則將其中一個轉發器指定為新主機。 應用程序**通過 HTTP 接口**訪問數據庫。 AOL 開發了一個 apache 模塊，用作 MySQL 的接口。 每個數據庫主機上都有一個安裝有模塊的 Web 服務器。 管理員管理與其數據庫的連接池，將 sql 查詢作為 GET 請求，然后以 XML 格式返回結果。 對于 AOL.com 之類的 Java 應用程序，有一個 Java 客戶端庫可將 HTTP 調用和 XML 解析抽象為類型化的對象。 HTTP 數據庫接口有多個原因。 首先，它使客戶端的數據庫訪問更加簡單。 任何使用任何編程語言的應用程序都可以進行 HTTP 調用，而無需擔心 MySQL 客戶端驅動程序或連接池。 其次，擴展應用程序也很容易。 應用程序通過單個 URL（指向負載均衡器虛擬 IP 地址的 URL）訪問數據庫。 添加新的從屬服務器后，客戶端應用程序無需將其添加到其配置中。 HTTP 接口的另一個好處是用于監視。 標準的 Web 服務器訪問日志和監視工具可以提供數據庫事務量，查詢響應時間和錯誤。 整個 SQL 查詢都作為參數包含在 URL 中，因此可以輕松地在日志中使用。 apache 模塊中還內置了一個管理界面，可以從任何 Web 瀏覽器獲取數據庫診斷信息。 ## 緩存 在體系結構中，有幾個區域使用了緩存。 CMS 中有**個二級緩存。 首先，訪問數據的 CMS Java 代碼利用內存緩存。 由于**的內容在 CMS 中的每個內容都是**版本，并且從未更新過，而是一個新版本，因此可以輕松地緩存數據以減少對數據庫的查找。 這種類型的緩存位于 Tomcat 實例級別，每個 700 個實例均保留其自己的緩存。** 但是仍然需要為每個頁面加載檢查數據庫，以查看是否有新的內容修訂版。 這會轉化為許多數據庫查詢，通常結果相同。 由于我們的數據庫查詢全部由 HTTP 接口通過前面描述的 apache mod 代理，因此我們可以使用 Varnish Cache 輕松地**緩存請求。 數據庫查詢是簡單的 HTTP GET 請求，URL 中帶有完整的 SQL 查詢，因此 Varnish 可以很好地工作，從而大大減少了到數據庫服務器的流量。** **Akamai CDN 用于緩存所有靜態資產**。 除了靜態資產緩存之外，Akamai 還每隔幾分鐘就會緩存一個精簡的 AOL.com 靜態版本。 當所有數據中心均無法訪問時，這是災難情況下很少使用的后備。 用戶將直接從 Akamai 獲取緩存的頁面，直到實際頁面重新聯機。 緩存的最終區域在 AOL.com **前端 JSP 代碼**中。 前端的工作是從 CMS 收集大量的小片段內容，并將它們組裝成 HTML 頁面。 我們開發了一個 JSP 標記庫，使開發人員可以在頁面上緩存任何組合的 HTML 塊。 例如，要指定要緩存的頁面部分，請用< cache：cache > < / cache：cache >包圍它。  ## 開發流程 對于需要更改編碼的主要功能，開發團隊會松懈地遵循 **Scrum 流程**。 沖刺通常需要 3 到 4 周，具體取決于業務承諾。 有時，可能同時處理多個 Sprint，例如某個功能需要花費 4 個多星期的開發時間。 僅通過 CMS 發布即可完成許多**網站更改，而無需構建或代碼部署過程。 這些是經常發生的事件，它們作為非周期過程處理，請求通過電子郵件列表發送給團隊。 這些更改全天部署，每天變化范圍從幾到十幾個或更多。 這些更改的周轉時間為幾分鐘到幾天。** 開發**小組每周輪換一個 iPhone，以作為應用程序隨時待命**。 觸發應用程序級別監視時，應用程序呼叫會收到警報。 例如，來自下游系統的數據可能已停止流動。 對于最終用戶而言，這不會造成明顯的問題，因為在這種情況下會有冗余和適度的后備，但是它會在問題變得嚴重之前主動發出警告。 除了應用程序待命之外，運營團隊還可以待命以解決網絡，主機和數據庫問題。 有明確定義的上報途徑和團隊來處理任何情況。 開發人員**在其本地環境**中工作。 大多數使用 Macbook Pro 筆記本電腦和 Netbeans 或 Eclipse。 在開發過程中使用了 6 種非生產環境。 所有環境都與生產環境匹配相同的配置，但規模較小。 有 2 個 Dev Integration，4 個 QA 和 1 個 Staging 環境。 多個 QA 環境對于同時支持 2 個 sprint 以及必要時的生產修復都必不可少。 通常，在任何給定時間僅使用 1 或 2 個 QA 環境。 國際版本也有單獨的 Dev，QA 和 Staging，它們分別運行同一代碼庫的單獨實例來服務 aol.co.uk，aol.fr 和 aol.de。 在安裝新代碼之前， **QA 流程相當嚴格**。 這些年來，已經建立了許多回歸測試，不僅有大量的自動化測試，而且還有許多手動測試。 硒用于自動化測試。 有一個自定義的屏幕截圖工具，可以快速捕獲各種瀏覽器/操作系統組合中的頁面外觀。 與典型的網站相比，AOL 使用較舊系統的用戶更多，而我們的回歸測試套件則包括 IE7，AOL 桌面瀏覽器以及模擬緩慢的 Internet 連接。 我們還測試了瀏覽器/操作系統/設備組合的廣泛矩陣。 在裝有 Windows 7 的 IE9 上看起來有些不錯，但在裝有 Windows XP 的 IE9 上卻壞了。 它增加了很多額外的時間來對瀏覽器和操作系統的所有排列進行站點回歸測試，但是事實證明，多年來，它是必要的。 Windows XP 和舊版 IE 構成了最大的問題。 AOL.com 傾向于在這些較舊的系統上吸引更多用戶，因此我們會更加注意它。 完整的安裝過程從開始到結束大約需要 2 個小時，整個開發團隊都在聽電話會議。 當流量最低時，安裝通常在美國東部時間上午 6 點完成。 在安裝過程中，站點或 CMS 不會停機。 即使大多數安裝步驟都是腳本化的，但每個步驟都由操作員單獨運行并在執行過程中進行驗證。 在生產安裝的前一天，在登臺環境中練習了整個安裝過程和腳本。 備份數據庫后，將部署并驗證各種組件。 更新網站的一個挑戰是 CDN 交付的 CSS，圖像和 Javascript 會緩存在瀏覽器中。 這樣，用戶可能會遇到糟糕的體驗，直到緩存的元素過期為止。 我們遵循消除此問題的過程。 首先，將新的**靜態內容推送到新版本路徑**下的 CDN，從而使舊資產和新資產均可用。 接下來，將生產環境中運行的舊代碼配置為指向新資產。 為了使它起作用，我們確保所有靜態內容都向后兼容。 一旦有新資產可用，就將新代碼部署到前端 Tomcat 服務器。 對于每臺服務器安裝，Apache 都會停止運行，這會告訴負載平衡器停止旋轉并停止發送流量。 然后停止 Tomcat，安裝新代碼，重新啟動 Tomcat，最后重新啟動 Apache，這觸發負載均衡器開始發送流量。 **使用 AOL 基于 RPM 軟件包**定制開發的部署系統，通常需要 20 到 30 分鐘才能在所有數據中心（總共超過 2000 臺服務器）中部署新代碼。 ## 來回回顧 AOL.com 的技術堆棧已經成熟并且運行良好。 就像任何使用 6 年以上的系統一樣，如果我們今天才開始，我們可能不會做出相同的選擇。 Java / Tomcat / JSP 已被 Web 應用程序的 Python 和 PHP 取代。 Nginx 的性能可能優于 Apache，并且出現了 NoSQL 數據庫。 許多這些技術已在 AOL 的其他領域中使用。 這是成功軟件系統的經典難題。 相同的健壯功能使當今的體系結構如此靈活和可靠，這使得利用新技術變得困難。 但是我們在此過程中做出了一些有影響力的更改。 僅舉幾個例子，包括從物理主機到虛擬主機的轉換。 添加清漆緩存； 并將 Jenkins 引入構建過程。 我們正在對前端 HTML 和 CSS 進行完全重寫，以清理大量舊代碼并促進響應性設計，而這幾年前還沒有考慮過。 我們的道路仍然是發展體系結構，在合理的時候重建零件并適應行業不斷變化的需求。 感謝您提供非常有趣的信息:-) 我感覺合理。 簡單，無聊且有效。 同樣，雖然有人將 Java 稱為新的 COBOL，但這并不總是一件壞事-許多語言設計使其能夠很好地處理 5 年未修改的代碼的維護工作，這對于像這樣的大型項目來說是一個重大問題。 即使它是免費的，在系統重寫后，任何問題所涉及的風險似乎也超過了任何財務收益。 像將其作為尋呼機一樣旋轉物理 iPhone 似乎有些愚蠢。 也許你們可能想研究一下 PagerDuty 這樣的更好的解決方案。 做得好！ 確實很有趣，有很多好處。 我真的很喜歡這篇文章。 謝謝戴夫。 鑒于該站點全天僅執行 8 毫米操作，因此每秒 200k 次的命中率似乎太高了。 在這段時間內，按照 200k /秒的文章進行 8 個小時的數學運算，將獲得 84MM 的點擊。 所以有些事了。 @EJ-200,000 次命中/秒是對前端服務器的所有請求。 對該頁面的訪問會產生許多服務器調用，因為在后臺還會發生其他 ajax 調用。 另外，其他 AOL 屬性正在使用 api，這些 api 會導致訪問前端服務器的流量，但不會注冊用戶訪問。 @ EJ 每天有 800 萬訪客，相對于每秒 20 萬頁面請求。 它沒有詳細介紹每個用戶獲得多少頁面請求。 戴夫，感謝您花費時間和精力來教育我們所有人。 您參與設計的過程令人印象深刻，您的雇主也允許您提高人們的數字敏感性，這也說明了他們的數量。 嗨，戴夫， 我希望您能透露更多有關您如何授權用戶的信息。 您正在使用 cookie，并且有一些身份驗證服務。 是否在每個請求（如果適用）上調用這些服務？ 解決方案是自家生產的嗎？ 我知道這個主題有點...嗯...很敏感，所以我會盡我所能。 謝謝 數據庫設計更引人入勝。 有人知道我們是否也可以采用類似的設計進行交易處理嗎？ 很棒的文章，非常感謝。 一件特別的事引起了我的注意，因為我們一直都在努力解決它： “對于每臺服務器安裝，Apache 都停止了，這告訴負載均衡器使其停止旋轉并停止發送流量。” 為了將其從負載均衡器池中刪除，Apache 實際上是否已停止運行？ 還是為了在停止 Apache 之前將其刪除而做些什么？ 顯然，僅停止 Apache，將導致所有活動用戶斷開連接。 除非使用“平穩停止”？ Thanks