Stack Overflow 2016最新架構(gòu)探秘

icecity1306 2016-07-29

展開全文

　　這篇文章主要揭秘 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ù)庫服務(wù)器（微軟 SQL Server），其中兩臺更新硬件配置
11 臺 Web 服務(wù)器（IIS），都已更新硬件配置
2 臺分布式緩存和消息處理服務(wù)器（Redis），都已更新硬件配置
3 臺應(yīng)用服務(wù)器（實現(xiàn)了 tag 引擎功能），其中兩臺為新硬件配置
3 臺搜索服務(wù)器（ElasticSearch），配置同 2013 年
4 臺負載均衡服務(wù)器（HAProxy），其中新增加的兩臺用于支持 CloudFlare 的 CDN 加速服務(wù)
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ù)器和網(wǎng)絡(luò)交換機要至少 2 x 10Gbps 帶寬
所有服務(wù)器配備兩個電源（帶有 UPS 電源備用）
所有服務(wù)器在機架A和B上互為冗余
所有服務(wù)器和服務(wù)都有異地雙活（紐約機房和科羅拉多州機房）

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

　　首先，用戶去 Stack Overflow 網(wǎng)站瀏覽就要通過 Internet。為了讓用戶瀏覽網(wǎng)站的速度更快 Stack Overflow 采用 CloudFlare 的 CDN 加速。這里使用 CloudFlare 服務(wù)是因為它們的 CDN 服務(wù)器遍布全球。

　　緊接著，用戶的 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ù)暮唵巍Ｋ鼈儽O(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 服務(wù)器（“primary”服務(wù)器），另外兩臺做網(wǎng)站元數(shù)據(jù)等環(huán)境管理。除 meta.stackoverflow.com 和 meta.stackexchange.com 外，Stack Overflow、Careers 和 Stack Exchange 網(wǎng)站業(yè)務(wù)都在“primary”服務(wù)器運行。

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

　　圖3

　　更直觀的看下對應(yīng)的 web 服務(wù)器的圖形展示，見圖4

圖4

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

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

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

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

圖5

　　Redis 所在服務(wù)器有 L1/L2 高速緩存，Web 服務(wù)的 HTTP 緩存設(shè)置在一級緩存 L1 中，Redis 緩存在二級緩存 L2。當用戶訪問在一級緩存 L1 中未命中后會去二級緩存中的 Redis 取值，這些值以 Protobuf 格式存儲，并以 protobuf-dot-net 解析。Redis 客戶使用的 StackExchange.Redis（Stack Overflow 內(nèi)部實現(xiàn)并開源了）。如果 web 服務(wù)在 L1 和 L2 兩級緩存都未命中，則會直接去原始數(shù)據(jù)源獲?。ū热纾瑪?shù)據(jù)庫查詢，API 回調(diào)等），然后并把獲取到的結(jié)果緩存到本地和 Redis 中，這時其它服務(wù)未命中 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 服務(wù)器運行在 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 服務(wù)器，384G 內(nèi)存，4TB SSD 存儲，雙 12 核 CPU；第二個集群硬件配置：Dell R730xd 服務(wù)器，768G 內(nèi)存，4TB SSD 存儲，雙 8 核 CPU。

　　所有數(shù)據(jù)庫過去 24 小時 CPU 監(jiān)控圖如圖 7 所示，大部分情況 CPU 使用率較低，偶爾做下緩存任務(wù)時會高些。圖中 NY-SQL02 和 04 是主庫，01 和 03 是備份庫。