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

這篇文章 主要揭秘Stack Overflow截止到2016年的技術(shù)架構(gòu)。

首先給出一個(gè)直觀的數(shù)據(jù)，讓大家有個(gè)初步的印象。相比于2013年11月，Stack Overflow在2016年02月統(tǒng)計(jì)數(shù)據(jù)有較大變化，下面給出2016年02月09號(hào)一天的數(shù)據(jù)，如下：

• HTTP請(qǐng)求數(shù)209,420,973 (+61,336,090)
• 網(wǎng)頁(yè)加載次數(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查詢(xún)數(shù)(HTTP請(qǐng)求)504,816,843 (+170,244,740)
• Redis命中數(shù)5,831,683,114 (+5,418,818,063)
• Elastic 查詢(xún)次數(shù)17,158,874 (未計(jì)入2013年的數(shù)據(jù))
• 標(biāo)簽引擎請(qǐng)求次數(shù)3,661,134 (+57,716)
• SQL查詢(xún)耗時(shí)607,073,066 (+48,848,481) 毫秒 (168小時(shí))
• Redis命中耗時(shí)10,396,073 (-88,950,843) 毫秒 (2.8 小時(shí))

你很難想象到.NET技術(shù)架構(gòu)能夠在每天6100萬(wàn)請(qǐng)求的情況下減少757小時(shí)的處理時(shí)間(相比于2013年)。這些改善既得益于 2015年早期的硬件設(shè)備升級(jí) ，也跟軟件的性能優(yōu)化有極大的關(guān)系。

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

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

為了支撐Stack Overflow運(yùn)行，那需要做點(diǎn)什么呢？其實(shí)跟2013年相比并沒(méi)有什么顯著變化，只是做了前面提到的硬件升級(jí)和程序的性能優(yōu)化。

現(xiàn)有系統(tǒng)一般都不會(huì)完全隔離開(kāi)來(lái)，Stack Overflow也不列外。一圖勝千言，下面給出Stack Overflow的整體架構(gòu)效果圖。本篇文章僅給出硬件整理的邏輯架構(gòu)的亮點(diǎn)，具體的硬件細(xì)節(jié)部分將在下一篇文章詳細(xì)介紹。

圖1是機(jī)架A（在2015年2月升級(jí)的）的實(shí)物圖片展示。

圖1現(xiàn)在來(lái)給出主要系統(tǒng)的邏輯架構(gòu)圖，如圖2。

圖2

基本規(guī)則

首先給出全局的通用規(guī)則：

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

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

首先，用戶去Stack Overflow網(wǎng)站瀏覽就要通過(guò)Internet。為了讓用戶瀏覽網(wǎng)站的速度更快Stack Overflow采用CloudFlare的CDN加速。這里使用CloudFlare服務(wù)是因?yàn)樗鼈兊腃DN服務(wù)器遍布全球。緊接著，用戶的HTTP流量通過(guò)四大ISP提供商（Level 3，Zayo，Cogent和Lighttower），經(jīng)過(guò)四臺(tái)路由器。Stack Overflow通過(guò)標(biāo)準(zhǔn)的邊界網(wǎng)關(guān)協(xié)議（BGP）來(lái)均衡所有的流量以便用戶更有效率的打開(kāi)網(wǎng)站。Stack Overflow的工程師Nick Craver建議在兩個(gè)異地?cái)?shù)據(jù)中心采用一個(gè)10 Gbps MPLS，這樣在出現(xiàn)突發(fā)情況下可以快速的恢復(fù)和復(fù)制數(shù)據(jù)。

負(fù)載均衡（HAProxy）

負(fù)載均衡使用的HAProxy 1.5.15和CentOS 7，并在HAProxy加入安全傳輸層協(xié)議（TLS/SSL）。后續(xù)會(huì)升級(jí)HAProxy到1.6版本來(lái)支持HTTP/2。

負(fù)載均衡器配備2對(duì)10Gbps網(wǎng)絡(luò)。Stack Overflow通過(guò)加內(nèi)存來(lái)有效的解決安全套接層（SSL）問(wèn)題。緩存安全傳輸層協(xié)議(TLS)會(huì)話到內(nèi)存加以重復(fù)使用，這樣可以減少對(duì)于同一臺(tái)客戶端連接的重復(fù)計(jì)算，到達(dá)提升會(huì)話的速度和成本。況且RAM相當(dāng)便宜，實(shí)現(xiàn)了雙贏的效果。

負(fù)載均衡器的設(shè)置是相當(dāng)?shù)暮?jiǎn)單。它們監(jiān)聽(tīng)各路IPs，并進(jìn)行路由分發(fā)。Stack Overflow還做了負(fù)載均衡限流和監(jiān)控HAProxy的日志做到及時(shí)報(bào)警。

Web層架構(gòu)（IIS 8.5，ASP.Net MVC 5.2.3，和.Net 4.6.1）

Stack Overflow經(jīng)過(guò)負(fù)載均衡層導(dǎo)入流量到9臺(tái)Web服務(wù)器（“primary”服務(wù)器），另外兩臺(tái)做網(wǎng)站元數(shù)據(jù)等環(huán)境管理。除 meta.stackoverflow.com和meta.stackexchange.com外，Stack Overflow、Careers和Stack Exchange網(wǎng)站業(yè)務(wù)都在“primary”服務(wù)器運(yùn)行。

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

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

圖4

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

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

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

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

圖5

Redis所在服務(wù)器有L1/L2高速緩存，Web服務(wù)的HTTP緩存設(shè)置在一級(jí)緩存L1中，Redis緩存在二級(jí)緩存L2。當(dāng)用戶訪問(wèn)在一級(jí)緩存L1中未命中后會(huì)去二級(jí)緩存中的Redis取值，這些值以Protobuf格式存儲(chǔ)，并以 protobuf-dot-net 解析。Redis客戶使用的 StackExchange.Redis （Stack Overflow內(nèi)部實(shí)現(xiàn)并開(kāi)源了）。如果web服務(wù)在L1和L2兩級(jí)緩存都未命中，則會(huì)直接去原始數(shù)據(jù)源獲取（比如，數(shù)據(jù)庫(kù)查詢(xún)，API回調(diào)等），然后并把獲取到的結(jié)果緩存到本地和Redis中，這時(shí)其它服務(wù)未命中L1高速緩存便會(huì)去二級(jí)緩存L2/Redis中獲取，節(jié)省了調(diào)用數(shù)據(jù)庫(kù)查詢(xún)或者API回調(diào)的訪問(wèn)時(shí)間。

大部分運(yùn)行的問(wèn)答網(wǎng)站都有自己的L1/L2高速緩存，通過(guò)L1緩存Key前綴、L2/Redis緩存數(shù)據(jù)庫(kù)ID。

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

Websockets (NetGain)

Websockets實(shí)時(shí)的推送消息（比如，頂欄的通知，投票，新的答案和評(píng)論）給用戶。

Sockets服務(wù)器運(yùn)行在web層， NetGain 是Stack Overflow實(shí)現(xiàn)的一個(gè)輕量級(jí)高性能實(shí)時(shí)的開(kāi)源消息中間件。高峰期可達(dá)到50萬(wàn)并發(fā)的websocket連接。

下圖展示的是一周websocket并發(fā)情況：

圖6

Search (Elasticsearch)

Stack Overflow的工程師Nick Craver表示搜索層并沒(méi)有激動(dòng)人心的部分。在web層采用Elasticsearch 1.4，并內(nèi)部實(shí)現(xiàn)了高性能的StackExchange.Elastic客戶端，此部分代碼未開(kāi)源。Stack Overflow使用Elastic來(lái)查詢(xún)相關(guān)的問(wèn)答。

每個(gè)數(shù)據(jù)中心都有一個(gè)Elasticsearch集群，包含三個(gè)節(jié)點(diǎn)，每個(gè)都建有自己的索引。三個(gè)Elasticsearch集群全部使用SSD存儲(chǔ)，192GB內(nèi)存和雙10Gbps網(wǎng)卡。

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

數(shù)據(jù)庫(kù)（SQL Server）

SQL Server是Stack Overflow唯一的源數(shù)據(jù)庫(kù)，所有Elastic和Redis的數(shù)據(jù)都來(lái)自SQL Server。使用微軟的SQL Server監(jiān)控組件AlwaysOn Availability Groups部署了兩個(gè)SQL Server集群。每個(gè)集群有一個(gè)主庫(kù)，一個(gè)數(shù)據(jù)備份在紐約，另一個(gè)數(shù)據(jù)備份在Colorrado數(shù)據(jù)中心。所有備份是異步復(fù)制。

第一個(gè)集群硬件配置：Dell R720xd服務(wù)器，384G內(nèi)存，4TB SSD存儲(chǔ)，雙12核CPU；第二個(gè)集群硬件配置：Dell R730xd服務(wù)器，768G內(nèi)存，4TB SSD存儲(chǔ)，雙8核CPU。

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

圖7

縱觀全文，Stack Overflow整體架構(gòu)并沒(méi)有采用那些非常高端的技術(shù)，卻造就了一個(gè)IT界最受歡迎的問(wèn)答網(wǎng)站之，這是非常不錯(cuò)的。其中每項(xiàng)使用到的技術(shù)都進(jìn)行了深入的研究并開(kāi)源分享給社區(qū)，國(guó)內(nèi)的公司可以從中獲得一些啟發(fā)。

?

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/Irving/p/5244646.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。