基于.NET的互聯(lián)網(wǎng)服務(wù)平臺架構(gòu)

1、 基于.NET的互聯(lián)網(wǎng)服務(wù)平臺架構(gòu).NET技術(shù)+25臺服務(wù)器怎樣支撐世界第54大網(wǎng)站？架構(gòu)文摘 微信號 ArchDigest功能介紹 每天一篇架構(gòu)領(lǐng)域重磅好文，涉及一線互聯(lián)網(wǎng)公司的互聯(lián)網(wǎng)應(yīng)用架構(gòu)、大數(shù)據(jù)、機器學(xué)習(xí)等各個熱門領(lǐng)域。StackOverflow是一個IT技術(shù)問答網(wǎng)站，用戶可以在網(wǎng)站上提交和回答問題。當(dāng)下的StackOverflow已擁有400萬個用戶，4000萬個回答，月PV5.6億，世界排行第54。然而值得關(guān)注的是，支撐他們網(wǎng)站的全部服務(wù)器只有25臺，并且都保持著非常低的資源使用率，這是一場高有效性、負(fù)載均衡、緩存、數(shù)據(jù)庫、搜索及高效代碼上的較量。本文總結(jié)了StackOverflo

2、w的成功原因。意料之中，也是意料之外，Stack Overflow仍然重度使用著微軟的產(chǎn)品。他們認(rèn)為既然微軟的基礎(chǔ)設(shè)施可以滿足需求，又足夠便宜，那么沒有什么理由去做根本上的改變。而在需要的地方，他們同樣使用了Linux。究其根本，一切都是為了性能。另一個值得關(guān)注的地方是，Stack Overflow仍然使用著縱向擴展策略，沒有使用云。他們使用了384GB的內(nèi)存和2TB的SSD來支撐SQL Servers，如果使用AWS的話，花費可想而知。沒有使用云的另一個原因是Stack Overflow認(rèn)為云會一定程度上的降低性能，同時也會給優(yōu)化和排查系統(tǒng)問題增加難度。此外，他們的架構(gòu)也并不需要橫向擴展。峰

3、值期間是橫向擴展的殺手級應(yīng)用場景，然而他們有著豐富的系統(tǒng)調(diào)整經(jīng)驗去應(yīng)對。該公司仍然堅持著Jeff Atwood的名言硬件永遠(yuǎn)比程序員便宜。Marco Ceccon曾提到，在談及系統(tǒng)時，有一件事情必須首先弄明白需要解決問題的類型。首先，從簡單方面著手，StackExchange究竟是用來做什么的首先是一些主題，然后圍繞這些主題建立社區(qū)，最后就形成了這個令人敬佩的問答網(wǎng)站。其次則是規(guī)模相關(guān)。StackExchange在飛速增長，需要處理大量的數(shù)據(jù)傳輸，那么這些都是如何完成的，特別是只使用了25臺服務(wù)器，下面一起追根揭底：狀態(tài)StackExchange擁有110個站點，以每個月3到4個的速度增長。4

4、00萬用戶800萬問題4000萬答案世界排名54位每年增長100%月PV 5.6億萬大多數(shù)工作日期間峰值為2600到3000請求每秒，作為一個編程相關(guān)網(wǎng)站，一般情況下工作日的請求都會高于周末25臺服務(wù)器SSD中儲存了2TB的SQL數(shù)據(jù)每個web server都配置了2個320G的SSD，使用RAID 1每個ElasticSearch主機都配備了300GB的機械硬盤，同時也使用了SSDStack Overflow的讀寫比是40:60DB Server的平均CPU利用率是10%11個web server，使用IIS2個負(fù)載均衡器，1個活躍，使用HAProxy4個活躍的數(shù)據(jù)庫節(jié)點，使用MS SQL3

5、臺實現(xiàn)了tag engine的應(yīng)用程序服務(wù)器，所有搜索都通過tag3臺服務(wù)器通過ElasticSearch做搜索2臺使用了Redis的服務(wù)器支撐分布式緩存和消息2臺Networks（Nexus 5596 + Fabric Extenders）2 Cisco 5525-X ASAs2 Cisco 3945 Routers主要服務(wù)Stack Exchange API的2個只讀SQL ServersVM用于部署、域控制器、監(jiān)控、運維數(shù)據(jù)庫等場合平臺ElasticSearchRedisHAProxyMS SQLOpserverTeamCityJilFast .NET JSON Serializer，建

6、立在Sigil之上Dapper微型的ORMUIUI擁有一個信息收件箱，用于新徽章獲得、用戶發(fā)送信息、重大事件發(fā)生時的信息收取，使用WebSockets實現(xiàn)，并通過Redis支撐。搜索箱通過 ElasticSearch 實現(xiàn)，使用了一個REST接口。因為用戶提出問題的頻率很高，因此很難顯示最新問題，每秒都會有新的問題產(chǎn)生，從而這里需要開發(fā)一個關(guān)注用戶行為模式的算法，只給用戶顯示感興趣的問題。它使用了基于Tag的復(fù)雜查詢，這也是開發(fā)獨立Tag Engine的原因。服務(wù)器端模板用于生成頁面。服務(wù)器25臺服務(wù)器并沒有滿載，CPU使用率并不高，單計算SO（Stack Overflow）只需要5臺服務(wù)器。

7、數(shù)據(jù)庫服務(wù)器資源利用率在10%左右，除下執(zhí)行備份時。為什么會這么低？因為數(shù)據(jù)庫服務(wù)器足足擁有384GB內(nèi)存，同時web server的CPU利用率也只有10%-15%?？v向擴展還沒有遇到瓶頸。通常情況下，如此流量使用橫向擴展大約需要100到300臺服務(wù)器。簡單的系統(tǒng)?；?Net，只用了9個項目，其他系統(tǒng)可能需要100個。之所以使用這么少系統(tǒng)是為了追求極限的編譯速度，這點需要從系統(tǒng)開始時就進行規(guī)劃，每臺服務(wù)器的編譯時間大約是10秒。11萬行代碼，對比流量來說非常少。使用這種極簡的方式主要基于幾個原因。首先，不需要太多測試，因為Meta.stackoverflow本來就是一個問題和bug討論社區(qū)

8、。其次，Meta.stackoverflow還是一個軟件的測試網(wǎng)站，如果用戶發(fā)現(xiàn)問題的話，往往會提出并給予解決方案。紐約數(shù)據(jù)中心使用的是Windows 2012，已經(jīng)向2012 R2升級（Oregon已經(jīng)完成了升級），Linux系統(tǒng)使用的是Centos 6.4。SSD默認(rèn)使用的是Intel 330（Web層等）Intel 520用于中間層寫入，比如Elastic Search數(shù)據(jù)層使用Intel 710和S3700系統(tǒng)同時使用了RAID 1和RAID 10（任何4+以上的磁盤都使用RAID 10）。不畏懼故障發(fā)生，即使生產(chǎn)環(huán)境中使用了上千塊2.5英寸SSD，還沒碰到過一塊失敗的情景。每個模型都

9、使用了1個以上的備件，多個磁盤發(fā)生故障的情景不在考慮之中。ElasticSearch在SSD上表現(xiàn)的異常出色，因為SO writes/re-indexes的操作非常頻繁。SSD改變了搜索的使用方式。因為鎖的問題，L并不能支撐SO的并發(fā)負(fù)載，因此他們轉(zhuǎn)向了ElasticSearch。在全SSD環(huán)境下，并不需要圍繞Binary Reader建立鎖。高可用性異地備份主數(shù)據(jù)中心位于紐約，備份數(shù)據(jù)中心在Oregon。Redis有兩個從節(jié)點，SQL有2個備份，Tag Engine有3個節(jié)點，elastic有3個節(jié)點，冗余一切，并在兩個數(shù)據(jù)中心同時存在。Nginx是用于SSL，終止SSL時轉(zhuǎn)換使用HAPro

10、xy。并不是主從所有，一些臨時的數(shù)據(jù)只會放到緩存中所有HTTP流量發(fā)送只占總流量的77%，還存在Oregon數(shù)據(jù)中心的備份及一些其他的VPN流量。這些流量主要由SQL和Redis備份產(chǎn)生。數(shù)據(jù)庫MS SQL ServerStack Exchange為每個網(wǎng)站都設(shè)置了數(shù)據(jù)庫，因此Stack Overflow有一個、Server Fault有一個，以此類推。在紐約的主數(shù)據(jù)中心，每個集群通常都使用1主和1只讀備份的配置，同時還會在Oregon數(shù)據(jù)中心也設(shè)置一個備份。如果是運行的是Oregon集群，那么兩個在紐約數(shù)據(jù)中心的備份都會是只讀和同步的。為其他內(nèi)容準(zhǔn)備的數(shù)據(jù)庫。這里還存在一個“網(wǎng)絡(luò)范圍”的數(shù)據(jù)

11、庫，用于儲存登陸憑證和聚合數(shù)據(jù)（大部分是用戶文件或者API）。Careers Stack Overflow、和Area 51等都擁有自己獨立的數(shù)據(jù)庫模式。模式的變化需要同時提供給所有站點的數(shù)據(jù)庫，它們需要向下兼容，舉個例子，如果需要重命名一個列，那么將非常麻煩，這里需要進行多個操作：增加一個新列，添加作用在兩個列上的代碼，給新列寫數(shù)據(jù)，改變代碼讓新列有效，移除舊列。并不需要分片，所有事情通過索引來解決，而且數(shù)據(jù)體積也沒那么大。如果有filtered indexes需求，那么為什么不更高效的進行？常見模式只在DeletionDate = Null上做索引，其他則通過為枚舉指定類型。每項votes

12、都設(shè)置了1個表，比如一張表給post votes，1張表給comment votes。大部分的頁面都可以實時渲染，只為匿名用戶緩存，因此，不存在緩存更新，只有重查詢。Scores是非規(guī)范化的，因此需要經(jīng)常查詢。它只包含IDs和dates，post votes表格當(dāng)下大約有56454478行，使用索引，大部分的查詢都可以在數(shù)毫秒內(nèi)完成。Tag Engine是完全獨立的，這就意味著核心功能并不依賴任何外部應(yīng)用程序。它是一個巨大的內(nèi)存結(jié)構(gòu)數(shù)組結(jié)構(gòu)，專為SO用例優(yōu)化，并為重負(fù)載組合進行預(yù)計算。Tag Engine是個簡單的windows服務(wù)，冗余的運行在多個主機上。CPU使用率基本上保持在2-5%，3

13、個主機專門用于冗余，不負(fù)責(zé)任何負(fù)載。如果所有主機同時發(fā)生故障，網(wǎng)絡(luò)服務(wù)器將把Tag Engine加載到內(nèi)存中持續(xù)運行。關(guān)于Dapper無編譯器校驗查詢與傳統(tǒng)ORM的對比。使用編譯器有很多好處，但在運行時仍然會存在fundamental disconnect問題。同時更重要的是，由于生成nasty SQL，通常情況還需要去尋找原始代碼，而Query Hint和parameterization控制等能力的缺乏更讓查詢優(yōu)化變得復(fù)雜。編碼流程大部分程序員都是遠(yuǎn)程工作，自己選擇編碼地點編譯非?？烊缓筮\行少量的測試一旦編譯成功，代碼即轉(zhuǎn)移至開發(fā)交付準(zhǔn)備服務(wù)器通過功能開關(guān)隱藏新功能在相同硬件上作為其他站點測

14、試運行然后轉(zhuǎn)移至Meta.stackoverflow測試，每天有上千個程序員在使用，一個很好的測試環(huán)境如果通過則上線，在更廣大的社區(qū)進行測試大量使用靜態(tài)類和方法，為了更簡單及更好的性能編碼過程非常簡單，因為復(fù)雜的部分被打包到庫里，這些庫被開源和維護。.Net 項目數(shù)量很低，因為使用了社區(qū)共享的部分代碼。開發(fā)者同時使用2到3個顯示器，多個屏幕可以顯著提高生產(chǎn)效率。緩存緩存一切5個等級的緩存1級是網(wǎng)絡(luò)級緩存，緩存在瀏覽器、CDN以及代理服務(wù)器中。2級由.Net框架 HttpRuntime.Cache完成，在每臺服務(wù)器的內(nèi)存中。3級Redis，分布式內(nèi)存鍵值存儲，在多個支撐同一個站點的服務(wù)器上共享緩

15、存項。4級SQL Server Cache，整個數(shù)據(jù)庫，所有數(shù)據(jù)都被放到內(nèi)存中。5級SSD。通常只在SQL Server預(yù)熱后才生效。舉個例子，每個幫助頁面都進行了緩存，訪問一個頁面的代碼非常簡單：使用了靜態(tài)的方法和類。從OOP角度來看確實很糟，但是非常快并有利于簡潔編碼。緩存由Redis和Dapper支撐，一個微型ORM為了解決垃圾收集問題，模板中1個類只使用1個副本，被建立和保存在緩存中。監(jiān)測一切，包括GC操。據(jù)統(tǒng)計顯示，間接層增加GC壓力達到了某個程度時會顯著的降低性能。CDN Hit 。鑒于查詢字符串基于文件內(nèi)容進行哈希，只在有新建立時才會被再次取出。每天3000萬到5000萬Hit，

16、帶寬大約為300GB到600GB。CDN不是用來應(yīng)對CPU或I/O負(fù)載，而是幫助用戶更快的獲得答案部署每天5次部署，不去建立過大的應(yīng)用。主要因為可以直接的監(jiān)視性能盡可能最小化建立，可以工作才是重點產(chǎn)品建立后再通過強大的腳本拷貝到各個網(wǎng)頁層，每個服務(wù)器的步驟是：通過POST通知HAProxy下架某臺服務(wù)器延遲IIS結(jié)束現(xiàn)有請求（大約5秒）停止網(wǎng)站（通過同一個PSSession結(jié)束所有下游）Robocopy文件開啟網(wǎng)站通過另一個POST做HAProxy Re-enable幾乎所有部署都是通過puppet或DSC，升級通常只是大幅度調(diào)整RAID陣列并通過PXE boot安裝，這樣做非?？焖?。協(xié)作團隊

17、SRE （System Reliability Engineering）：5人Core Dev（Q&A site）6-7人Core Dev Mobile：6人Careers團隊專門負(fù)責(zé)SO Careers產(chǎn)品開發(fā)：7人Devops和開發(fā)者結(jié)合的非常緊密團隊間變化很大大部分員工遠(yuǎn)程工作辦公室主要用于銷售，Denver和London除外一切平等，些許偏向紐約工作者，因為面對面有助于工作交流，但是在線工作影響也并不大對比可以在同一個辦公室辦公，他們更偏向熱愛產(chǎn)品及有才華的工程師，他們可以很好的衡量利弊許多人因為家庭而選擇遠(yuǎn)程工作，紐約是不錯，但是生活并不寬松辦公室設(shè)立在曼哈頓，那是個人才的誕生地。數(shù)

18、據(jù)中心不能太偏，因為經(jīng)常會涉及升級打造一個強大團隊，偏愛極客。早期的微軟就聚集了大量極客，因此他們征服了整個世界Stack Overflow社區(qū)也是個招聘的地點，他們在那尋找熱愛編碼、樂于助人及熱愛交流的人才。編制預(yù)算預(yù)算是項目的基礎(chǔ)。錢只花在為新項目建立基礎(chǔ)設(shè)施上，如此低利用率的web server還是3年前數(shù)據(jù)中心建立時購入。測試快速迭代和遺棄許多測試都是發(fā)布隊伍完成的。開發(fā)擁有一個同樣的SQL服務(wù)器，并且運行在相同的Web層，因此性能測試并不會糟糕。非常少的測試。Stack Overflow并沒有進行太多的單元測試，因為他們使用了大量的靜態(tài)代碼，還有一個非?；钴S的社區(qū)?；A(chǔ)設(shè)施改變。鑒于

19、所有東西都有雙份，所以每個舊配置都有備份，并使用了一個快速故障恢復(fù)機制。比如，keepalived可以在負(fù)載均衡器中快速回退。對比定期維護，他們更愿意依賴冗余系統(tǒng)。SQL備份用一個專門的服務(wù)器進行測試，只為了可以重存儲。計劃做每兩個月一次的全數(shù)據(jù)中心故障恢復(fù)，或者使用完全只讀的第二數(shù)據(jù)中心。每次新功能發(fā)布都做單元測試、集成測試盒UI測試，這就意味著可以預(yù)知輸入的產(chǎn)品功能測試后就會推送到孵化網(wǎng)站，即meta.stackexchange（原meta.stackoverflow）。監(jiān)視/日志當(dāng)下正在考慮使用/做日志管理，目前使用了一個專門的服務(wù)將syslog UDP傳輸?shù)絊QL數(shù)據(jù)庫中。網(wǎng)頁中為計時

20、添加header，這樣就可以通過HAProxy來捕獲并且融合到syslog傳輸中。Opserver和Realog用于顯示測量結(jié)果。Realog是一個日志展示系統(tǒng)，由Kyle Brandt和Matt Jibson使用Go建立。日志通過HAProxy負(fù)載均衡器借助syslog完成，而不是IIS，因為其功能比IIS更豐富。關(guān)于云還是老生常談，硬件永遠(yuǎn)比開發(fā)者和有效率的代碼便宜?；谀就靶?yīng)，速度肯定受限于某個短板，現(xiàn)有的云服務(wù)基本上都存在容量和性能限制。如果從開始就使用云來建設(shè)SO說不定也會達到現(xiàn)在的水準(zhǔn)。但毫無疑問的是，如果達到同樣的性能，使用云的成本將遠(yuǎn)遠(yuǎn)高于自建數(shù)據(jù)中心。性能至上StackOv

21、erflow是個重度的性能控，主頁加載的時間永遠(yuǎn)控制在50毫秒內(nèi)，當(dāng)下的響應(yīng)時間是28毫秒。程序員熱衷于降低頁面加載時間以及提高用戶體驗。每個獨立的網(wǎng)絡(luò)提交都予以計時和記錄，這種計量可以弄清楚提升性能需要修改的地方。如此低資源利用率的主要原因就是高效的代碼。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個好處：給升級留下很大的空間；在嚴(yán)重錯誤發(fā)生時可以保持服務(wù)可用；在需要時可以快速回檔。總結(jié)1. 為什么使用MS產(chǎn)品的同時還使用Redis？什么好