問答社區(qū)網(wǎng)絡(luò) StackExchange 由 100 多個(gè)網(wǎng)站構(gòu)成，其中包括了 Alexa 排名第 54 的 StackOverflow。StackExchang 有 400 萬(wàn)用戶，每月 5.6 億

問答社區(qū)網(wǎng)絡(luò) StackExchange 由 100 多個(gè)網(wǎng)站構(gòu)成，其中包括了 Alexa 排名第 54 的 StackOverflow。StackExchang 有 400 萬(wàn)用戶，每月 5.6 億 PV，但只用 25 臺(tái)服務(wù)器，并且 CPU 負(fù)荷并不高。

它沒有使用云計(jì)算，因?yàn)樵朴?jì)算可能會(huì)拖慢速度，更難優(yōu)化和更難排除系統(tǒng)故障。

StackOverflow 仍然使用微軟的架構(gòu)，它非常實(shí)際，微軟的基礎(chǔ)設(shè)施能有效工作，又足夠廉價(jià)，沒有令人信服的理由需要做出改變。但這并不表示它不使用 Linux，它將 Linux 用在有意義的地方。

它的 Windows 服務(wù)器運(yùn)行的操作系統(tǒng)版本是 Windows 2012 R2，Linux 服務(wù)器運(yùn)行 Centos 6.4。

網(wǎng)站數(shù)據(jù)庫(kù) MS SQL 大小 2TB，全都儲(chǔ)存在 SSD 上，它有 11 臺(tái)運(yùn)行 IIS 的 Web 服務(wù)器，2 臺(tái)運(yùn)行 HAProxy 的負(fù)載均衡服務(wù)器，2 臺(tái)運(yùn)行 Redis 的緩存服務(wù)器。

StackOverflow 是一個(gè) IT 技術(shù)問答網(wǎng)站，用戶可以在網(wǎng)站上提交和回答問題。當(dāng)下的 StackOverflow 已擁有 400 萬(wàn)個(gè)用戶，4000 萬(wàn)個(gè)回答，月 PV5.6 億，世界排行第 54。然而值得關(guān)注的是，支撐他們網(wǎng)站的全部服務(wù)器只有 25 臺(tái)，并且都保持著非常低的資源使用率，這是一場(chǎng)高有效性、負(fù)載均衡、緩存、數(shù)據(jù)庫(kù)、搜索及高效代碼上的較量。近日，High Scalability 創(chuàng)始人 Todd Hoff 根據(jù) Marco Cecconi 的演講視頻 The architecture of StackOverflow”以及 Nick Craver 的博文 What it takes to run Stack Overflow”總結(jié)了 StackOverflow 的成功原因。

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

另一個(gè)值得關(guān)注的地方是，Stack Overflow 仍然使用著縱向擴(kuò)展策略，沒有使用云。他們使用了 384GB 的內(nèi)存和 2TB 的 SSD 來支撐 SQL Servers，如果使用 AWS 的話，花費(fèi)可想而知。沒有使用云的另一個(gè)原因是 Stack Overflow 認(rèn)為云會(huì)一定程度上的降低性能，同時(shí)也會(huì)給優(yōu)化和排查系統(tǒng)問題增加難度。此外，他們的架構(gòu)也并不需要橫向擴(kuò)展。峰值期間是橫向擴(kuò)展的殺手級(jí)應(yīng)用場(chǎng)景，然而他們有著豐富的系統(tǒng)調(diào)整經(jīng)驗(yàn)去應(yīng)對(duì)。該公司仍然堅(jiān)持著 Jeff Atwood 的名言——硬件永遠(yuǎn)比程序員便宜。

Marco Ceccon 曾提到，在談及系統(tǒng)時(shí)，有一件事情必須首先弄明白——需要解決問題的類型。首先，從簡(jiǎn)單方面著手，StackExchange 究竟是用來做什么的——首先是一些主題，然后圍繞這些主題建立社區(qū)，最后就形成了這個(gè)令人敬佩的問答網(wǎng)站。

其次則是規(guī)模相關(guān)。StackExchange 在飛速增長(zhǎng)，需要處理大量的數(shù)據(jù)傳輸，那么這些都是如何完成的，特別是只使用了 25 臺(tái)服務(wù)器，下面一起追根揭底：

狀態(tài)

StackExchange 擁有 110 個(gè)站點(diǎn)，以每個(gè)月 3 到 4 個(gè)的速度增長(zhǎng)。400 萬(wàn)用戶800 萬(wàn)問題4000 萬(wàn)答案世界排名 54 位每年增長(zhǎng) 100%月 PV 5.6 億萬(wàn)大多數(shù)工作日期間峰值為 2600 到 3000 請(qǐng)求每秒，作為一個(gè)編程相關(guān)網(wǎng)站，一般情況下工作日的請(qǐng)求都會(huì)高于周末25 臺(tái)服務(wù)器SSD 中儲(chǔ)存了 2TB 的 SQL 數(shù)據(jù)每個(gè) web server 都配置了 2 個(gè) 320G 的 SSD，使用 RAID 1每個(gè) ElasticSearch 主機(jī)都配備了 300GB 的機(jī)械硬盤，同時(shí)也使用了 SSDStack Overflow 的讀寫比是 40:60DB Server 的平均 CPU 利用率是 10%11 個(gè) web server，使用 IIS2 個(gè)負(fù)載均衡器，1 個(gè)活躍，使用 HAProxy4 個(gè)活躍的數(shù)據(jù)庫(kù)節(jié)點(diǎn)，使用 MS SQL3 臺(tái)實(shí)現(xiàn)了 tag engine 的應(yīng)用程序服務(wù)器，所有搜索都通過 tag3 臺(tái)服務(wù)器通過 ElasticSearch 做搜索2 臺(tái)使用了 Redis 的服務(wù)器支撐分布式緩存和消息2 臺(tái) Networks（Nexus 5596 + Fabric Extenders）2 Cisco 5525-X ASAs 2 Cisco 3945 Routers主要服務(wù) Stack Exchange API 的 2 個(gè)只讀 SQL ServersVM 用于部署、域控制器、監(jiān)控、運(yùn)維數(shù)據(jù)庫(kù)等場(chǎng)合

平臺(tái)

ElasticSearchRedisHAProxyMS SQLOpserverTeamCityJil——Fast .NET JSON Serializer，建立在 Sigil 之上Dapper——微型的 ORMUI

UI 擁有一個(gè)信息收件箱，用于新徽章獲得、用戶發(fā)送信息、重大事件發(fā)生時(shí)的信息收取，使用 WebSockets 實(shí)現(xiàn)，并通過 Redis 支撐。搜索箱通過 ElasticSearch 實(shí)現(xiàn)，使用了一個(gè) REST 接口。因?yàn)橛脩籼岢鰡栴}的頻率很高，因此很難顯示最新問題，每秒都會(huì)有新的問題產(chǎn)生，從而這里需要開發(fā)一個(gè)關(guān)注用戶行為模式的算法，只給用戶顯示感興趣的問題。它使用了基于 Tag 的復(fù)雜查詢，這也是開發(fā)獨(dú)立 Tag Engine 的原因。服務(wù)器端模板用于生成頁(yè)面。

服務(wù)器

25 臺(tái)服務(wù)器并沒有滿載，CPU 使用率并不高，單計(jì)算 SO（Stack Overflow）只需要 5 臺(tái)服務(wù)器。數(shù)據(jù)庫(kù)服務(wù)器資源利用率在 10% 左右，除下執(zhí)行備份時(shí)。為什么會(huì)這么低？因?yàn)閿?shù)據(jù)庫(kù)服務(wù)器足足擁有 384GB 內(nèi)存，同時(shí) web server 的 CPU 利用率也只有 10%-15%?？v向擴(kuò)展還沒有遇到瓶頸。通常情況下，如此流量使用橫向擴(kuò)展大約需要 100 到 300 臺(tái)服務(wù)器。簡(jiǎn)單的系統(tǒng)?；?.Net，只用了 9 個(gè)項(xiàng)目，其他系統(tǒng)可能需要 100 個(gè)。之所以使用這么少系統(tǒng)是為了追求極限的編譯速度，這點(diǎn)需要從系統(tǒng)開始時(shí)就進(jìn)行規(guī)劃，每臺(tái)服務(wù)器的編譯時(shí)間大約是 10 秒。11 萬(wàn)行代碼，對(duì)比流量來說非常少。使用這種極簡(jiǎn)的方式主要基于幾個(gè)原因。首先，不需要太多測(cè)試，因?yàn)?Meta.stackoverflow 本來就是一個(gè)問題和 bug 討論社區(qū)。其次，Meta.stackoverflow 還是一個(gè)軟件的測(cè)試網(wǎng)站，如果用戶發(fā)現(xiàn)問題的話，往往會(huì)提出并給予解決方案。紐約數(shù)據(jù)中心使用的是 Windows 2012，已經(jīng)向 2012 R2 升級(jí)（Oregon 已經(jīng)完成了升級(jí)），Linux 系統(tǒng)使用的是 Centos 6.4。

SSD

默認(rèn)使用的是 Intel 330（Web 層等）Intel 520 用于中間層寫入，比如 Elastic Search數(shù)據(jù)層使用 Intel 710 和 S3700系統(tǒng)同時(shí)使用了 RAID 1 和 RAID 10（任何4+ 以上的磁盤都使用 RAID 10）。不畏懼故障發(fā)生，即使生產(chǎn)環(huán)境中使用了上千塊 2.5 英寸 SSD，還沒碰到過一塊失敗的情景。每個(gè)模型都使用了 1 個(gè)以上的備件，多個(gè)磁盤發(fā)生故障的情景不在考慮之中。ElasticSearch 在 SSD 上表現(xiàn)的異常出色，因?yàn)?SO writes/re-indexes 的操作非常頻繁。SSD 改變了搜索的使用方式。因?yàn)殒i的問題，Luncene.net 并不能支撐 SO 的并發(fā)負(fù)載，因此他們轉(zhuǎn)向了 ElasticSearch。在全 SSD 環(huán)境下，并不需要圍繞 Binary Reader 建立鎖。

高可用性

異地備份——主數(shù)據(jù)中心位于紐約，備份數(shù)據(jù)中心在 Oregon。Redis 有兩個(gè)從節(jié)點(diǎn)，SQL 有 2 個(gè)備份，Tag Engine 有 3 個(gè)節(jié)點(diǎn)，elastic 有 3 個(gè)節(jié)點(diǎn)，冗余一切，并在兩個(gè)數(shù)據(jù)中心同時(shí)存在。Nginx 是用于 SSL，終止 SSL 時(shí)轉(zhuǎn)換使用 HAProxy。并不是主從所有，一些臨時(shí)的數(shù)據(jù)只會(huì)放到緩存中所有 HTTP 流量發(fā)送只占總流量的 77%，還存在 Oregon 數(shù)據(jù)中心的備份及一些其他的 VPN 流量。這些流量主要由 SQL 和 Redis 備份產(chǎn)生。

數(shù)據(jù)庫(kù)

MS SQL ServerStack Exchange 為每個(gè)網(wǎng)站都設(shè)置了數(shù)據(jù)庫(kù)，因此 Stack Overflow 有一個(gè)、Server Fault 有一個(gè)，以此類推。在紐約的主數(shù)據(jù)中心，每個(gè)集群通常都使用 1 主和 1 只讀備份的配置，同時(shí)還會(huì)在 Oregon 數(shù)據(jù)中心也設(shè)置一個(gè)備份。如果是運(yùn)行的是 Oregon 集群，那么兩個(gè)在紐約數(shù)據(jù)中心的備份都會(huì)是只讀和同步的。為其他內(nèi)容準(zhǔn)備的數(shù)據(jù)庫(kù)。這里還存在一個(gè)網(wǎng)絡(luò)范圍”的數(shù)據(jù)庫(kù)，用于儲(chǔ)存登陸憑證和聚合數(shù)據(jù)（大部分是 stackexchange.com 用戶文件或者 API）。Careers Stack Overflow、stackexchange.com 和 Area 51 等都擁有自己獨(dú)立的數(shù)據(jù)庫(kù)模式。模式的變化需要同時(shí)提供給所有站點(diǎn)的數(shù)據(jù)庫(kù)，它們需要向下兼容，舉個(gè)例子，如果需要重命名一個(gè)列，那么將非常麻煩，這里需要進(jìn)行多個(gè)操作：增加一個(gè)新列，添加作用在兩個(gè)列上的代碼，給新列寫數(shù)據(jù)，改變代碼讓新列有效，移除舊列。并不需要分片，所有事情通過索引來解決，而且數(shù)據(jù)體積也沒那么大。如果有 filtered indexes 需求，那么為什么不更高效的進(jìn)行？常見模式只在 DeletionDate = Null 上做索引，其他則通過為枚舉指定類型。每項(xiàng) votes 都設(shè)置了 1 個(gè)表，比如一張表給 post votes，1 張表給 comment votes。大部分的頁(yè)面都可以實(shí)時(shí)渲染，只為匿名用戶緩存，因此，不存在緩存更新，只有重查詢。Scores 是非規(guī)范化的，因此需要經(jīng)常查詢。它只包含 IDs 和 dates，post votes 表格當(dāng)下大約有 56454478 行，使用索引，大部分的查詢都可以在數(shù)毫秒內(nèi)完成。Tag Engine 是完全獨(dú)立的，這就意味著核心功能并不依賴任何外部應(yīng)用程序。它是一個(gè)巨大的內(nèi)存結(jié)構(gòu)數(shù)組結(jié)構(gòu)，專為 SO 用例優(yōu)化，并為重負(fù)載組合進(jìn)行預(yù)計(jì)算。Tag Engine 是個(gè)簡(jiǎn)單的 windows 服務(wù)，冗余的運(yùn)行在多個(gè)主機(jī)上。CPU 使用率基本上保持在2-5%，3 個(gè)主機(jī)專門用于冗余，不負(fù)責(zé)任何負(fù)載。如果所有主機(jī)同時(shí)發(fā)生故障，網(wǎng)絡(luò)服務(wù)器將把 Tag Engine 加載到內(nèi)存中持續(xù)運(yùn)行。關(guān)于 Dapper 無(wú)編譯器校驗(yàn)查詢與傳統(tǒng) ORM 的對(duì)比。使用編譯器有很多好處，但在運(yùn)行時(shí)仍然會(huì)存在 fundamental disconnect 問題。同時(shí)更重要的是，由于生成 nasty SQL，通常情況還需要去尋找原始代碼，而 Query Hint 和 parameterization 控制等能力的缺乏更讓查詢優(yōu)化變得復(fù)雜。編碼

流程大部分程序員都是遠(yuǎn)程工作，自己選擇編碼地點(diǎn)編譯非?？烊缓筮\(yùn)行少量的測(cè)試一旦編譯成功，代碼即轉(zhuǎn)移至開發(fā)交付準(zhǔn)備服務(wù)器通過功能開關(guān)隱藏新功能在相同硬件上作為其他站點(diǎn)測(cè)試運(yùn)行然后轉(zhuǎn)移至 Meta.stackoverflow 測(cè)試，每天有上千個(gè)程序員在使用，一個(gè)很好的測(cè)試環(huán)境如果通過則上線，在更廣大的社區(qū)進(jìn)行測(cè)試大量使用靜態(tài)類和方法，為了更簡(jiǎn)單及更好的性能編碼過程非常簡(jiǎn)單，因?yàn)閺?fù)雜的部分被打包到庫(kù)里，這些庫(kù)被開源和維護(hù)。.Net 項(xiàng)目數(shù)量很低，因?yàn)槭褂昧松鐓^(qū)共享的部分代碼。開發(fā)者同時(shí)使用 2 到 3 個(gè)顯示器，多個(gè)屏幕可以顯著提高生產(chǎn)效率。緩存

緩存一切5 個(gè)等級(jí)的緩存1 級(jí)是網(wǎng)絡(luò)級(jí)緩存，緩存在瀏覽器、CDN 以及代理服務(wù)器中。2 級(jí)由 .Net 框架 HttpRuntime.Cache 完成，在每臺(tái)服務(wù)器的內(nèi)存中。3 級(jí) Redis，分布式內(nèi)存鍵值存儲(chǔ)，在多個(gè)支撐同一個(gè)站點(diǎn)的服務(wù)器上共享緩存項(xiàng)。4 級(jí) SQL Server Cache，整個(gè)數(shù)據(jù)庫(kù)，所有數(shù)據(jù)都被放到內(nèi)存中。5 級(jí) SSD。通常只在 SQL Server 預(yù)熱后才生效。舉個(gè)例子，每個(gè)幫助頁(yè)面都進(jìn)行了緩存，訪問一個(gè)頁(yè)面的代碼非常簡(jiǎn)單：使用了靜態(tài)的方法和類。從 OOP 角度來看確實(shí)很糟，但是非?？觳⒂欣诤?jiǎn)潔編碼。緩存由 Redis 和 Dapper 支撐，一個(gè)微型 ORM為了解決垃圾收集問題，模板中 1 個(gè)類只使用 1 個(gè)副本，被建立和保存在緩存中。監(jiān)測(cè)一切，包括 GC 操。據(jù)統(tǒng)計(jì)顯示，間接層增加 GC 壓力達(dá)到了某個(gè)程度時(shí)會(huì)顯著的降低性能。CDN Hit 。鑒于查詢字符串基于文件內(nèi)容進(jìn)行哈希，只在有新建立時(shí)才會(huì)被再次取出。每天 3000 萬(wàn)到 5000 萬(wàn) Hit，帶寬大約為 300GB 到 600GB。CDN 不是用來應(yīng)對(duì) CPU 或I/O負(fù)載，而是幫助用戶更快的獲得答案部署

每天 5 次部署，不去建立過大的應(yīng)用。主要因?yàn)榭梢灾苯拥谋O(jiān)視性能盡可能最小化建立，可以工作才是重點(diǎn)產(chǎn)品建立后再通過強(qiáng)大的腳本拷貝到各個(gè)網(wǎng)頁(yè)層，每個(gè)服務(wù)器的步驟是：通過 POST 通知 HAProxy 下架某臺(tái)服務(wù)器延遲 IIS 結(jié)束現(xiàn)有請(qǐng)求（大約 5 秒）停止網(wǎng)站（通過同一個(gè) PSSession 結(jié)束所有下游）Robocopy 文件開啟網(wǎng)站通過另一個(gè) POST 做 HAProxy Re-enable幾乎所有部署都是通過 puppet 或 DSC，升級(jí)通常只是大幅度調(diào)整 RAID 陣列并通過 PXE boot 安裝，這樣做非常快速。協(xié)作

團(tuán)隊(duì)SRE （System Reliability Engineering）：5 人Core Dev（Q&A site）6-7 人Core Dev Mobile：6 人Careers 團(tuán)隊(duì)專門負(fù)責(zé) SO Careers 產(chǎn)品開發(fā)：7 人Devops 和開發(fā)者結(jié)合的非常緊密團(tuán)隊(duì)間變化很大大部分員工遠(yuǎn)程工作辦公室主要用于銷售，Denver 和 London 除外一切平等，些許偏向紐約工作者，因?yàn)槊鎸?duì)面有助于工作交流，但是在線工作影響也并不大對(duì)比可以在同一個(gè)辦公室辦公，他們更偏向熱愛產(chǎn)品及有才華的工程師，他們可以很好的衡量利弊許多人因?yàn)榧彝ザx擇遠(yuǎn)程工作，紐約是不錯(cuò)，但是生活并不寬松辦公室設(shè)立在曼哈頓，那是個(gè)人才的誕生地。數(shù)據(jù)中心不能太偏，因?yàn)榻?jīng)常會(huì)涉及升級(jí)打造一個(gè)強(qiáng)大團(tuán)隊(duì)，偏愛極客。早期的微軟就聚集了大量極客，因此他們征服了整個(gè)世界Stack Overflow 社區(qū)也是個(gè)招聘的地點(diǎn)，他們?cè)谀菍ふ覠釔劬幋a、樂于助人及熱愛交流的人才。

編制預(yù)算

預(yù)算是項(xiàng)目的基礎(chǔ)。錢只花在為新項(xiàng)目建立基礎(chǔ)設(shè)施上，如此低利用率的 web server 還是 3 年前數(shù)據(jù)中心建立時(shí)購(gòu)入。測(cè)試

快速迭代和遺棄許多測(cè)試都是發(fā)布隊(duì)伍完成的。開發(fā)擁有一個(gè)同樣的 SQL 服務(wù)器，并且運(yùn)行在相同的 Web 層，因此性能測(cè)試并不會(huì)糟糕。非常少的測(cè)試。Stack Overflow 并沒有進(jìn)行太多的單元測(cè)試，因?yàn)樗麄兪褂昧舜罅康撵o態(tài)代碼，還有一個(gè)非?；钴S的社區(qū)。基礎(chǔ)設(shè)施改變。鑒于所有東西都有雙份，所以每個(gè)舊配置都有備份，并使用了一個(gè)快速故障恢復(fù)機(jī)制。比如，keepalived 可以在負(fù)載均衡器中快速回退。對(duì)比定期維護(hù)，他們更愿意依賴冗余系統(tǒng)。SQL 備份用一個(gè)專門的服務(wù)器進(jìn)行測(cè)試，只為了可以重存儲(chǔ)。計(jì)劃做每?jī)蓚€(gè)月一次的全數(shù)據(jù)中心故障恢復(fù)，或者使用完全只讀的第二數(shù)據(jù)中心。每次新功能發(fā)布都做單元測(cè)試、集成測(cè)試盒 UI 測(cè)試，這就意味著可以預(yù)知輸入的產(chǎn)品功能測(cè)試后就會(huì)推送到孵化網(wǎng)站，即 meta.stackexchange（原 meta.stackoverflow）。監(jiān)視/日志

當(dāng)下正在考慮使用 http://logstash.net/做日志管理，目前使用了一個(gè)專門的服務(wù)將 syslog UDP 傳輸?shù)?SQL 數(shù)據(jù)庫(kù)中。網(wǎng)頁(yè)中為計(jì)時(shí)添加 header，這樣就可以通過 HAProxy 來捕獲并且融合到 syslog 傳輸中。Opserver 和 Realog 用于顯示測(cè)量結(jié)果。Realog 是一個(gè)日志展示系統(tǒng)，由 Kyle Brandt 和 Matt Jibson 使用 Go 建立。日志通過 HAProxy 負(fù)載均衡器借助 syslog 完成，而不是 IIS，因?yàn)槠涔δ鼙?IIS 更豐富。關(guān)于云

還是老生常談，硬件永遠(yuǎn)比開發(fā)者和有效率的代碼便宜?；谀就靶?yīng)，速度肯定受限于某個(gè)短板，現(xiàn)有的云服務(wù)基本上都存在容量和性能限制。如果從開始就使用云來建設(shè) SO 說不定也會(huì)達(dá)到現(xiàn)在的水準(zhǔn)。但毫無(wú)疑問的是，如果達(dá)到同樣的性能，使用云的成本將遠(yuǎn)遠(yuǎn)高于自建數(shù)據(jù)中心。性能至上

StackOverflow 是個(gè)重度的性能控，主頁(yè)加載的時(shí)間永遠(yuǎn)控制在 50 毫秒內(nèi)，當(dāng)下的響應(yīng)時(shí)間是 28 毫秒。程序員熱衷于降低頁(yè)面加載時(shí)間以及提高用戶體驗(yàn)。每個(gè)獨(dú)立的網(wǎng)絡(luò)提交都予以計(jì)時(shí)和記錄，這種計(jì)量可以弄清楚提升性能需要修改的地方。如此低資源利用率的主要原因就是高效的代碼。web server 的 CPU 平均利用率在5% 到 15% 之間，內(nèi)存使用為 15.5 GB，網(wǎng)絡(luò)傳輸在 20 Mb/s到 40 Mb/s。SQL 服務(wù)器的 CPU 使用率在5% 到 10% 之間，內(nèi)存使用是 365GB，網(wǎng)絡(luò)傳輸為 100 Mb/s到 200 Mb/s。這可以帶來 3 個(gè)好處：給升級(jí)留下很大的空間；在嚴(yán)重錯(cuò)誤發(fā)生時(shí)可以保持服務(wù)可用；在需要時(shí)可以快速回檔。我更愿意把Stack Overflow看作是能夠運(yùn)行于大規(guī)模數(shù)據(jù)下，但本身并不算大規(guī)模的（running with scale but not at scale）。意思是我們的網(wǎng)站非常有效率，但至少目前為止，我們的規(guī)模還不夠大”。讓我們通過一些數(shù)字來介紹Stack Overflow當(dāng)前是一個(gè)怎樣的規(guī)模吧。以下是一些核心的數(shù)字，來自于不久前在一整天（24小時(shí)）內(nèi)的統(tǒng)計(jì)，準(zhǔn)確說是2013年11月12日。這是一個(gè)典型的工作日，并且只統(tǒng)計(jì)了我們活動(dòng)的數(shù)據(jù)中心，也就是我們自己的服務(wù)器。那些對(duì)CDN節(jié)點(diǎn)的請(qǐng)求和流量被排除在外，因?yàn)樗鼈儾⒉恢苯釉L問我們的網(wǎng)絡(luò)。

負(fù)載均衡器接受了148,084,833次HTTP請(qǐng)求其中36,095,312次是加載頁(yè)面833,992,982,627 bytes (776 GB) 的HTTP流量用于發(fā)送總共接收了286,574,644,032 bytes (267 GB) 數(shù)據(jù)總共發(fā)送了1,125,992,557,312 bytes (1,048 GB) 數(shù)據(jù)334,572,103次SQL查詢（僅包含來自于HTTP請(qǐng)求的）412,865,051次Redis請(qǐng)求3,603,418次標(biāo)簽引擎請(qǐng)求耗時(shí)558,224,585 ms (155 hours) 在SQL查詢上耗時(shí)99,346,916 ms (27 hours) 在Redis請(qǐng)求上耗時(shí)132,384,059 ms (36 hours) 在標(biāo)簽引擎請(qǐng)求上耗時(shí)2,728,177,045 ms (757 hours) 在ASP.Net程序處理上（我覺得應(yīng)該發(fā)表一篇文章介紹我們?nèi)绾慰焖俨杉@些數(shù)據(jù)，以及為什么值得耗費(fèi)精力去獲取它們）

注意以上數(shù)字包括了整個(gè)Stack Exchange網(wǎng)絡(luò)，但那并不是我們?nèi)康?。除此之外，這些數(shù)字也僅僅來自于我們?yōu)榱藱z測(cè)性能而記錄的HTTP請(qǐng)求。哇，一天有這么多個(gè)小時(shí)，你們?cè)趺醋龅降模?rdquo;我們把這叫做魔法，當(dāng)然有些人喜歡說成許多個(gè)有多核處理器的服務(wù)器”，但我們依然堅(jiān)持這是魔法。以下是那個(gè)數(shù)據(jù)中心里運(yùn)行Stack Exchange網(wǎng)絡(luò)的設(shè)備：

4個(gè)MS SQL 服務(wù)器11個(gè)IIS服務(wù)器2個(gè)Redis服務(wù)器3個(gè)標(biāo)簽引擎服務(wù)（任何針對(duì)標(biāo)簽的請(qǐng)求都會(huì)訪問它們，比如/questions/tagged/c++）3個(gè)ElasticSearch服務(wù)器2個(gè)負(fù)載均衡器（HAProxy）2個(gè)交換機(jī)（Nexus 5596和Fabric Extenders）2個(gè)Cisco 5525-X ASA (可看作是防火墻)2個(gè)Cisco 3945 Router有圖有真相：

我們不僅僅運(yùn)行網(wǎng)站，旁邊架子上還有一些運(yùn)行著虛擬機(jī)的服務(wù)器和其他設(shè)備，它們并不直接服務(wù)于網(wǎng)站，而是進(jìn)行部署、域名控制、監(jiān)控、操作數(shù)據(jù)庫(kù)等其他工作。上面列表中的兩個(gè)數(shù)據(jù)庫(kù)服務(wù)器之前一直都是用作備份，直到最近才作為只讀的負(fù)載（主要用于Stack Exchange API），于是我們可以不需要太多考慮便繼續(xù)擴(kuò)大規(guī)模了。Web服務(wù)器有兩個(gè)分別用于開發(fā)和存儲(chǔ)元數(shù)據(jù)，運(yùn)行負(fù)載非常低。

讓我們?cè)賮砜偨Y(jié)一下：

核心設(shè)備

如果除去那些多余的設(shè)備，以下是Stack Exchange運(yùn)行需要的（保持目前的性能水平）：

2個(gè)MS SQL服務(wù)器（Stack Overflow在一臺(tái)，其他的在另一臺(tái)，實(shí)際上只需一臺(tái)機(jī)器運(yùn)行還能有富余）2個(gè)Web服務(wù)器（或許3個(gè)吧，不過我有信心2個(gè)足矣）1個(gè)Redis服務(wù)器1個(gè)標(biāo)簽引擎服務(wù)器1個(gè)ElasticSearch服務(wù)器1個(gè)負(fù)載均衡器1個(gè)交換機(jī)1個(gè)ASA1個(gè)路由器（我們真該找個(gè)機(jī)會(huì)嘗試這個(gè)配置，關(guān)閉部分設(shè)備，看看極限在哪）

現(xiàn)在還有一些虛擬機(jī)運(yùn)行在后臺(tái)，執(zhí)行一些輔助功能，比如域名控制等等。但那都是些相當(dāng)?shù)拓?fù)載的任務(wù)，我們就不做討論了，這里把重心放在Stack Overflow本身，看看它是怎樣全速加載出頁(yè)面的。如果你希望更精確全面，可以增加一個(gè)VMware虛擬機(jī)進(jìn)來，用于執(zhí)行所有的輔助工作。這樣看來并不需要很多機(jī)器，但是這些機(jī)器的規(guī)格通常在云上難以實(shí)現(xiàn)，除非你有足夠多的錢。以下是這些增強(qiáng)型”服務(wù)器簡(jiǎn)要的配置介紹：

數(shù)據(jù)庫(kù)服務(wù)器有384GB內(nèi)存和1.8TB的SSD硬盤Redis服務(wù)器有96GB內(nèi)存ElasticSearch服務(wù)器有196GB內(nèi)存標(biāo)簽引擎服務(wù)器有著我們能買得起的最快的處理器交換機(jī)每個(gè)端口有10Gb的帶寬Web服務(wù)器不是很特別，有32GB內(nèi)存、2個(gè)4核處理器和300GB的SSD硬盤有些服務(wù)器有2個(gè)10Gb帶寬的接口（比如數(shù)據(jù)庫(kù)），其他有4個(gè)1Gb帶寬的20Gb的帶寬太多余了？你還真特么說對(duì)了，活動(dòng)的數(shù)據(jù)庫(kù)服務(wù)器平均只利用了20Gb通道中的100-200Mb。然而，像備份、重建等等操作，根據(jù)當(dāng)前內(nèi)存和SSD硬盤的情況，可以使帶寬完全飽和，所以說這樣設(shè)計(jì)還是有意義的。

存儲(chǔ)設(shè)備

我們目前有大約2TB的數(shù)據(jù)庫(kù)存儲(chǔ)（第一個(gè)集群有18塊SSD硬盤—— 總共1.63TB，使用1.06TB；第二個(gè)集群由4塊SSD硬盤組成—— 總共1.45TB，使用889GB），這是我們?cè)谠品?wù)器上需要的（嗯哼，又要吐槽價(jià)格了吧），請(qǐng)記住這全部都是SSD硬盤。歸功于存儲(chǔ)器良好的表現(xiàn)，我們數(shù)據(jù)庫(kù)的平均寫入時(shí)間是0毫秒，甚至超出我們能度量的精度了。算上內(nèi)存中的數(shù)據(jù)以及兩級(jí)緩存，Stack Overflow中實(shí)際的數(shù)據(jù)庫(kù)讀寫比例是40:60。你沒看錯(cuò)，60%是寫操作（點(diǎn)此了解讀寫比）。此外，每個(gè)Web服務(wù)器都有兩塊320GB SSD硬盤組成的RAID1。ElasticSearch在每個(gè)區(qū)塊大約需要300GB的容量，由于我們會(huì)非常頻繁的寫入或重建索引，SSD硬盤在這里是更好的選擇。

值得注意的是我們擁有一個(gè)SAN（存儲(chǔ)區(qū)域網(wǎng)絡(luò)）連接到核心網(wǎng)絡(luò)，那就是 Equal Logic PS6110X，它有24個(gè)可熱交換的10K SAS磁盤和2個(gè)10Gb的控制器。這個(gè)設(shè)備僅僅被VM服務(wù)器用作共享儲(chǔ)存空間以保證虛擬機(jī)高度的可用性，但并不實(shí)際支撐網(wǎng)站的運(yùn)行。換句話說，如果SAN掛掉了，在一段時(shí)間內(nèi)網(wǎng)站甚至無(wú)法察覺（只有虛擬機(jī)中的域名控制器能感知到）。

整合到一起

這所有的設(shè)備在一起是為了什么？性能。我們需要很高的性能，這是一個(gè)對(duì)我們來說很重要的特性。所有站點(diǎn)的首頁(yè)都是問題頁(yè)面，我們內(nèi)部把它親切地稱作Question/Show（路由的名字）。在11月12日，這個(gè)頁(yè)面平均渲染時(shí)間是28毫秒，而我們的要求是至多50ms。為了使用戶獲得更好的體驗(yàn)，我們盡一切可能縮短頁(yè)面加載的時(shí)間，哪怕只有一毫秒。在和性能有關(guān)的問題上，我們所有的開發(fā)人員都是錙銖必較”的，這也有助于我們的網(wǎng)站保持快速響應(yīng)。以下是一些Stack Overflow上熱門頁(yè)面的平均渲染時(shí)間，數(shù)據(jù)還是來自于前面統(tǒng)計(jì)的那24小時(shí)：

Question/Show: 28 ms (2970萬(wàn)次點(diǎn)擊)User Profiles: 39 ms (170萬(wàn)次點(diǎn)擊)Question List: 78 ms (110萬(wàn)次點(diǎn)擊)Home page: 65 ms (100萬(wàn)次點(diǎn)擊) （這對(duì)我們來說已經(jīng)很慢了，Kevin Montrose正在著手修復(fù)這個(gè)問題）憑借對(duì)每一次請(qǐng)求的時(shí)間線的記錄，我們能夠準(zhǔn)確觀察到頁(yè)面加載的過程。我們需要這樣的數(shù)據(jù)，否則難道靠腦補(bǔ)來做決定嗎？有數(shù)據(jù)在手，我們就可以這樣監(jiān)控性能：

如果你對(duì)某個(gè)特定頁(yè)面的數(shù)據(jù)感興趣，我也很樂意發(fā)布出來。但這里我重點(diǎn)關(guān)注渲染時(shí)間，因?yàn)樗硎疚覀兊姆?wù)器需要多久來生成一個(gè)網(wǎng)頁(yè)。網(wǎng)絡(luò)傳輸速度是一個(gè)完全不同的話題了（盡管不得不承認(rèn)它也有很大的關(guān)系），不過將來我會(huì)講到的。

增長(zhǎng)空間

非常值得一提的是我們這些服務(wù)器運(yùn)行時(shí)的使用率都非常低。比如Web服務(wù)器的CPU平均使用率為5-15%，內(nèi)存只使用了15.5GB，網(wǎng)絡(luò)流量只有20-40Mb/s；而數(shù)據(jù)庫(kù)服務(wù)器CPU平均使用率為5-10%，使用了365GB內(nèi)存，以及100-200Mb/s的網(wǎng)絡(luò)。這使我們能做到幾件重要的事情：在網(wǎng)站規(guī)模增大時(shí)不至于需要馬上升級(jí)設(shè)備；當(dāng)出現(xiàn)問題時(shí)（錯(cuò)誤的查詢、代碼以及攻擊等等，無(wú)論是什么樣的問題），我們能保持網(wǎng)站始終不掛；在必要的時(shí)候降低功耗。這里有個(gè)我們Web層的監(jiān)控項(xiàng)目：

利用率如此之低的主要原因是高效的代碼。盡管本文的主題并不是這個(gè)，但是高效的代碼對(duì)挖掘服務(wù)器的性能也有著決定性的作用。做一件非必要的事情所損失的，居然比無(wú)所作為還要多——把這引申到代碼中就是說，你需要把它們改進(jìn)得更高效了。這些損失或者消耗可以是能源、硬件（你需要更多更快的服務(wù)器）、開發(fā)人員理解代碼更困難（平心而論，這個(gè)有兩面性，高效的代碼并不一定那么簡(jiǎn)單），以及緩慢的頁(yè)面渲染——可能導(dǎo)致用戶更少地瀏覽網(wǎng)站其他頁(yè)面甚至再也不訪問你的網(wǎng)站了。低效率代碼帶來的損失可能比你想象的大很多。