# Bazaarvoice 的架構每月發展到 500M 唯一用戶 > 原文： [http://highscalability.com/blog/2013/12/2/evolution-of-bazaarvoices-architecture-to-500m-unique-users.html](http://highscalability.com/blog/2013/12/2/evolution-of-bazaarvoices-architecture-to-500m-unique-users.html)  *這是由 [Victor Trac](http://victortrac.com) ，的云架構師 [Bazaarvoice](http://www.bazaarvoice.com) 撰寫的客座 。* Bazaarvoice 是一家與人們定期進行互動但從未聽說過的公司。 如果您在 bestbuy.com，nike.com 或 walmart.com 等網站上閱讀了客戶評論，則說明您正在使用 Bazaarvoice 服務。 這些站點以及其他數千個站點都依賴 Bazaarvoice 提供軟件和技術，以收集和顯示有關產品和服務的用戶對話。 所有這些意味著 Bazaarvoice 會處理我們每天使用的大多數產品的很多情緒數據。 Bazaarvoice helps our clients make better products by using a combination of machine learning and natural language processing to extract useful information and user sentiments from the millions of free-text reviews that go through our platform. This data gets boiled down into reports that clients can use to improve their products and services. We are also starting to look at how to show personalized sortings of reviews that speak to what we think customers care about the most. A mother browsing for cars, for example, may prefer to read reviews about safety features as compared to a 20-something male, who might want to know about the car’s performance. As more companies use Bazaarvoice technology, consumers become more informed and make better buying decisions.  *紅色的框由 Bazaarvoice 提供* Bazaarvoice 已集成到全球數千個網站中。 在任何給定的月份，我們將為超過 4.75 億的唯一身份訪問者提供流量。 這些訪問者將瀏覽，閱讀和貢獻我們的內容，包括從產品評論到問題&答案，甚至是我們客戶產品和服務的視頻等內容。 這五億人口將在我們的平臺上花費大量時間，每個月的瀏覽量達到數百億。 而且由于我們在眾多人流量眾多的商業站點上，因此我們的可靠性和正常運行時間至關重要。 如果 Bazaarvoice 平臺發生故障，我們將影響成千上萬依賴我們的網站。 為了快速，可靠地完成所有這些工作，我們設計了一個高度冗余的堆棧，該堆棧主要建立在 Amazon Web Services 之上。 假期購物旺季是我們基礎設施最繁忙的時間。 在“黑色星期五”和“網絡星期一”，我們會看到流量非常高，從今年年底到 1 月，我們的負荷一直很高。 這就提出了一個獨特的擴展挑戰，因為我們必須在一年中的 3-4 個月內處理幾乎兩倍于正常（并且一直在增長）的流量。 今年，我們預計在假日購物旺季每秒將收到 6 萬至 6.5 萬次請求。  *假期前到我們平臺的帶寬和 HTTP 請求的一周視圖* ## 卑微的開端 與大多數大型軟件堆棧一樣，我們從一個非常簡單的體系結構開始。 我們最初的應用程序是使用 MySQL 作為數據存儲的單個整體 Java 應用程序，所有這些程序都在托管主機環境中運行。 隨著我們這些年來的成長，我們在相同的代碼庫上構建了其他應用程序，并增加了新功能。 我們是 Solr 的早期用戶，它使我們能夠將 MySQL 主要轉變為鍵值存儲。 除了 Solr，我們通過僅給 JVM 更多的 RAM 或將 MySQL 服務器放在更快的盒子上來垂直擴展。 然而，正如一位經驗豐富的工程師所知道的那樣，垂直縮放所帶來的容易的早期收益很快變得難以實現。 因此，我們通過簡單地復制整個堆棧開始水平擴展。 我們稱這些為“集群”，它們使我們無需進行較大的應用程序更改即可實現水平擴展。  *每個群集都是具有不同數據的整個堆棧的副本。* 在 2008 年，Bazaarvoice 大約 3 歲時，我們在托管數據中心經歷了一些停機時間，這使我們面臨著更多冗余的挑戰。 一種選擇是簡單地在另一個地理區域中找到另一個托管服務提供商，然后復制我們所有的服務器。 但是，由于我們使用的是 MySQL，因此我們無法輕松地跨地區使用多主機。 因此，我們最初的計劃只是從主托管數據中心運行 MySQL 復制，并保持足夠的容量以熱備份方式在備份區域中為生產流量提供服務。 如果我們的主數據中心發生故障，我們將更新 DNS 以指向備份數據中心。 但是，這將意味著很難進行單向故障轉移，因為 MySQL 從屬服務器將被提升為主服務器。 為使從屬數據中心在災難中真正發揮作用，我們需要保留足夠的備用容量來服務我們 100％的生產流量，從而在不增加生產能力的情況下有效地使托管成本增加一倍。 ### 輸入 AWS 作為當時的年輕創業公司，我們無法簡單地將托管成本提高一倍。 Amazon Web Services 在一個月前（即 2008 年 10 月）剛剛從 EC2 刪除了“測試版”標簽，因此我們認為這可能是一個絕佳的機會，可以利用這種新型云技術在我們的備用站點上節省資金。 在 EC2 上構建冗余備份站點時，我們的策略與使用備份數據中心基本相同，除了不必為機架中準備就緒的服務器付費，我們只需要運行 MySQL 從屬即可。 。 當我們需要故障轉移到 EC2 時，我們可以按需啟動實例。 這樣做的成本只是在另一個數據中心復制整個生產堆棧的成本的一小部分。  *我們最初嘗試使用 MySQL 從站進入 Amazon Web Services。* 幸運的是，我們無需執行故障轉移計劃。 但是，當我們決定要在托管數據中心和 Amazon us-east-1 地區之外提供實時流量時，我們使用 EC2 的經驗使我們有足夠的信心繼續使用它。 我們的數據已經被復制到 us-east-1 中，因此我們只需要啟動應用程序實例并在應用程序堆棧上進行一些小的工程設計即可使其適合實時請求。 AWS us-east-1 設計為只讀，可與 MySQL 復制完美配合。 當最終用戶向 AWS 提交新的內容時，這變得更加復雜，因為 AWS 中的 MySQL 是只讀的。 我們通過編寫一個基于 MQ 的提交隊列解決了這個問題，該隊列將寫操作復制回我們的主數據中心，在此我們在 MySQL Master 上執行寫操作。 在幾秒鐘內，更改將被復制回 AWS。 此設置運行良好，使我們能夠將生產能力提高一倍，同時仍然使我們能夠在必要時完全故障轉移到 AWS。 不久之后，我們決定將 us-east-1 集群復制到 us-west-2，從而為我們提供了三個實時生產區域。 [  *MySQL 從我們的托管數據中心復制到兩個 AWS 區域。* 為了在兩個 AWS 區域與我們的托管 DC 之間路由請求，我們采用了基于 DNS 的健康檢查系統。 在 EC2，我們使用在具有 EIP 的實例上運行的 HAProxy 作為負載均衡器。 這使我們在 EC2 的每個區域的每個群集獲得一個公共 IP，在我們的托管數據中心的每個群集獲得一個公共 IP。 我們將這些原始 IP 添加到了我們的 DNS 服務的基于 DNS 的運行狀況檢查池中，該池定期向每個原始 IP 發出 HTTP 請求。 DNS 服務器會拉出所有在運行狀況檢查中失敗的原始 IP，同時平衡到其他區域的流量。 這樣做的一個附帶好處是，我們可以輕松地拆除一個區域并一次滾動部署（一個區域一次），讓 DNS 處理流量的轉移。 多年來，隨著我們獲得成千上萬的客戶并將流量擴展到每月數十億的頁面瀏覽量，我們最終獲得了運行在 3 個 AWS 區域和受管理數據中心的 7 個集群中的數百個應用程序服務器。 每個集群都有一個主數據庫，在三個區域中都有大量的從屬鏈。 如果沿鏈上的中繼從機死亡，我們將必須重建所有下游從機以重置主機位置。 從操作的角度來看，這變得非常難以管理。 我們還有兩個重要的寫流量瓶頸：在托管數據中心運行的 MySQL 主服務器和在所有從服務器上的 MySQL 單線程復制。 當我們不得不攝取大量新數據時，奴隸通常會落后一些，有時甚至要花 10 個小時或更長時間。 我們需要重新考慮整個堆棧。 ## 從干凈的板巖開始 在 2011 年底，我們的堆棧正在工作，但我們希望將其提升到更高的靈活性，性能和可靠性水平。 我們想解決我們的多區域復制問題。 我們希望擺脫單個集群，以便我們可以做更多有趣的跨集群數據關系。 我們想更快地發布。 我們希望成為更多的云原生用戶，以便能夠利用自動擴展等 AWS 功能。 這是很大的變化，但是我們從 Amazon Web Services 獲得了一個新的 CTO，他非常支持這些計劃。 ### 組織和技術變更 我們的整體 Java 應用程序分為一組小型服務，每個小型服務均由分散的工程團隊提供支持。 這些團隊負責從開發到質量檢查再到運營的整個服務生命周期。 此外，工程學采用敏捷作為開發方法，以前我們是在瀑布驅動下進行的。 這些更改使我們能夠從高度協調的 8-12 周發布周期轉變為允許任何團隊隨時發布。 一些團隊繼續進行完整的持續集成。 在技術方面，我們決定在新堆棧中全力支持 AWS。 對于我們的記錄系統，我們選擇 Cassandra 是因為它具有多區域復制功能（DynamoDB 在這里失敗）和云原生操作質量。 出于類似原因，ElasticSearch 取代了 Solr。 ### 云工程師 我們成立了一個名為 Platform Infrastructure 的團隊，負責構建 AWS 基礎設施和云工具。 平臺基礎架構團隊選擇使用 CloudFormation 在 Amazon 的虛擬私有云環境中的三個區域（us-west-2，us-east-1 和 eu-west-1）中構建 AWS。 然后，平臺基礎架構團隊構建了有用的微服務，例如內部 VPC DNS，內部監控，集中式日志記錄，成本分析，甚至是受 Netflix 啟發的“猴子”，以執行標簽一致性實施。 由于所有內容都使用 CloudFormation，因此我們能夠在幾個小時內迅速為三個區域的 Dev，QA 和 Prod 環境啟動相同的 VPC。 這個內部稱為 Nexus 的新平臺負責“繁重”的基礎架構，并為應用程序團隊構建服務奠定了堅實的基礎。  *Nexus：三個 AWS 區域中跨九個 VPC 的三個環境。 來自類似環境的 VPN。* ### VPC 基礎架構 除了環境標簽，IP 范圍（當然還有數據集）之外，每個 VPC 看起來都相同。 每個 VPC 使用一個/ 20 子網，分為三個/ 24 公共子網和三個/ 22 私有子網，每個 VPC 使用三個可用區。 我們的 CloudFormation 模板還使用自動縮放組 1 來為每個可用區配置 1 臺 NAT 服務器，并設置路由，以便每個專用子網使用其自己的 NAT 服務器進行出站連接。 這允許 AZ 級別的隔離，并使 NAT 帶寬增加三倍，而不是每個 VPC 使用單個 NAT 服務器。  *每個 VPC 使用三個可用區，每個可用區都有自己的 NAT 實例。* 我們為每個工程師提供了一個完整的 AWS IAM 帳戶，使他們可以不受限制地訪問 Amazon 的各種更高級別的服務，例如簡單工作流程服務，Elastic MapReduce 和 Redshift。 我們選擇優化工程師敏捷性而不是效率。 但是為了確保我們的成本不會完全失控，平臺基礎架構團隊會強制執行標簽一致性。 為了保持一致，每個團隊必須在其所有資源中使用兩個標簽：team 和 VPC。 沒有適當標簽的任何 AWS 資源都會自動終止。 擁有一致且強制的標記的一個巨大好處是，我們能夠確定每個團隊的確切成本。 ### 數據層 我們的數據團隊提供了三項服務來處理我們的海量數據集，所有這些服務均針對開發人員的生產力和易于管理進行了優化。 為了存儲通用的內容類型而不需要進行模式遷移，并且能夠表達性地查詢我們的數據，EmoDB 和 Polloi 誕生了。 在 Cassandra 的支持下，EmoDB 設計為使用最終一致性（AP）和多主機沖突解決方案來跨越多個數據中心。 它公開了一個非常簡單的 RESTful API，允許用戶創建“表”（不需要模式-僅表名和表放置），并將文檔存儲在這些表中。 EmoDB 仍然缺少 SQL 語義，例如 where，join，group by-基本上是除主鍵查找和表掃描之外的任何其他語義。 這就是 Polloi 的來歷。 Polloi 將實體流索引到 ElasticSearch 集群中。 每個表的索引是根據用非常簡單的域特定語言（DSL）指定給 Polloi 的規則完成的。 一旦 Polloi 根據這些用戶指定的規則為數據建立了索引，我們最終將獲得一個功能強大的 ElasticSearch 集群，該集群不僅可以處理主鍵查找。 而且由于每個 Polloi 集群都有一個自定義的規則集，所以我們有多個 Elasticsearch 集群，每個集群都針對使用它們的應用程序的需求進行了調整。 應用程序可以利用 ElasticSearch 的強大功能來對 PB 級數據進行超快速的查詢響應。 ElasticSearch 仍需要與 EmoDB 保持同步，因此我們創建了數據總線以將 EmoDB 和 Polloi 結合在一起。 Databus 允許應用程序監視 EmoDB 表和文檔上的更新事件，而 Polloi 偵聽 Databus 上的實時更新并適當地索引數據。  *EmoDB，Polloi 和數據總線* 簡而言之，EmoDB 提供了一種簡單的方法來存儲 JSON 對象，對特定應用程序很重要的 Polloi 索引字段，并且 Databus 會將數據的更改通知 Polloi 以及其他任何人。 ### 應用層 隨著轉向面向服務的體系結構，我們的工程師不再受限于特定的技術堆棧。 服務團隊可以選擇最適合他們的語言和組件。 盡管大多數團隊仍然選擇使用 Java 來實現其服務，但 Python 和 node.js 是另外兩個受歡迎的選擇。 此外，團隊可以自由選擇 Amazon 的更高級別的服務，例如簡單隊列服務（SQS），簡單通知服務（SNS）甚至簡單工作流服務（SWF）。 現在，我們最成功的服務之一就是很大程度上基于 SWF，使 Bazaarvoice 成為亞馬遜最大的 SWF 用戶之一。 使用這些 AWS 服務使團隊能夠比以前更快地構建其服務。 ### CDN & DNS 我們遺留在堆棧中的兩個組件是 CDN 和基于 DNS 的全局流量管理層。 他們倆都運作良好，因此我們不認為需要為改變而做出改變。  *Bazaarvoice 的新堆棧的高級概述。* ## 未來 隨著我們在新堆棧上增加生產工作量，我們一直在尋找改進的地方。 我們計劃在應用程序部署，基于代理的異常檢測方面實現更多自動化，并提高我們的運營效率。 我們還構建了一些有用的 AWS 工具，希望在不久的將來開源。 如果您對我們架構的任何方面都感興趣，請發表評論或 [直接與我聯系](http://twitter.com/victortrac) 。 很好的文章。 我很喜歡閱讀您如何將可搜索性與可伸縮鍵值存儲合并。 解釋得很好，路徑清楚地顯示了簡單應用程序如何轉換為大型企業應用程序。 喜歡該架構的詳細視圖，并且通過視覺插圖更容易理解。 寫得很好 做得好！ 我希望這會不斷發展！ 這非常有幫助。 很棒的博客！