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 界最受歡迎的問答網站之,這是非常不錯的。其中每項使用到的技術都進行了深入的研究並開源分享給社群,國內的公司可以從中獲得一些啟發。
相關文章
- Google大資料技術架構探祕Go大資料架構
- 哪門程式語言更賺錢?看看 Stack Overflow 的最新調查
- Stack Overflow 與全民程式設計時代程式設計
- 玩轉 Stack Overflow 之提問篇
- 探祕日本手遊市場最新動態–資訊圖
- Windows Kernel Exploitation Notes(一)——HEVD Stack OverflowWindows
- 我是如何在Stack Overflow找到工作的
- 前端工程架構探討前端架構
- 每日安全資訊:Stack Overflow 遭遇黑客攻擊黑客
- Stack Overflow:最令人討厭的程式語言
- Stack Overflow 最流行的程式語言和標籤
- 歐洲最大MySQL使用者Booking.com資料庫構架探祕!MySql資料庫
- 動手做:構建模型來預測Stack Overflow中的問題標籤模型
- 探祕WKWebViewWebView
- WebSocket探祕Web
- Stack Overflow 上人氣最旺的 10 個 Java 問題Java
- Web列印探祕Web
- AutoEx應用崩潰自動匹配Stack Overflow的解答應用崩潰
- H.264介紹(從Stack Overflow答案翻譯)
- Azure DevOps 的架構窺探dev架構
- Web 框架的架構模式探討Web框架架構模式
- Android 專案最新架構Android架構
- 跟著《架構探險》學輕量級微服務架構 (一)架構微服務
- 探尋軟體架構的本質,到底什麼是架構?架構
- 探尋軟體架構的本質,到底什麼是架構架構
- 跟著《架構探險》學輕量級微服務架構 (二)架構微服務
- Stack Overflow:2020 年開發人員調查
- Stack Overflow:2019年全球開發者調查報告
- 2021年Stack Overflow程式設計師開發者調查程式設計師
- Stack Overflow 2018 開發者調查報告出爐
- 基於使用者投票的排名演算法:Stack Overflow演算法
- Cglib proxy探祕CGLib
- java concurrent 探祕Java
- PingCode 技術架構揭祕GC架構
- Stack Overflow:2019全球程式語言高薪排行榜高薪
- 使用ChatGPT人工智慧回答國外知乎Stack Overflow上問題?ChatGPT人工智慧
- 在 Stack Overflow 遠端辦公是怎樣一種體驗?
- 千萬條資料,Stack Overflow 是如何實現快速分頁的?