首先給出一個直觀的數據，讓大家有個初步的印象。
相比於 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 路由器
爲了支撐 Stack Overflow 運行，那需要做點什麼呢？其實跟 2013 年相比並沒有什麼顯著變化，只是做了前面提到的硬件升級和程序的性能優化。
現有系統一般都不會完全隔離開來，Stack Overflow 也不列外。一圖勝千言，下面給出 Stack Overflow 的整體架構效果圖。本篇文章僅給出硬件整理的邏輯架構的亮點，具體的硬件細節部分將在下一篇文章詳細介紹。
圖 1 是機架A（在 2015 年 2 月升級的）的實物圖片展示。
圖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% 之下。
圖5
Redis 所在服務器有 L1/L2 高速緩存，Web 服務的 HTTP 緩存設置在一級緩存 L1 中，Redis 緩存在二級緩存 L2。當用戶訪問在一級緩存 L1 中未命中後會去二級緩存中的 Redis 取值，這些值以 Protobuf 格式存儲，並以 protobuf-dot-net 解析。Redis 客戶使用的 StackExchange.Redis（Stack Overflow 內部實現並開源了）。如果 web 服務在 L1 和 L2 兩級緩存都未命中，則會直接去原始數據源獲取（比如，數據庫查詢，API 回調等），然後並把獲取到的結果緩存到本地和 Redis 中，這時其它服務未命中 L1 高速緩存便會去二級緩存 L2/Redis 中獲取，節省了調用數據庫查詢或者 API 回調的訪問時間。
大部分運行的問答網站都有自己的 L1/L2 高速緩存，通過 L1 緩存 Key 前綴、L2/Redis 緩存數據庫 ID。
儘管 Redis 主要是用來緩存，但也起到一個消費和訂閱的功能，Redis 可以推送一個消息，然後其他訂閱者來訂閱消息（包括下游的 Redis 從庫在訂閱消息）。
Websockets (NetGain)
Websockets 實時的推送消息（比如，頂欄的通知，投票，新的答案和評論）給用戶。
Sockets 服務器運行在 web 層，NetGain 是 Stack Overflow 實現的一個輕量級高性能實時的開源消息中間件。高峯期可達到 50 萬併發的 websocket 連接。
下圖展示的是一週 websocket 併發情況：
圖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）
SQL Server 是 Stack Overflow 唯一的源數據庫，所有 Elastic 和 Redis 的數據都來自 SQL Server。使用微軟的 SQL Server 監控組件 AlwaysOn Availability Groups 部署了兩個 SQL Server 集羣。每個集羣有一個主庫，一個數據備份在紐約，另一個數據備份在 Colorrado 數據中心。所有備份是異步複製。
第一個集羣硬件配置：Dell R720xd 服務器，384G 內存，4TB SSD 存儲，雙 12 核 CPU；第二個集羣硬件配置：Dell R730xd 服務器，768G 內存，4TB SSD 存儲，雙 8 核 CPU。
所有數據庫過去 24 小時 CPU 監控圖如圖 7 所示，大部分情況 CPU 使用率較低，偶爾做下緩存任務時會高些。圖中 NY-SQL02 和 04 是主庫，01 和 03 是備份庫。
圖7
縱觀全文，Stack Overflow 整體架構並沒有採用那些非常高端的技術，卻造就了一個 IT 界最受歡迎的問答網站之，這是非常不錯的。其中每項使用到的技術都進行了深入的研究並開源分享給社區，國內的公司可以從中獲得一些啓發。