【轉載】看StackOverflow如何用25臺伺服器撐起5.6億的月PV

雲霏霏發表於2017-02-07

問答社群網路 StackExchange 由 100 多個網站構成,其中包括了 Alexa 排名第 54 的 StackOverflow。StackExchang 有 400 萬使用者,每月 5.6 億 PV,但只用 25 臺伺服器,並且 CPU 負荷並不高。

它沒有使用雲端計算,因為雲端計算可能會拖慢速度,更難優化和更難排除系統故障。

StackOverflow 仍然使用微軟的架構,它非常實際,微軟的基礎設施能有效工作,又足夠廉價,沒有令人信服的理由需要做出改變。但這並不表示它不使用 Linux,它將 Linux 用在有意義的地方。

它的 Windows 伺服器執行的作業系統版本是 Windows 2012 R2,Linux 伺服器執行 Centos 6.4。

網站資料庫 MS SQL 大小 2TB,全都儲存在 SSD 上,它有 11 臺執行 IIS 的 Web 伺服器,2 臺執行 HAProxy 的負載均衡伺服器,2 臺執行 Redis 的快取伺服器。

  StackOverflow 是一個 IT 技術問答網站,使用者可以在網站上提交和回答問題。當下的 StackOverflow 已擁有 400 萬個使用者,4000 萬個回答,月 PV5.6 億,世界排行第 54。然而值得關注的是,支撐他們網站的全部伺服器只有 25 臺,並且都保持著非常低的資源使用率,這是一場高有效性、負載均衡、快取、資料庫、搜尋及高效程式碼上的較量。近日,High Scalability 創始人 Todd Hoff 根據 Marco Cecconi 的演講視訊“ The architecture of StackOverflow”以及 Nick Craver 的博文“ What it takes to run Stack Overflow”總結了 StackOverflow 的成功原因。

  意料之中,也是意料之外,Stack Overflow 仍然重度使用著微軟的產品。他們認為既然微軟的基礎設施可以滿足需求,又足夠便宜,那麼沒有什麼理由去做根本上的改變。而在需要的地方,他們同樣使用了 Linux。究其根本,一切都是為了效能。

  另一個值得關注的地方是,Stack Overflow 仍然使用著縱向擴充套件策略,沒有使用雲。他們使用了 384GB 的記憶體和 2TB 的 SSD 來支撐 SQL Servers,如果使用 AWS 的話,花費可想而知。沒有使用雲的另一個原因是 Stack Overflow 認為雲會一定程度上的降低效能,同時也會給優化和排查系統問題增加難度。此外,他們的架構也並不需要橫向擴充套件。峰值期間是橫向擴充套件的殺手級應用場景,然而他們有著豐富的系統調整經驗去應對。該公司仍然堅持著 Jeff Atwood 的名言——硬體永遠比程式設計師便宜。

  Marco Ceccon 曾提到,在談及系統時,有一件事情必須首先弄明白——需要解決問題的型別。首先,從簡單方面著手,StackExchange 究竟是用來做什麼的——首先是一些主題,然後圍繞這些主題建立社群,最後就形成了這個令人敬佩的問答網站。

其次則是規模相關。StackExchange 在飛速增長,需要處理大量的資料傳輸,那麼這些都是如何完成的,特別是只使用了 25 臺伺服器,下面一起追根揭底:

狀態

  • StackExchange 擁有 110 個站點,以每個月 3 到 4 個的速度增長。
  • 400 萬使用者
  • 800 萬問題
  • 4000 萬答案
  • 世界排名 54 位
  • 每年增長 100%
  • 月 PV 5.6 億萬
  • 大多數工作日期間峰值為 2600 到 3000 請求每秒,作為一個程式設計相關網站,一般情況下工作日的請求都會高於週末
  • 25 臺伺服器
  • SSD 中儲存了 2TB 的 SQL 資料
  • 每個 web server 都配置了 2 個 320G 的 SSD,使用 RAID 1
  • 每個 ElasticSearch 主機都配備了 300GB 的機械硬碟,同時也使用了 SSD
  • Stack Overflow 的讀寫比是 40:60
  • DB Server 的平均 CPU 利用率是 10%
  • 11 個 web server,使用 IIS
  • 2 個負載均衡器,1 個活躍,使用 HAProxy
  • 4 個活躍的資料庫節點,使用 MS SQL
  • 3 臺實現了 tag engine 的應用程式伺服器,所有搜尋都通過 tag
  • 3 臺伺服器通過 ElasticSearch 做搜尋
  • 2 臺使用了 Redis 的伺服器支撐分散式快取和訊息
  • 2 臺 Networks(Nexus 5596 + Fabric Extenders)
  • 2 Cisco 5525-X ASAs 
  • 2 Cisco 3945 Routers
  • 主要服務 Stack Exchange API 的 2 個只讀 SQL Servers
  • VM 用於部署、域控制器、監控、運維資料庫等場合

平臺

  • ElasticSearch
  • Redis
  • HAProxy
  • MS SQL
  • Opserver
  • TeamCity
  • Jil——Fast .NET JSON Serializer,建立在 Sigil 之上
  • Dapper——微型的 ORM

UI

  • UI 擁有一個資訊收件箱,用於新徽章獲得、使用者傳送資訊、重大事件發生時的資訊收取,使用 WebSockets 實現,並通過 Redis 支撐。
  • 搜尋箱通過 ElasticSearch 實現,使用了一個 REST 介面。
  • 因為使用者提出問題的頻率很高,因此很難顯示最新問題,每秒都會有新的問題產生,從而這裡需要開發一個關注使用者行為模式的演算法,只給使用者顯示感興趣的問題。它使用了基於 Tag 的複雜查詢,這也是開發獨立 Tag Engine 的原因。
  • 伺服器端模板用於生成頁面。

伺服器

  • 25 臺伺服器並沒有滿載,CPU 使用率並不高,單計算 SO(Stack Overflow)只需要 5 臺伺服器。
  • 資料庫伺服器資源利用率在 10% 左右,除下執行備份時。
  • 為什麼會這麼低?因為資料庫伺服器足足擁有 384GB 記憶體,同時 web server 的 CPU 利用率也只有 10%-15%。
  • 縱向擴充套件還沒有遇到瓶頸。通常情況下,如此流量使用橫向擴充套件大約需要 100 到 300 臺伺服器。
  • 簡單的系統。基於 .Net,只用了 9 個專案,其他系統可能需要 100 個。之所以使用這麼少系統是為了追求極限的編譯速度,這點需要從系統開始時就進行規劃,每臺伺服器的編譯時間大約是 10 秒。
  • 11 萬行程式碼,對比流量來說非常少。
  • 使用這種極簡的方式主要基於幾個原因。首先,不需要太多測試,因為 Meta.stackoverflow 本來就是一個問題和 bug 討論社群。其次,Meta.stackoverflow 還是一個軟體的測試網站,如果使用者發現問題的話,往往會提出並給予解決方案。
  • 紐約資料中心使用的是 Windows 2012,已經向 2012 R2 升級(Oregon 已經完成了升級),Linux 系統使用的是 Centos 6.4。

SSD

  • 預設使用的是 Intel 330(Web 層等)
  • Intel 520 用於中間層寫入,比如 Elastic Search
  • 資料層使用 Intel 710 和 S3700
  • 系統同時使用了 RAID 1 和 RAID 10(任何4+ 以上的磁碟都使用 RAID 10)。不畏懼故障發生,即使生產環境中使用了上千塊 2.5 英寸 SSD,還沒碰到過一塊失敗的情景。每個模型都使用了 1 個以上的備件,多個磁碟發生故障的情景不在考慮之中。
  • ElasticSearch 在 SSD 上表現的異常出色,因為 SO writes/re-indexes 的操作非常頻繁。
  • SSD 改變了搜尋的使用方式。因為鎖的問題,Luncene.net 並不能支撐 SO 的併發負載,因此他們轉向了 ElasticSearch。在全 SSD 環境下,並不需要圍繞 Binary Reader 建立鎖。

高可用性

  • 異地備份——主資料中心位於紐約,備份資料中心在 Oregon。
  • Redis 有兩個從節點,SQL 有 2 個備份,Tag Engine 有 3 個節點,elastic 有 3 個節點,冗餘一切,並在兩個資料中心同時存在。
  • Nginx 是用於 SSL,終止 SSL 時轉換使用 HAProxy。
  • 並不是主從所有,一些臨時的資料只會放到快取中
  • 所有 HTTP 流量傳送只佔總流量的 77%,還存在 Oregon 資料中心的備份及一些其他的 VPN 流量。這些流量主要由 SQL 和 Redis 備份產生。

資料庫

  • MS SQL Server
  • Stack Exchange 為每個網站都設定了資料庫,因此 Stack Overflow 有一個、Server Fault 有一個,以此類推。
  • 在紐約的主資料中心,每個叢集通常都使用 1 主和 1 只讀備份的配置,同時還會在 Oregon 資料中心也設定一個備份。如果是執行的是 Oregon 叢集,那麼兩個在紐約資料中心的備份都會是隻讀和同步的。
  • 為其他內容準備的資料庫。這裡還存在一個“網路範圍”的資料庫,用於儲存登陸憑證和聚合資料(大部分是 stackexchange.com 使用者檔案或者 API)。
  • Careers Stack Overflow、stackexchange.com 和 Area 51 等都擁有自己獨立的資料庫模式。
  • 模式的變化需要同時提供給所有站點的資料庫,它們需要向下相容,舉個例子,如果需要重新命名一個列,那麼將非常麻煩,這裡需要進行多個操作:增加一個新列,新增作用在兩個列上的程式碼,給新列寫資料,改變程式碼讓新列有效,移除舊列。
  • 並不需要分片,所有事情通過索引來解決,而且資料體積也沒那麼大。如果有 filtered indexes 需求,那麼為什麼不更高效的進行?常見模式只在 DeletionDate = Null 上做索引,其他則通過為列舉指定型別。每項 votes 都設定了 1 個表,比如一張表給 post votes,1 張表給 comment votes。大部分的頁面都可以實時渲染,只為匿名使用者快取,因此,不存在快取更新,只有重查詢。
  • Scores 是非規範化的,因此需要經常查詢。它只包含 IDs 和 dates,post votes 表格當下大約有 56454478 行,使用索引,大部分的查詢都可以在數毫秒內完成。
  • Tag Engine 是完全獨立的,這就意味著核心功能並不依賴任何外部應用程式。它是一個巨大的記憶體結構陣列結構,專為 SO 用例優化,併為重負載組合進行預計算。Tag Engine 是個簡單的 windows 服務,冗餘的執行在多個主機上。CPU 使用率基本上保持在2-5%,3 個主機專門用於冗餘,不負責任何負載。如果所有主機同時發生故障,網路伺服器將把 Tag Engine 載入到記憶體中持續執行。
  • 關於 Dapper 無編譯器校驗查詢與傳統 ORM 的對比。使用編譯器有很多好處,但在執行時仍然會存在 fundamental disconnect 問題。同時更重要的是,由於生成 nasty SQL,通常情況還需要去尋找原始程式碼,而 Query Hint 和 parameterization 控制等能力的缺乏更讓查詢優化變得複雜。

編碼

  • 流程
  • 大部分程式設計師都是遠端工作,自己選擇編碼地點
  • 編譯非常快
  • 然後執行少量的測試
  • 一旦編譯成功,程式碼即轉移至開發交付準備伺服器
  • 通過功能開關隱藏新功能
  • 在相同硬體上作為其他站點測試執行
  • 然後轉移至 Meta.stackoverflow 測試,每天有上千個程式設計師在使用,一個很好的測試環境
  • 如果通過則上線,在更廣大的社群進行測試
  • 大量使用靜態類和方法,為了更簡單及更好的效能
  • 編碼過程非常簡單,因為複雜的部分被打包到庫裡,這些庫被開源和維護。.Net 專案數量很低,因為使用了社群共享的部分程式碼。
  • 開發者同時使用 2 到 3 個顯示器,多個螢幕可以顯著提高生產效率。

快取

  • 快取一切
  • 5 個等級的快取
  • 1 級是網路級快取,快取在瀏覽器、CDN 以及代理伺服器中。
  • 2 級由 .Net 框架 HttpRuntime.Cache 完成,在每臺伺服器的記憶體中。
  • 3 級 Redis,分散式記憶體鍵值儲存,在多個支撐同一個站點的伺服器上共享快取項。
  • 4 級 SQL Server Cache,整個資料庫,所有資料都被放到記憶體中。
  • 5 級 SSD。通常只在 SQL Server 預熱後才生效。
  • 舉個例子,每個幫助頁面都進行了快取,訪問一個頁面的程式碼非常簡單:
  • 使用了靜態的方法和類。從 OOP 角度來看確實很糟,但是非常快並有利於簡潔編碼。
  • 快取由 Redis 和 Dapper 支撐,一個微型 ORM
  • 為了解決垃圾收集問題,模板中 1 個類只使用 1 個副本,被建立和儲存在快取中。監測一切,包括 GC 操。據統計顯示,間接層增加 GC 壓力達到了某個程度時會顯著的降低效能。
  • CDN Hit 。鑑於查詢字串基於檔案內容進行雜湊,只在有新建立時才會被再次取出。每天 3000 萬到 5000 萬 Hit,頻寬大約為 300GB 到 600GB。
  • CDN 不是用來應對 CPU 或I/O負載,而是幫助使用者更快的獲得答案

部署

  • 每天 5 次部署,不去建立過大的應用。主要因為
  • 可以直接的監視效能
  • 儘可能最小化建立,可以工作才是重點
  • 產品建立後再通過強大的指令碼拷貝到各個網頁層,每個伺服器的步驟是:
  • 通過 POST 通知 HAProxy 下架某臺伺服器
  • 延遲 IIS 結束現有請求(大約 5 秒)
  • 停止網站(通過同一個 PSSession 結束所有下游)
  • Robocopy 檔案
  • 開啟網站
  • 通過另一個 POST 做 HAProxy Re-enable
  • 幾乎所有部署都是通過 puppet 或 DSC,升級通常只是大幅度調整 RAID 陣列並通過 PXE boot 安裝,這樣做非常快速。

協作

  • 團隊
  • SRE (System Reliability Engineering):5 人
  • Core Dev(Q&A site)6-7 人
  • Core Dev Mobile:6 人
  • Careers 團隊專門負責 SO Careers 產品開發:7 人
  • Devops 和開發者結合的非常緊密
  • 團隊間變化很大
  • 大部分員工遠端工作
  • 辦公室主要用於銷售,Denver 和 London 除外
  • 一切平等,些許偏向紐約工作者,因為面對面有助於工作交流,但是線上工作影響也並不大
  • 對比可以在同一個辦公室辦公,他們更偏向熱愛產品及有才華的工程師,他們可以很好的衡量利弊
  • 許多人因為家庭而選擇遠端工作,紐約是不錯,但是生活並不寬鬆
  • 辦公室設立在曼哈頓,那是個人才的誕生地。資料中心不能太偏,因為經常會涉及升級
  • 打造一個強大團隊,偏愛極客。早期的微軟就聚集了大量極客,因此他們征服了整個世界
  • Stack Overflow 社群也是個招聘的地點,他們在那尋找熱愛編碼、樂於助人及熱愛交流的人才。

編制預算

  • 預算是專案的基礎。錢只花在為新專案建立基礎設施上,如此低利用率的 web server 還是 3 年前資料中心建立時購入。

測試

  • 快速迭代和遺棄
  • 許多測試都是釋出隊伍完成的。開發擁有一個同樣的 SQL 伺服器,並且執行在相同的 Web 層,因此效能測試並不會糟糕。
  • 非常少的測試。Stack Overflow 並沒有進行太多的單元測試,因為他們使用了大量的靜態程式碼,還有一個非常活躍的社群。
  • 基礎設施改變。鑑於所有東西都有雙份,所以每個舊配置都有備份,並使用了一個快速故障恢復機制。比如,keepalived 可以在負載均衡器中快速回退。
  • 對比定期維護,他們更願意依賴冗餘系統。SQL 備份用一個專門的伺服器進行測試,只為了可以重儲存。計劃做每兩個月一次的全資料中心故障恢復,或者使用完全只讀的第二資料中心。
  • 每次新功能釋出都做單元測試、整合測試盒 UI 測試,這就意味著可以預知輸入的產品功能測試後就會推送到孵化網站,即 meta.stackexchange(原 meta.stackoverflow)。

監視/日誌

  • 當下正在考慮使用 http://logstash.net/做日誌管理,目前使用了一個專門的服務將 syslog UDP 傳輸到 SQL 資料庫中。網頁中為計時新增 header,這樣就可以通過 HAProxy 來捕獲並且融合到 syslog 傳輸中。
  • Opserver 和 Realog 用於顯示測量結果。Realog 是一個日誌展示系統,由 Kyle Brandt 和 Matt Jibson 使用 Go 建立。
  • 日誌通過 HAProxy 負載均衡器藉助 syslog 完成,而不是 IIS,因為其功能比 IIS 更豐富。

關於雲

  • 還是老生常談,硬體永遠比開發者和有效率的程式碼便宜。基於木桶效應,速度肯定受限於某個短板,現有的雲服務基本上都存在容量和效能限制。
  • 如果從開始就使用雲來建設 SO 說不定也會達到現在的水準。但毫無疑問的是,如果達到同樣的效能,使用雲的成本將遠遠高於自建資料中心。

效能至上

  • StackOverflow 是個重度的效能控,主頁載入的時間永遠控制在 50 毫秒內,當下的響應時間是 28 毫秒。
  • 程式設計師熱衷於降低頁面載入時間以及提高使用者體驗。
  • 每個獨立的網路提交都予以計時和記錄,這種計量可以弄清楚提升效能需要修改的地方。
  • 如此低資源利用率的主要原因就是高效的程式碼。web server 的 CPU 平均利用率在5% 到 15% 之間,記憶體使用為 15.5 GB,網路傳輸在 20 Mb/s到 40 Mb/s。SQL 伺服器的 CPU 使用率在5% 到 10% 之間,記憶體使用是 365GB,網路傳輸為 100 Mb/s到 200 Mb/s。這可以帶來 3 個好處:給升級留下很大的空間;在嚴重錯誤發生時可以保持服務可用;在需要時可以快速回檔。

學到的知識

1. 為什麼使用 MS 產品的同時還使用 Redis?什麼好用用什麼,不要做無必要的系統之爭,比如 C# 在 Windows 機器上執行最好,我們使用 IIS;Redis 在*nix 機器上可以得到充分發揮,我們使用*nix。

2. Overkill 即策略。平常的利用率並不能代表什麼,當某些特定的事情發生時,比如備份、重建等完全可以將資源使用拉滿。

3. 堅固的 SSD。所有資料庫都建立在 SSD 之上,這樣可以獲得 0 延時。

4. 瞭解你的讀寫負載。

5. 高效的程式碼意味著更少的主機。只有新專案上線時才會因為特殊需求增加硬體,通常情況下是新增記憶體,但在此之外,高效的程式碼就意味著 0 硬體新增。所以經常只討論兩個問題:為儲存增加新的 SSD;為新專案增加硬體。

6. 不要害怕定製化。SO 在 Tag 上使用複雜查詢,因此專門開發了所需的 Tag Engine。

7. 只做必須做的事情。之所以不需要測試是因為有一個活躍的社群支撐,比如,開發者不用擔心出現“Square Wheel”效應,如果開發者可以製作一個更更輕量級的元件,那就替代吧。

8. 注重硬體知識,比如 IL。一些程式碼使用 IL 而不是C#。聚焦 SQL 查詢計劃。使用 web server 的記憶體轉儲究竟做了些什麼。探索,比如為什麼一個 split 會產生 2GB 的垃圾。

9. 切勿官僚作風。總有一些新的工具是你需要的,比如,一個編輯器,新版本的 Visual Studio,降低提升過程中的一切阻力。

10. 垃圾回收驅動程式設計。SO 在減少垃圾回收成本上做了很多努力,跳過類似 TDD 的實踐,避免抽象層,使用靜態方法。雖然極端,但是確實打造出非常高效的程式碼。

11. 高效程式碼的價值遠遠超出你想象,它可以讓硬體跑的更快,降低資源使用,切記讓程式碼更容易被程式設計師理解。

 

相關文章