這篇文章主要揭秘Stack Overflow截止到2016年的技術(shù)架構(gòu)。

首先給出一個直觀的數(shù)據(jù)，讓大家有個初步的印象。
相比于2013年11月，Stack Overflow在2016年02月統(tǒng)計數(shù)據(jù)有較大變化，下面給出2016年02月09號一天的數(shù)據(jù)，如下：

• HTTP請求數(shù)209,420,973 (+61,336,090)
• 網(wǎng)頁加載次數(shù) 66,294,789 (+30,199,477)
• HTTP流量發(fā)送有1,240,266,346,053 (+406,273,363,426)字節(jié) (1.24 TB)
• 接收數(shù)據(jù)總量569,449,470,023 (+282,874,825,991) 字節(jié)(569 GB)
• 發(fā)送數(shù)據(jù)總量3,084,303,599,266 (+1,958,311,041,954) 字節(jié) (3.08 TB)
• SQL查詢數(shù)(HTTP請求)504,816,843 (+170,244,740)
• Redis命中數(shù)5,831,683,114 (+5,418,818,063)
• Elastic 查詢次數(shù)17,158,874 (未計入2013年的數(shù)據(jù))
• 標簽引擎請求次數(shù)3,661,134 (+57,716)
• SQL查詢耗時607,073,066 (+48,848,481) 毫秒 (168小時)
• Redis命中耗時10,396,073 (-88,950,843) 毫秒 (2.8 小時)

你很難想象到.NET技術(shù)架構(gòu)能夠在每天6100萬請求的情況下減少757小時的處理時間(相比于2013年)。這些改善既得益于2015年早期的硬件設(shè)備升級，也跟軟件的性能優(yōu)化有極大的關(guān)系。

那么最近兩年在硬件上有什么變化呢？以下為截止到目前為止的硬件列表：

• 4臺數(shù)據(jù)庫服務器（微軟SQL Server），其中兩臺更新硬件配置
• 11臺Web服務器（IIS），都已更新硬件配置
• 2臺分布式緩存和消息處理服務器（Redis），都已更新硬件配置
• 3臺應用服務器（實現(xiàn)了tag引擎功能），其中兩臺為新硬件配置
• 3臺搜索服務器（ElasticSearch），配置同2013年
• 4臺負載均衡服務器（HAProxy），其中新增加的兩臺用于支持CloudFlare的CDN加速服務
• 2臺網(wǎng)絡(luò)交換機（每個都是Cisco Nexus 5596 + Fabric Extenders，并升級網(wǎng)卡10Gbps)2臺Fortinet 800C（替代2臺Cisco 5525-X ASA防火墻）
• 2臺Ciso ASR-1001路由器（替代2臺Cisco 3945路由器)
• 2臺Ciso ASR-1001-x路由器

為了支撐Stack Overflow運行，那需要做點什么呢？其實跟2013年相比并沒有什么顯著變化，只是做了前面提到的硬件升級和程序的性能優(yōu)化。
現(xiàn)有系統(tǒng)一般都不會完全隔離開來，Stack Overflow也不列外。一圖勝千言，下面給出Stack Overflow的整體架構(gòu)效果圖。本篇文章僅給出硬件整理的邏輯架構(gòu)的亮點，具體的硬件細節(jié)部分將在下一篇文章詳細介紹。
圖1是機架A（在2015年2月升級的）的實物圖片展示。

圖1
現(xiàn)在來給出主要系統(tǒng)的邏輯架構(gòu)圖，如圖2。

圖2

基本規(guī)則

首先給出全局的通用規(guī)則：

• 萬事需要備份
• 所有服務器和網(wǎng)絡(luò)交換機要至少2 x 10Gbps帶寬
• 所有服務器配備兩個電源（帶有UPS電源備用）
• 所有服務器在機架A和B上互為冗余
• 所有服務器和服務都有異地雙活（紐約機房和科羅拉多州機房）

網(wǎng)絡(luò)服務

首先，用戶去Stack Overflow網(wǎng)站瀏覽就要通過Internet。為了讓用戶瀏覽網(wǎng)站的速度更快Stack Overflow采用CloudFlare的CDN加速。這里使用CloudFlare服務是因為它們的CDN服務器遍布全球。
緊接著，用戶的HTTP流量通過四大ISP提供商（Level 3，Zayo，Cogent和Lighttower），經(jīng)過四臺路由器。Stack Overflow通過標準的邊界網(wǎng)關(guān)協(xié)議（BGP）來均衡所有的流量以便用戶更有效率的打開網(wǎng)站。Stack Overflow的工程師Nick Craver建議在兩個異地數(shù)據(jù)中心采用一個10 Gbps MPLS，這樣在出現(xiàn)突發(fā)情況下可以快速的恢復和復制數(shù)據(jù)。

負載均衡（HAProxy）

負載均衡使用的HAProxy 1.5.15和CentOS 7，并在HAProxy加入安全傳輸層協(xié)議（TLS/SSL）。后續(xù)會升級HAProxy到1.6版本來支持HTTP/2。

負載均衡器配備2對10Gbps網(wǎng)絡(luò)。Stack Overflow通過加內(nèi)存來有效的解決安全套接層（SSL）問題。緩存安全傳輸層協(xié)議(TLS)會話到內(nèi)存加以重復使用，這樣可以減少對于同一臺客戶端連接的重復計算，到達提升會話的速度和成本。況且RAM相當便宜，實現(xiàn)了雙贏的效果。

負載均衡器的設(shè)置是相當?shù)暮唵?。它們監(jiān)聽各路IPs，并進行路由分發(fā)。Stack Overflow還做了負載均衡限流和監(jiān)控HAProxy的日志做到及時報警。

Web層架構(gòu)（IIS 8.5，ASP.Net MVC 5.2.3，和.Net 4.6.1）

Stack Overflow經(jīng)過負載均衡層導入流量到9臺Web服務器（“primary”服務器），另外兩臺做網(wǎng)站元數(shù)據(jù)等環(huán)境管理。除meta.stackoverflow.com和meta.stackexchange.com外，Stack Overflow、Careers和Stack Exchange網(wǎng)站業(yè)務都在“primary”服務器運行。

在監(jiān)控平臺Opserver上可以看到，Stack Overflow在Web層的分布，見圖3

圖3
更直觀的看下對應的web服務器的圖形展示，見圖4

圖4

服務層（IIS，ASP.Net MVC 5.2.3， Net 4.6.1和HTTP.SYS）

在整體邏輯架構(gòu)圖上可以清晰的看到，緊挨著Web層的是服務層（部署在Window服務器Windows 2012R2上）。其有兩個重要的功能：tag應用服務器（基于http.sys）和API（基于IIS）。為了提升這兩個服務做了非常多的冗余，但不超過9倍的冗余。舉個列子，從數(shù)據(jù)庫加載所有的網(wǎng)頁和對應的tags變化（每n分鐘（當前設(shè)置為2分鐘））是非常耗時的。這里只需要加載三次即可保證安全。Stack Overflow也同時在硬件層做了相關(guān)的優(yōu)化。Tag應用服務是一個比較復雜的topic，這里簡單說下，當你訪問/questions/tagged/java就使用tag應用服務。還有所有/search和導航也都是用的這些數(shù)據(jù)服務。

緩存&發(fā)布/訂閱（Redis）

Stack Overflow在緩存層用Redis，Redis服務器256GB內(nèi)存，采用master/slave結(jié)構(gòu)部署，盡管每個月16000萬的ops，每個實例的CPU使用率也在2%之下。

圖5
Redis所在服務器有L1/L2高速緩存，Web服務的HTTP緩存設(shè)置在一級緩存L1中，Redis緩存在二級緩存L2。當用戶訪問在一級緩存L1中未命中后會去二級緩存中的Redis取值，這些值以Protobuf格式存儲，并以protobuf-dot-net解析。Redis客戶使用的StackExchange.Redis（Stack Overflow內(nèi)部實現(xiàn)并開源了）。如果web服務在L1和L2兩級緩存都未命中，則會直接去原始數(shù)據(jù)源獲取（比如，數(shù)據(jù)庫查詢，API回調(diào)等），然后并把獲取到的結(jié)果緩存到本地和Redis中，這時其它服務未命中L1高速緩存便會去二級緩存L2/Redis中獲取，節(jié)省了調(diào)用數(shù)據(jù)庫查詢或者API回調(diào)的訪問時間。

大部分運行的問答網(wǎng)站都有自己的L1/L2高速緩存，通過L1緩存Key前綴、L2/Redis緩存數(shù)據(jù)庫ID。

盡管Redis主要是用來緩存，但也起到一個消費和訂閱的功能，Redis可以推送一個消息，然后其他訂閱者來訂閱消息（包括下游的Redis從庫在訂閱消息）。

Websockets (NetGain)

Websockets實時的推送消息（比如，頂欄的通知，投票，新的答案和評論）給用戶。
Sockets服務器運行在web層，NetGain是Stack Overflow實現(xiàn)的一個輕量級高性能實時的開源消息中間件。高峰期可達到50萬并發(fā)的websocket連接。
下圖展示的是一周websocket并發(fā)情況：

圖6

Search (Elasticsearch)

Stack Overflow的工程師Nick Craver表示搜索層并沒有激動人心的部分。在web層采用Elasticsearch 1.4，并內(nèi)部實現(xiàn)了高性能的StackExchange.Elastic客戶端，此部分代碼未開源。Stack Overflow使用Elastic來查詢相關(guān)的問答。

每個數(shù)據(jù)中心都有一個Elasticsearch集群，包含三個節(jié)點，每個都建有自己的索引。三個Elasticsearch集群全部使用SSD存儲，192GB內(nèi)存和雙10Gbps網(wǎng)卡。

Stack Overflow使用Elasticsearch代替先前的SQL全排索引，主要因素是：Elasticsearch的擴展性和低成本。

數(shù)據(jù)庫（SQL Server）

SQL Server是Stack Overflow唯一的源數(shù)據(jù)庫，所有Elastic和Redis的數(shù)據(jù)都來自SQL Server。使用微軟的SQL Server監(jiān)控組件AlwaysOn Availability Groups部署了兩個SQL Server集群。每個集群有一個主庫，一個數(shù)據(jù)備份在紐約，另一個數(shù)據(jù)備份在Colorrado數(shù)據(jù)中心。所有備份是異步復制。
第一個集群硬件配置：Dell R720xd服務器，384G內(nèi)存，4TB SSD存儲，雙12核CPU；第二個集群硬件配置：Dell R730xd服務器，768G內(nèi)存，4TB SSD存儲，雙8核CPU。
所有數(shù)據(jù)庫過去24小時CPU監(jiān)控圖如圖7所示，大部分情況CPU使用率較低，偶爾做下緩存任務時會高些。圖中NY-SQL02和04是主庫，01和03是備份庫。

圖7

縱觀全文，Stack Overflow整體架構(gòu)并沒有采用那些非常高端的技術(shù)，卻造就了一個IT界最受歡迎的問答網(wǎng)站之，這是非常不錯的。其中每項使用到的技術(shù)都進行了深入的研究并開源分享給社區(qū)，國內(nèi)的公司可以從中獲得一些啟發(fā)。

感謝杜小芳對本文的審校。

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關(guān)注我們，并與我們的編輯和其他讀者朋友交流（歡迎加入InfoQ讀者交流群（已滿），InfoQ讀者交流群（#2））。