# TripAdvisor 架構-4,000 萬訪客，200M 動態頁面瀏覽，30TB 數據 > 原文： [http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html)  *這是 TripAdvisor 工程部副總裁 [Andy Gelfond](http://www.linkedin.com/in/andrewgelfond) 的特邀帖子。 安迪（Andy）在 TripAdvisor 呆了六年半，在早期就寫了很多代碼，并一直在建立和運營一流的工程和運營團隊，該團隊負責全球最大的旅游網站。 史詩般的 TripAdvisor 更新：[上有此文章的更新：為什么不在云上運行？ 盛大實驗](http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html)。* 對于 [TripAdvisor](http://en.wikipedia.org/wiki/TripAdvisor) 而言，可擴展性已滲透到我們組織的多個層次上-數據中心，軟件體系結構，開發/部署/運營，最重要的是在文化和組織內部。 擁有可擴展的數據中心或可擴展的軟件架構是不夠的。 設計，編碼，測試和部署代碼的過程也需要可擴展。 所有這一切都始于招聘，一種文化和一個組織，該組織重視并支持復雜，高度可擴展的消費者網站的分布式，快速，有效的開發和運營。 ## 截至 6/2011 的統計數據 * 每月超過 4000 萬的唯一身份訪問者（Comscore），2000 萬成員，4500 萬評論和意見 * 超過 29 種銷售點，20 種語言 * 我們的移動產品可在 iPhone，iPad，Android，諾基亞，Palm 和 Windows Phone 上使用，每月吸引 1000 萬用戶 * 每天超過 200M 個動態頁面請求，而所有靜態資源（例如 js，css，圖像，視頻等）都通過 CDN 進行服務 * 每天執行超過 2.5B 的分布式操作（服務，數據庫，內存緩存），以滿足頁面請求 * 每天流式傳輸超過 120GB 的日志文件（壓縮） * Hadoop 上 30 TB 的數據，預計明年初將達到 100 TB-每天修補程序，以“需要今天退出”功能/修復 * 從來沒有計劃過停機時間，正常運行時間接近 4 9 * 在北京單獨部署以支持 daodao.com * 每周發布周期，每天發布“補丁”。 開發周期可以是一天，可以是一周，可以是一個月 * 超過二十個小型團隊（略多于 100 名工程師）一次處理 50 多個同步項目，每周部署 20-30 個項目 * 團隊包括：搜索引擎營銷（SEM），搜索引擎優化（SEO），內容管理，客戶關系管理（CRM），移動網絡，移動應用，社交網絡（FB），酒店，餐廳，論壇，旅行清單，視頻平臺，航班，度假租賃，企業列表，內容分發，API，中國 ，亞太地區，銷售和營銷活動，數據中心運營，開發運營，分析和倉儲，質量檢查 ## 一般建筑 * 開源 Linux，Apache，Tomcat，Java，Postgres，Lucene，Velocity，Memcached，JGroups * 保持非常簡單-易于構建，調試，部署，維護和操作 * 非常簡單的無狀態 Web 服務器庫，運行簡單的 Java 和 Velocity 模板 * 每個“功能”區域（媒體，成員，評論，旅行清單等）都打包為服務 * “服務”庫-每個服務都是針對總體性能進行優化的高級，面向業務的 API * 假設事情失敗了。 集群中有大量節點（Web 服務器，服務機），或者具有真正的 N + 1 冗余（數據庫和數據中心本身） ## 控制流程 * 控制流程非常簡單：解析請求 URL，從各種服務中收集內容，然后將其應用于模板。 * 我們的 URL 結構經過深思熟慮，即使在重新設計網站和重構代碼的情況下，也能保持很長一段時間的穩定性。 * 請求通過負載平衡器路由到 Web 服務器。 請求是在基于 cookie 的“池”（服務器的集合）中隨機分配的。 池用于部署管理和 A / B 測試。 請求本質上是無狀態的-瀏覽器 cookie 中存儲著“會話”信息。 登錄的用戶將從數據庫中獲取其他狀態。 * Java servlet 解析 url 和 cookie 信息并確定所需的內容，從而調用各種服務。 服務 API 定義為 Java 接口，而 Servlet 會發出 0 到十幾個服務請求。 服務呼叫通常需要 2 到 15 毫秒。 服務調用通過具有可重試邏輯的軟件負載平衡器進行，該邏輯可基于每種方法進行定義。 * 每個服務都具有針對業務和/或使用模式進行了優化的 API，例如，獲取成員的評論或位置的評論。 大多數服務本質上是數據庫前面的大型智能緩存，例如，局部 LRU，內存緩存，數據庫調用在內存部分樹/圖中。 Jgroups 有時用于在需要時使緩存保持同步。 大多數服務在不同的共享/物理計算機上運行 4 個實例，有時為服務實例分配自己的計算機。 * 從服務調用返回的內容集經過處理，并由 Java 代碼組織成對象集，這些對象集傳遞給 Velocity 模板（有點像弱 JSP） * 有多種邏輯可根據上下文選擇不同形式的 Servlet 和/或 Velocity 模板，其中可能包括 POS，語言，功能等。還有用于選擇 A / B 和其他代碼的不同代碼和模板路徑的基礎結構 測試 * 我們的 Web 服務器排列在“池”中，以允許進行 A / B 測試并控制部署。 我們的每周發布過程將部署到一個小型池中，并讓代碼運行幾個小時，以確保在部署到所有池之前一切正常 ## 科技類 * BigIP 冗余對，Cisco 路由器 * 64 個無狀態 Web 服務器，運行 Java servlet 的 Linux / Apache / Tomcat，每天處理 200M +請求的庫 * 40 臺運行約 100 個實例的無狀態服務機（約 25 個服務實例），Jetty / Java，每天處理 700M +個請求 * Postgres，在 6 對（DRDB）機器上運行，每天處理 700M +次查詢 * Memcached，3 個獨立的群集，運行在 350GB 以上的 Web 服務器上。 Spy Memcache 客戶端的可配置池-異步，NIO 以擴展請求。 進行了優化和其他更改以監視 java 客戶端以實現規模和可靠性。 * Lucene 包含在我們的服務基礎結構中，擁有 5000 萬個文檔，55GB 索引，每天 8M 搜索，每日增量更新，每周一次完全重新生成。 -隱藏引用文字- * 當沒有其他選擇時，JGroups 用于服務機之間的狀態同步。 * Hadoop，具有 192TB 原始磁盤存儲的 16 個節點群集，192CPU，10GB 網絡 * Java，Python，Ruby，PHP，Perl 等用于工具和支持基礎架構 * 監視-仙人掌，nagios，自定義。 * 兩個數據中心，位于 N + 1 配置中的不同城市，一個以 R / W 模式接收流量，另一個以 R / O 模式同步通信，準備進行 24/7 故障轉移，定期按季度交換活動數據 * 每個數據中心總共約有 125 臺計算機，所有標準 Dell 設備 * 日志記錄-120GB（壓縮）應用程序日志，apache 訪問日志，財務敏感數據的冗余日志記錄-流式（記錄）和非流式 ## 發展歷程 * 滿載的 Mac 或 Linux 計算機，SVN，Bugzilla，30 英寸顯示器 * 數以百計的虛擬化開發服務器。 每位工程師專用一位，按需提供其他服務 * 每周部署周期-每個星期一都會發布整個代碼庫 * 那些“今天需要離開”的人的每日補丁程序/修復 * 大約 100 個工程師同時處理 50 多個并發項目，每周部署約 25 個 * 工程師端到端地工作-設計，代碼，測試，監控。 您設計一些東西，然后編寫代碼。 您編寫一些代碼，然后進行測試。 * 工程師跨整個堆棧工作-HTML，CSS，JS，Java，腳本。 如果您不了解某些內容，則可以學習。 * 發布過程在各個高級工程師和工程經理之間共享和輪換 * 可用的測試框架多種多樣：單元，功能，負載，煙霧，硒，負載和測試實驗室。 它是您的代碼，選擇最適合您的代碼。 * 多種機制可幫助您提供最優質的功能：設計審查，代碼審查，部署審查，運營審查 ## 文化 * 與運行兩個同時啟動的新興公司相比，TripAdvisor 的工程技術最好，它們都在同一代碼庫上運行，并且在一個通用的分布式計算環境中運行。 這些團隊中的每個團隊都有自己的業務目標，每個團隊都有能力并對其業務的各個方面負責。 交付項目的唯一障礙是您，因為您應該在各個級別上工作-設計，代碼，測試，監視，CSS，JS，Java，SQL，腳本。 * TripAdvisor 工程是按業務職能組織的-有兩個以上的“團隊”，每個團隊負責直接與他們的業務同行在 SEM，SEO，移動，商務，CRM，內容，社交應用程序，社區，成員資格，銷售和營銷解決方案上合作 ，中國，亞太地區，商家信息，度假租賃，航班，內容聯合供稿等。 我們沒有傳統的架構師，編碼員，質量檢查人員 * 我們的運營團隊是一個團隊，負責所有其他團隊使用的平臺：數據中心，軟件基礎架構，DevOps，倉儲。 您可以將 Operations 視為我們的內部“ AWS”，將我們的 24/7 分布式計算基礎架構作為服務提供，并且將代碼/開發/測試/部署全部整合為一個。 該團隊包括兩名負責數據中心和軟件基礎架構的技術運營工程師和兩名現場運營工程師。 * 每個團隊的運作方式都最適合其獨特的業務和個人需求，我們的流程被形容為“敏捷后/混亂”。 * 責任文化-您端到端擁有您的項目，并負責設計，編碼，測試，監視。 大多數項目是 1-2 位工程師。 * 記錄和測量-大量數據，大量指標 * 黑客周-每個工程師每年都有一個星期從事他們想要的任何項目。 您可以與其他人一起解決更大的項目 * 工程交換。 來自不同團隊的工程師對將交換幾個星期的時間，以傳播知識和文化 * Web 工程程序。 一個新的計劃，適用于希望在許多不同的團隊中工作幾個月的工程師。 * 夏季星期五-在夏季改變您的星期幾并釋放星期五的時間 * 每年的慈善日-整個公司外出并為當地的慈善機構捐款-繪畫，園藝等 * TripAdvisor 慈善基金會。 員工可獲得數百萬美元的資助，可以向自己所參與的慈善組織申請贈款。 ## 關于我們學到的東西，我們如何工作的隨機想法 * 可擴展性始于您的文化，即您的雇用方式，雇用對象和設定的期望。 * 工程師。 雇用聰明，快速，靈活的工程師，他們愿意從事任何類型的工作，并為學習新技術而興奮。 我們沒有“建筑師”-在 TripAdvisor 上，如果您設計某些東西，編寫代碼，然后對它們進行測試。 不喜歡走出舒適區的工程師，或者覺得某些工作在他們“之下”的工程師將很容易受阻。 * 雇用從交付有用的事物中獲得樂趣的人。 技術是達到目的的手段，而不是最終目的。 * 您擁有自己的代碼及其效果-設計，測試，編碼，監控。 如果您弄壞了東西，請修復它。 * 最好是在兩天之內交付 20 個帶有 10 個錯誤的項目，而錯過 5 個項目，而不是交付 10 個完全且及時的項目。 * 鼓勵學習和突破極限-在這里工作的每個人在開始的幾個月中都會犯許多錯誤，并且隨著時間的推移，偶爾還會犯錯。 重要的是您學到了多少，不要一次又一次犯同樣的錯誤。 * 保持設計簡單，并著眼于近期業務需求-不要設計得太遠。 例如，隨著我們的會員功能從數萬個擴展到數百萬個到數千萬個，我們已經重寫了我們的成員功能。 當我們需要的數以萬計的時候，我們為數千萬的設計本來就很糟糕。 我們更快地交付了每個階段的問題，并且與每個階段所學的相比，重寫的成本很小。 * 您可以在垂直擴展數據庫方面走得很遠，尤其是在最小化聯接使用的情況下，尤其是可以將所有內容放入 RAM 的情況下。 * 僅在必要時才進行分片，并保持簡單。 我們最大的單個表具有超過 1B 的行，并且可以輕松垂直擴展，直到我們每天需要更新/插入數千萬行，達到寫入 IOP 限制。 到那時，我們通過將其拆分為 12 個表在服務級別上進行了分片，并且目前在 2 臺計算機上（每臺都有 6 個表）運行它。 我們可以輕松地將其擴展到 3、4、6，然后是 12 臺機器，而無需更改哈希算法或數據分布，只需復制表即可。 我們沒有任何可衡量的性能下降（讀取或寫入），并且執行此操作的代碼很小，易于理解且易于調試。 每天有超過 700M 的數據庫操作，因此我們離分拆任何其他表都不遠。 * 盡可能避免加入。 我們的內容類型（成員，媒體，評論等）位于單獨的數據庫中，有時在共享計算機上，有時在其自己的計算機上。 比執行聯接要好得多（執行兩個查詢（獲取具有其成員 ID 的評論集，然后從該 ID 集合中獲取所有成員并在應用程序級別將其合并））。 通過將數據存儲在不同的數據庫中，可以輕松地將每個數據庫擴展到一臺計算機。 保持內容類型的可伸縮性也更加容易-我們可以以模塊化的方式添加新的內容類型，因為每種內容類型都是獨立的。 這也與我們的面向服務的方法非常吻合，該服務由數據庫支持。 * 承擔單個工程師的端到端責任。 當一個人擁有一切（CSS，JS，Java，SQL，腳本）時，就沒有等待，瓶頸，調度沖突，管理開銷或“所有權”的分配。 可以采用模塊化方式添加更多項目/人員，而不會影響其他所有人。 * 服務。 擁有一組與業務和使用模式對齊的已知的塊狀協議（針對有線網絡進行了優化）協議，使組裝頁面變得更加容易，并允許您根據業務需求擴展每個服務。 搜索流量大增？ 添加更多搜索服務器。 還可以使您更仔細地考慮使用模式和業務。 * 硬件-保持非常簡單。 沒有花哨的硬件-沒有 SAN，沒有專用設備（用于網絡設備）-我們運行所有戴爾的商品。 假定任何組件都會隨時發生故障，并且具有 N + 1 設計或足夠的資源來彌補故障。 我們的網絡服務器庫可以處理大量失敗-高達 50％。 數據庫為 N + 1，具有重復的熱（基于 DRDB）故障轉移。 服務在多臺計算機上運行多個實例。 負載平衡器和路由器均具有熱備用和自動故障轉移。 我們在不同城市擁有兩個完整的數據中心，一個處于活動 R / W 模式，可處理所有流量，另一個處于最新狀態，R / O 模式可隨時用于流量。 我們每三個月進行一次“故障轉移”，以確保隨時準備好“備份”，并為我們的數據中心提供連續/增量的維護。 * 軟件-保持非常，非常，非常簡單。 有一些您不想自己寫的系統-Apache，Tomcat，Jetty，Lucene，Postgres，memcached，Velocity。 我們自己構建了其他所有內容-分布式服務體系結構，Web 框架等。這并不難做到，您可以理解和控制所有內容。 * 處理。 越少越好。 您需要使用源代碼控制。 您需要成為一個良好的代碼公民。 您需要交付有效的代碼。 您需要傳達您的設計及其工作水平。 “需要”或“需要”沒有太多其他內容。 如果您很聰明，則將對設計進行審查，對代碼進行審查，并編寫測試和適當的監視腳本。 雇用了解您想要這些東西的人，因為它們可以幫助您提供更好的產品，而不是因為它們是“必需品”。 如果您犯了一個錯誤，并且您會犯錯，并且將其修復。 重要的是要找到自己的錯誤，而不要依靠別人為您找到錯誤。 * 設計評論。 邀請所有工程師進行每周設計審查。 如果您有一個項目會影響其他項目（數據庫，內存使用，新的 servlet，新的庫，重要的東西），那么您應該在設計審查時介紹您的設計并進行討論。 這不僅是對整個系統提供指導和監督的好方法，而且是每個人互相學習并了解正在發生的事情的好方法。 * * * 我非常感謝 Andy Gelfond 對 TripAdivsor 所做的工作提供了非常有用的描述。 好工作。 如此注重細節，不難看出為什么 TripAdvisor 如此有用。 謝謝。 TripAdvisor 正在[招聘](http://www.tripadvisor.com/careers/)。 ## 相關文章 * [黑客新聞主題](http://news.ycombinator.com/item?id=2701936) > Postgres，在 6 對（DRDB）機器上運行，每天處理 700M +次查詢 是 DRBD（http://en.wikipedia.org/wiki/DRBD），對嗎？ > 工程師端到端地工作-設計，代碼，測試，監控。 您設計一些東西，然后編寫代碼。 您編寫一些代碼，然后進行測試。 > 工程師跨整個堆棧工作-HTML，CSS，JS，Java，腳本。 如果您不了解某些內容，則可以學習。 > 交付項目的唯一障礙就是您，因為您應該在所有級別上工作-設計，代碼，測試，監視，CSS，JS，Java，SQL，腳本。 don't you end up with dissimilar code all over the place? are you allowing your dev to design the way your apps interact with end users? don't you know that dev rarely design good user interfaces? if the same dev is also responsible for supporting their code throughout its lifetime, don't you eventually get into a situation where that dev/team will do nothing but fix bugs in their existing code and don't have enough time to work on new projects? DRBD 是正確的，謝謝 Progga 嗨，mxx， 我們的系統并不完美-每個團隊都需要決定對他們而言重要的事情并做出選擇。 是的，有時我們確實會得到重復的代碼，但這并沒有您想的那么糟糕。 我們依靠工程師來做正確的事，并且我們進行了大量的代碼審查。 開發人員在其“生命周期”中并不總是對其代碼負責，您對您的項目負責，并且各種各樣的人可能會介入并使用您的代碼來做事-這有其優點和缺點。 系統對我們來說運作良好，而且最重要的是，可以使人們參與其中-您在整個堆棧中工作，并且您可以進行自己的軟件設計和測試。 而且，不，開發人員不會執行 UI 或圖形設計，這種情況在很多年前在我們的網站上有了足夠的 wtf 后就結束了。 “設計”是軟件設計。 其他團隊負責 UI /圖形。 安迪 1）大概是數據庫寫操作從 R / W 數據中心復制到 R / O 數據中心（通過 Postgresql 9.0 復制？）如何處理復制滯后？ 例如，如果我提交了酒店評論，它將被寫入 R / W 數據中心。 現在，如果我再次訪問該酒店的頁面，則可能會將我路由到 R / O 數據中心，由于復制滯后，該數據中心可能尚未接受新提交的評論。 在這種情況下，用戶可能認為他的評論已丟失。 你如何處理？ 2）為什么每周都要重新生成 Lucene 索引？ 謝謝。 嗨安迪， 我們使用 Postgres8.x。 復制是通過一種較舊的查詢復制方法（類似于 slony）完成的，多年來，我們已對其進行了升級（例如，通過批量查詢以提高性能）。 活動數據中心將復制到另一個數據中心和我們的“本地”辦公室數據中心。 有一個滯后-每個人可能要花幾分鐘才能趕上。 但是，數據中心處于 N + 1 配置-只有一個（R / W）正在獲得流量。 另一個（R / O）處于活動狀態并且可以傳輸流量，但是 DNS 僅指向活動的一個-因此，我們沒有遇到您提到的問題，因為我們有兩個數據中心用于可靠性，而不是規模。 我們研究了日志和/或流復制（我相信這就是 Postgres 9 所做的），但是它并不像我們想要的那樣可靠-數據傳輸中的損壞會產生重大影響。 使用查詢復制（并非如此）以及使用查詢復制，我們還可以根據需要手動調整數據（我們需要做幾次）。 我們在北京也有一個數據中心，該數據中心的延遲和連接性很差-考慮到它的情況，查詢復制對我們來說效果更好。 Lucene 索引再生-我們發現，隨著時間的推移，增量更新會導致索引碎片化和性能下降，因此我們每周進行一次完整重建，以使其保持“干凈”。 另外，索引更改（無論是增量重建還是完全重建）都是在脫機狀態下完成的，我們每天重新啟動 lucene 以使用新索引-我們永遠無法獲得“實時”的工作。 我們經營一小堆的 Lucene 包裹式服務，因此沒有停機時間。 很有可能有一種更好的方法可以做到這一點-我們嘗試了許多方法，并且到目前為止，這種方法效果最好。 “每個服務都具有針對業務和/或使用模式進行了優化的 API-例如，獲取成員的評論或位置的評論。大多數服務本質上都是數據庫前面的大型智能緩存，對于 例如，局部 LRU，memcached，數據庫調用在內存局部樹/圖形中； Jgroups 有時在需要時用于使高速緩存保持同步；大多數服務在不同的共享/物理計算機上運行 4 個實例，有時為服務實例分配自己的計算機。 ” 和： “ 40 臺無狀態服務銀行，運行約 100 個實例的?25 服務，Jetty / Java，每天處理 700M +個請求 在 6 對（DRDB）計算機上運行的 Postgres，每天處理 700M +次查詢 “ 我有些困惑：服務進行大量緩存，但是每天的請求數似乎與數據庫上每天的查詢數相匹配。 我猜想也許對數據庫的大量查詢與這些服務無關？ 1.您最初是如何進行負載測試并選擇 Tomcat 進行此類負載的？ 2.當前如何對整個堆棧進行負載測試？ 3.您具有哪些 CI 設置和單元測試？ 4.您是否使用 JMX 或其他方法監視應用程序事件？是否通過 HTTP 將日志事件傳輸到瀏覽器以監視批處理程序的進度。 Thanks. 嗨，您好， 非常感謝您的出色描述！ 來自 Web 公司，我很驚訝地將 Java 視為后端。 您對選擇 Java 作為后端語言的滿意程度如何？ 我真的很喜歡它，但是我很難抗拒更多“炒作”語言（如 Ruby，Python，Scala，JS 等）的誘惑。 我想成千上萬的詞，您會基于 Java 再做一次，為什么或為什么不呢？ > 您是否允許開發人員設計應用程序與最終用戶交互的方式？ 您不知道開發人員很少設計良好的用戶界面嗎？ > 如果同一個開發人員還負責在其整個生命周期內支持其代碼，那么您最終是否會陷入這種情況，即該開發人員/團隊除了修復現有代碼中的錯誤之外什么都不做，沒有足夠的時間來 在新項目上工作？ 通常，將向開發人員提供圖形設計和產品營銷團隊的模型。 “這是它的外觀”。 工程師的職責通常在發布后一周就結束，因為很明顯沒有與此相關的直接問題（尤其是性能問題）。 到那時，您便可以開始其他工作了。 哪一個確實可能是錯誤修復或其他人項目的功能增強。 期望所有工程師都可以使用任何代碼庫工作。 長期代碼擁有權比我在其他地方看到的要少得多。 因此，開發人員最終會看到彼此足夠多的代碼，而這些代碼最終不會因閱讀或使用而異樣。 安迪 感謝您的解釋。 > >我們從未能夠獲得“實時”的工作。 您嘗試了哪種類型的實時 Lucene 實現，但無法使其正常工作？ Lucene 2.9 添加了 NRT（近實時）。 您使用的是早期版本，還是 Lucene NRT 根本不適合您？ 很想在這里詳細了解您的經歷。 安迪，您提到您的運營團隊包括兩名技術工程師和兩名現場工程師-當然，這不能成為整個團隊嗎？ 您能否提供更多有關團隊規模及其組成的見解？ 謝謝你寫的好。 羅伯 Andy. 那真是太棒了。 我的問題之一是，您是否在完全使用開源架構運行 4 9 的正常運行時間基礎架構？ 以及如何確保應用程序響應時間達到目??標。 另外，想知道如何監視基礎架構？ 我將嘗試回答盡可能多的問題： 丹： 服務調用和數據庫調用的數目大致相同是巧合，并且數據庫調用的數目更多是猜測（我們將 db 調用記錄在 Java 代碼中），但這是正確的。 我們的許多網頁進行多個服務調用，而我們的許多服務進行多個數據庫調用，但是每天大約有 1B +內存緩存調用保持了數據庫的負載。 由于我們緩存對象而不是查詢，因此許多對象可能代表幾個數據庫調用。 如果我們不使用 memcached，則可能一天會執行 2B +查詢。 我一直發現有趣的是，將我們從不同來源收集的所有數字進行關聯是多么困難。 Mohan： -當我們開始（11 年前）時，我們使用了標準的 Linux / Apache / Tomcat / Java / Postgres 堆棧。 那時我還沒來得及，但我認為決策周圍沒有太多的結構化流程，我也不認為當時還有許多其他開源選項 -負載測試是一個有趣的領域。 我們有不同的測試工具和測試，測試實驗室，有時我們使用輔助數據中心。 有時我們使用實時數據中心（例如，將 1/2 臺 Web 服務器淘汰掉以查看會發生什么）。 負載測試是在我們認為需要的地方進行的，并且說實話，這是一門藝術。 我們了解到的一件事是，即使重放日志文件，也永遠無法真正進行負載測試。 我堅信一切都會失敗，并確保您有恢復的方法。 -不熟悉“ CI” -監視是通過 Nagios，Cacti 和許多自定義腳本來完成的，這些腳本分析我們的日志并顯示數據。 我可以按 servlet，日期和小時向下鉆取，以獲得頁面請求的總時間，cpu，數據庫，服務調用數據（經過時間和調用次數）。 主持人： -我對 Java 非常滿意，尤其是對于服務。 天哪，強大的線程和狀態支持對于構建高性能服務至關重要。 我不確定如何實現可共享的進程內緩存以及如何使用其他語言處理線程。 我們的服務機每秒可以處理數千個請求，并且仍以 15％的負載運行。 如果我要再做一遍，我會考慮一些腳本語言用于前端工作（我們在該領域的一些實驗并未顯示出許多弊端的實際好處），但是對于服務器工作線程卻能夠保持 狀態（共享內存）對于我們的用例至關重要。 steveo： 謝謝 SteveO :-) Andy： 我們嘗試通過 api 逐步更新索引，但存在很多問題。 這是幾年前的事，我不記得具體情況。 擁有 NRT 對我們來說很好，但并不關鍵。 Robbo：?? 我們過去曾為兩個數據中心配備一名技術運營工程師，但發現我們需要再增加一名：-) 我們有兩個以上的空缺，因為我們計劃擴大規模。 因此，我們有： 2 位數據中心和我們的開發環境（很多 xen 服務器）的技術運營（數據中心）人員 2 位負責軟件基礎架構的“站點運營”工程師。 發布工程由我們的網站運營工程師和各種技術經理（需要給他們做一些有趣的事情）完成。 來自各個團隊的 10 多位工程師可以訪問該網站并提供補丁程序幫助， 發行，軟件開發，數據庫，數據中心等。 對于我們的工作方式，重要的是，軟件團隊從字面上看要是真正的“游戲皮”。 “ Dan： 服務調用和數據庫調用的數量大致相同是巧合，并且數據庫調用的數量更多是猜測（我們將 db 調用記錄在 Java 代碼中），但這是正確的。許多 我們的網頁中有多個服務調用，而我們的許多服務也有多個數據庫調用，但每天大約有 1B +內存緩存調用保持了數據庫的負載。由于我們緩存對象而非查詢，因此許多對象可能代表 幾個數據庫調用。如果我們不使用 memcached，我們可能一天會進行 2B +查詢。我一直發現有趣的是，將我們從不同來源收集的所有數字關聯起來是多么困難。” 謝謝安迪。 同意，關聯是建立對我們系統的理解的關鍵挑戰。 實際上，我覺得這里總是會有一些近似值，因為數字是由具有不同上下文量的不同層產生的，這是我們用來將事物捆綁在一起的上下文。 即使是簡單的東西，例如使用系統時鐘來確定時間段內的順序或相關數據的收集，也是有問題的。 另一個挑戰是在不影響用戶感知性能的情況下捕獲信息。 一個人要么避免捕獲數據，要么接受其中的某些數據可能丟失。 我傾向于默認使用后者，因為有些信息總比沒有好。 大話題，值得啤酒討論！ 最好， Dan. 克里希納坎特： 我們使用多種監視技術，包括用于外部“第三方”監視的 Gomez 以及自定義腳本和工具。 我們的“ 4 9”并不是統一的衡量標準。 有一些功能對我們的業務很重要（基本站點的建立，商務和評論），這實際上是衡量標準的來源。我們的站點非常復雜，具有許多不同的內容類型和功能。 如果基本站點，商務和評論正在運行，則我認為該站點已“啟動”。 更重要的是，我的老板也是如此：-)我不確定其他所有設備的正常運行時間，但是大概是 3 個 9。 關于開源與“商業”解決方案-事實是，它們都失敗了。 永遠不要相信任何組件，尤其是 SAN。 組件聲稱“完全可靠”的越多，由于最終信任它，您可能會遇到更多麻煩。 設計失敗。 正常運行時間可以通過多種方式實現： 三個基本規則：簡單性，圍繞所有組件均發生故障的事實進行設計，并使軟件工程師和管理人員始終承擔起運營責任。 -我們讓事情變得非常簡單-商品硬件，以及軟件的基礎知識（Linus / Apache / Tomcat / Java / Postgres / Lucene / Memcached / jgroups）。 我們僅使用簡單的系統/軟件，我們了解它們的深入工作原理，經過實踐證明，具有良好的運營支持，更重要的是，我們知道疣在哪里，因此我們可以對其進行管理。 -保持操作盡可能簡單和可見（自動），但請確保您可以在任何步驟進行干預。 -我們的許多工程師都具有豐富的操作知識，可以隨時待命，并可以為現場站點及其操作提供幫助。 我們的運維團隊非常小，但“虛擬”運維團隊非常龐大，其中包括許多經理。 團隊中很少有工程師不會感覺到現場的“熱度”。 -假設一切失敗。 我們不僅對所有“關鍵”部分（路由器，負載平衡器，數據庫和其他“關鍵”計算機）進行了加倍（N + 1 配置），而且還可以容忍多臺計算機宕機的 Web 服務器和服務庫。 而且，整個數據中心在 N + 1 配置中翻了一番。 這不僅為我們節省了一些時間（當 BigIP 出現兩次故障時您將不勝感激，并且可以在 5-10 分鐘的停機時間內解決這個問題），而且還使我們能夠進行認真的機器/網絡維護和安全性升級。 Hi Andy, 您的 3 層架構（web- >服務-> db）有多嚴格？ 是為了保持體系結構簡單而實施的，還是為了某些本地的簡化/可管理性而嘗試減少某些地方的層？ 開發人員如何工作？ 在本地啟動這 25 個服務中的一些服務，本地數據庫并針對它們開發 Web 服務器？ 您說過要對服務進行負載平衡：Web 和服務層如何通信？ （http，RMI 甚至是 Corba？）為什么您決定支持硬件的軟件負載平衡？ 感謝您分享所有這些！ Stefan 您好 Stefan， 好問題- 我們的三層體系結構未強制執行。 我們希望看到所有來自服務的數據庫調用。 不幸的是，由于大多數是遺留原因，而且并非所有主要功能都在服務中，有時我們需要做的一些簡單事情不值得將服務組合在一起，因此 Web 服務器確實會進行數據庫調用。 當解決變得很重要時，那些“優先擁有項目”可能會被優先考慮。 但是，我們確實有所謂的“ DBR” db 讀取數據庫。 這些是只讀數據庫，每天更新一次，并且處于負載平衡配置（我認為我們有 3 個），因為我們已經將所有可寫操作移到了服務上。 因此，服務獲得了令狀，大多數讀取得到了，并且有些數據可以直接讀取。 我們有一些常見的服務和數據庫庫，因此，如果您僅在 Web 層上工作，那么您所需要的只是前端。 如果您正在使用某項服務，則除了運行 Web 服務器或測試工具外，您所需要的只是運行自己的服務版本-您的個人 ini 文件可以訪問并混合并與任何地方的服務匹配。 服務接口的更改需要向后兼容，因此效果很好。 如果您需要添加/更改表，則可以對共享數據庫之一進行操作，因為這些更改還需要向后兼容。 很少有人需要運行自己的數據庫服務器。 對于某些不向后兼容的模式更改的項目，還有其他整個流程可付諸實踐，因為現在我們面臨著巨大的實時站點部署挑戰。 這偶爾發生。 服務是 XML / HTTP。 這樣做的目的很簡單，它使我們能夠看到正在發生的事情，并輕松生成測試用例。 但是，恕我直言，一旦您有什么值得編碼的地方，XML 就會像二進制格式一樣流行。 因此，我們現在通過 xstream 進行序列化（那里有很多優點/缺點）。 服務調用是由 Java 接口定義的，我們有一個代理，它將接受方法調用，并根據配置設置將它們分配給服務器。 設置將重試邏輯確定為方法級別（等待時間長短，一臺計算機上多少次退休，多少臺計算機重試）。 負載平衡是通過生成 ini 文件設置來完成的-例如，給定的服務通常將映射到 4-8 臺計算機，并且不同的 Web 服務器將具有不同的順序。 如果其中一個不起作用，它將嘗試下一個，并在一段時間后重置為原始配置。 有點笨拙（它是多年來開發的），存在一些問題，但是非常可靠，并且非常容易通過編輯其配置文件來調整計算機。 我們可以通過旋轉一臺新的服務機并調整一臺 Web 服務器來輕松地在站點上測試服務的新代碼。 對于本地開發，這也非常有用。 由于歷史上的增量開發，我們選擇了軟件負載平衡方，但是我們的負載平衡需求非常復雜，有時需要以臨時方式進行調整，需要開發人員進行修改以供本地使用，并且我們也希望能夠 打開登錄以提供正在發生的事情的詳細信息。 我們已經討論過將其移至負載均衡器的方法，但是我們不了解如何以數據驅動（ini 文件）的方式進行此操作，如何讓每個開發人員都有自己的設置，或允許 Web 服務器調出 任何 HTTP 服務（例如，不在同一網絡上）。 對于更改負載均衡器上的代碼以及如何正確測試它，也存在極大的恐懼。 帖子不錯，謝謝您的分享。 謝謝，安迪， 特別是您對負載均衡器的洞察力非常有趣。 我在一個非常相似的網站上工作，但是房地產和德語（僅德語），可能占您頁面瀏覽量的十分之一，而且我們確實有硬件負載平衡器。 結果是，即使開發人員幾乎不了解 devop，對于開發人員來說，這個主題也是一個（遙遠的）黑匣子，并且是唯一的可操作事情。 此外，還有很多與“開發人員因為開發環境沒有 Big IP 負載平衡器而無法正確測試”有關的問題，您可能可以避免這種情況。 我只能建議您堅持這個決定。 最佳 Stefan 設計審查實踐似乎非常有趣。 我同意我們不需要“ powerpoint”架構師，但有些開發人員更有經驗。 您如何避免沒有大的自我沖突導致拼湊而成的設計？ Hi Andy, 您提到您的內容按內容類型（成員，媒體，評論等）分隔，那么您的 20 種語言呢？ 每種語言都有一個數據庫嗎？ 也就是說，每種內容類型都有 20 個數據庫嗎？ 還是每種內容類型只有一個數據庫（包括所有語言）？ Best, 馬蒂亞斯 嗨，Uberto， 您從事和/或領導的項目的類型取決于您對我們系統的經驗和知識-這樣，如果您是新手或剛離開學校，則可以擁有自己的小型項目，或者與他人一起工作 一個更大的項目的高級工程師。 隨著學習，您將獲得“更大”的項目。 我以與代碼審查相同的方式看待設計審查-您之所以不要這樣做，不是因為期望，而是因為您真正地感覺到它們是幫助您交付最佳代碼的好方法。 我發現，比較成功的工程師是積極尋求代碼和設計審查的工程師。 關于自我。 通過明確我們的工作方式，許多信息在面試過程中被過濾掉了-許多“非常高級”的工程師不想編寫代碼或進行測試，因此他們會轉到其他公司。 我發現，當有人被迫在同行面前討論他們的設計，并且他們需要進行自己的編碼和測試時，設計往往會更簡單，更實用和更清潔。 雖然要求人們回頭重新考慮其設計的某些方面在某種程度上很普遍，但很少有真正的分歧。 我只能想一想我實際上必須介入并做出決定的地方-團隊總是做出一個令我滿意的決定（我可能會以相同的方式做）或我足夠自在（也許不是） 我會做的方式，但效果很好，至少 imo :-)。 我認為這與兩件事有關：一是每個人都真正想做正確的事，人們真正尊重彼此的意見，而我們擁有可借鑒的巨大廣度和經驗。 第二個是我們的“設計”專注于方法/操作，這使事情變得實用。 事實是，您可以使任何語言工作和擴展-Python，Perl，Java，PHP，甚至 Ruby :-)-我們關注的重點是內存使用情況，代碼所在的位置（Web 服務器，服務，離線）， 數據已存儲（數據庫，文本文件，日志文件，內存），通過網絡傳輸的內容，什么樣的緩存（本地，本地 LRU，memcached 等），算法復雜性以及數據模式是什么。 我們很少涉及類和類結構或特定的代碼。 而且，如果您想引進新技術，則需要同時做功課以及為什么不能使我們當前的技術適合您的用例。 是的，我們有時最終會在網站的不同部分出現“不同的設計”。 這并沒有您想的那么糟糕，最后，我更喜歡為團隊提供方法上的靈活性（在多年來已經確定的某些界限之內），尤其是考慮到團隊需要真正感受到其工作的主人翁感。 此外，令人驚訝的是您從不同的方法中學到了什么。 嗨 Matlias， 內容不會按語言劃分，但是會按語言和 POS 來源進行標記。 Hi Andy, 謝謝回答。 我明白了，當您說“避免聯接”時，您是在談論數據庫之間的聯接，不同內容類型之間的聯接，但是顯然每個內容類型數據庫內部都有很多表（包含所有標記為 POS，語言等）。 也就是說，在不同數據庫之間進行聯接非常昂貴，如果它們位于不同的計算機上，聯接成本甚至更高。 然后，由于使用的是 DRDB，因此可以在許多位置（也許是？）以多種語言提供內容，就像您所說的那樣，它可以使您進行重復的熱故障轉移，同時可以減少對不同國家/地區的延遲，因為 您的服務器位置。 我對么？ Hi Andy, 關于內容，您是否實施了一些用于更改數據的捕獲？ 你能評論一下嗎？ 知道您如何處理具有成千上萬個項目（酒店，評論等）的內容版本化將非常有趣。 Best, Matias 我認為允許進行一些不同的設計和代碼復制是一個好主意。 否則，您將獲得嚴格的標準，這將使您的應用程序/代碼不再發展。 看到這發生在其他地方，這就是為什么我要說。 一旦規則變得比創造力，實時思考更重要，發展就不再與業務聯系在一起。 此外，DRY 的難看面孔是強耦合。 國際海事組織的最佳選擇總是介于極端之間。