Stack Overflow 2016最新架構探秘

這篇文章 主要揭秘Stack Overflow截止到2016年的技術架構。

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

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

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

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

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

圖1現在來給出主要系統的邏輯架構圖，如圖2。

圖2

基本規則

首先給出全局的通用規則：

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

網絡服務

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

負載均衡（HAProxy）

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

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

負載均衡器的設置是相當的簡單。它們監聽各路IPs，并進行路由分發。Stack Overflow還做了負載均衡限流和監控HAProxy的日志做到及時報警。

Web層架構（IIS 8.5，ASP.Net MVC 5.2.3，和.Net 4.6.1）

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

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

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

圖4

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

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

緩存&發布/訂閱（Redis）

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

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

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

Websockets (NetGain)

圖6

Search (Elasticsearch)

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

每個數據中心都有一個Elasticsearch集群，包含三個節點，每個都建有自己的索引。三個Elasticsearch集群全部使用SSD存儲，192GB內存和雙10Gbps網卡。

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

數據庫（SQL Server）

圖7

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