原文：http://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
轉載：http://www.infoq.com/cn/news/2016/03/Stack-Overflow-architecture-insi?utm_source=tuicool&utm_medium=referral

這篇文章 主要揭秘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路由器

為了支撐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界最受歡迎的問答網站之，這是非常不錯的。其中每項使用到的技術都進行了深入的研究并開源分享給社區，國內的公司可以從中獲得一些啟發。

?

REFER:
StackOverflow 這么大，它的架構是怎么樣的？
http://blog.jobbole.com/98633/

?

轉載于:https://www.cnblogs.com/Irving/p/5244646.html

總結

以上是生活随笔為你收集整理的Stack Overflow 2016 最新架构探秘的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。