.NET技術+25臺伺服器怎樣支撐世界第54大網站

　　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. 高效程式碼的價值遠遠超出你想象，它可以讓硬體跑的更快，降低資源使用，切記讓程式碼更容易被程式設計師理解。

　　原文連結： StackOverflow Update: 560M Pageviews A Month, 25 Servers, And It's All About Performance