從西安一碼通崩潰，看千萬級(jí)DAU系統(tǒng)該如何設(shè)計(jì)
最近西安一碼通的故障引起了業(yè)界廣泛的討論，究其根本原因還是系統(tǒng)未充分考慮到擴(kuò)展性，在面臨超過日常訪問數(shù)倍甚至十倍以上的突發(fā)流量時(shí)某個(gè)環(huán)節(jié)達(dá)到了瓶頸點(diǎn)，并且系統(tǒng)不能做到自動(dòng)擴(kuò)縮容，最終導(dǎo)致了故障。
而之前各個(gè)網(wǎng)站頻繁崩潰登上微博熱搜，也是在應(yīng)對(duì)突發(fā)流量方面做的不是很好，一方面是因?yàn)橄到y(tǒng)的冗余度評(píng)估不足，流量超出了系統(tǒng)的最大承載能力；另一方面是因?yàn)橄到y(tǒng)不能做到自動(dòng)擴(kuò)縮容，在流量超過系統(tǒng)最大承載時(shí)需要人工介入，響應(yīng)速度和故障恢復(fù)速度都遠(yuǎn)遠(yuǎn)比不上自動(dòng)擴(kuò)縮容。
1
? ?
通用百萬級(jí) DAU 用戶系統(tǒng)架構(gòu)設(shè)計(jì)
在闡述千萬級(jí) DAU 系統(tǒng)的架構(gòu)設(shè)計(jì)之前，我們首先來看一個(gè)通用的百萬級(jí) DAU 互聯(lián)網(wǎng)應(yīng)用架構(gòu)的設(shè)計(jì)。如下圖所示，一次用戶訪問請(qǐng)求通常要經(jīng)過以下幾層：
1.1
? ?
DNS
DNS 最主要的作用是根據(jù)用戶的 IP 地址，決定把請(qǐng)求解析到哪個(gè)地域的 IDC，一般大型互聯(lián)網(wǎng)公司往往不止一個(gè) IDC，為了訪問速度考慮，北方用戶多訪問聯(lián)通機(jī)房，南方用戶多訪問電信機(jī)房。正常情況下每個(gè)用戶請(qǐng)求的 DNS 解析是固定的，并且在客戶端留有緩存，如果以前訪問聯(lián)通機(jī)房就會(huì)一直訪問聯(lián)通機(jī)房，以前訪問電信機(jī)房也會(huì)一直訪問電信機(jī)房。
1.2
? ?
四層負(fù)載均衡
流量經(jīng)過 DNS 解析后第一個(gè)要訪問的就是四層負(fù)載均衡了。四層負(fù)載均衡主要起到流量轉(zhuǎn)發(fā)作用，比如根據(jù)請(qǐng)求的域名決定流量轉(zhuǎn)發(fā)到后端哪個(gè)七層網(wǎng)關(guān)集群。四層負(fù)載均衡設(shè)備有軟負(fù)載也有硬負(fù)載，最典型的軟負(fù)載是 LVS，單臺(tái)承載能力通常是十萬級(jí) QPS 以上。而硬負(fù)載如 F5，單臺(tái)承載能力達(dá)到百萬級(jí) QPS，不過成本也較高，單臺(tái)機(jī)器成本幾十萬以上，所以一般互聯(lián)網(wǎng)公司四層負(fù)載均衡設(shè)備主要采用軟負(fù)載 LVS。
1.3
? ?
七層負(fù)載均衡
七層負(fù)載均衡一般又叫做網(wǎng)關(guān)，一般互聯(lián)網(wǎng)公司通過 Nginx 搭建自己的網(wǎng)關(guān)集群，當(dāng)流量經(jīng)過四層負(fù)載均衡轉(zhuǎn)發(fā)后，就到了具體某個(gè)七層網(wǎng)關(guān)集群了。為什么有了四層負(fù)載均衡后還要有七層負(fù)載均衡呢？主要有以下兩方面的考慮：
應(yīng)用層的轉(zhuǎn)發(fā)
對(duì)于大型互聯(lián)網(wǎng)公司應(yīng)用來說，通常業(yè)務(wù)包括幾十個(gè)甚至上百個(gè)域名，不僅要針對(duì)域名來做四層流量的負(fù)載均衡，還要針對(duì)統(tǒng)一域名下不同的接口來做七層流量的負(fù)載均衡，比如上下行接口的拆分，核心和非核心接口的拆分等。
集成鑒權(quán)、日志、監(jiān)控等通用功能
除此之外，一些通常的接口功能需求，如接口調(diào)用鑒權(quán)、日志統(tǒng)計(jì)、耗時(shí)監(jiān)控等等，適合放在網(wǎng)關(guān)層統(tǒng)一進(jìn)行處理，而不需要每個(gè)接口都實(shí)現(xiàn)這些功能。
1.4
? ?
服務(wù)端
流量經(jīng)過網(wǎng)關(guān)轉(zhuǎn)發(fā)后，就可以訪問某臺(tái)具體 IP 的服務(wù)器了，實(shí)際的應(yīng)用程序就部署在服務(wù)器上。服務(wù)端的程序部署一般有兩種架構(gòu)：
單體應(yīng)用
單體應(yīng)用就是所有的業(yè)務(wù)的代碼開發(fā)、合并、打包、部署都集成在一起，通常適合于比較簡(jiǎn)單的業(yè)務(wù)或者團(tuán)隊(duì)規(guī)模比較小的團(tuán)隊(duì)。
微服務(wù)拆分
當(dāng)應(yīng)用的接口上百個(gè)或者是團(tuán)隊(duì)規(guī)模超過十人時(shí)，代碼開發(fā)、合并、打包、部署在一起就會(huì)引起開發(fā)效率的降低，這個(gè)時(shí)候就適合進(jìn)行微服務(wù)拆分了，把相同領(lǐng)域的接口拆分到一個(gè)應(yīng)用，獨(dú)立進(jìn)行代碼開發(fā)、合并、打包和部署，更加靈活。
1.5
? ?
緩存
業(yè)務(wù)流量到達(dá)服務(wù)端后，服務(wù)端通常需要請(qǐng)求數(shù)據(jù)庫，再組裝處理后返回。一般情況下數(shù)據(jù)庫的延遲在十毫秒以上，為了提高訪問速度，可以把經(jīng)常訪問的數(shù)據(jù)放到緩存中，當(dāng)前用的最多的如 memcached、redis 等，單機(jī)的承載能力都是十萬級(jí)別，并且延遲只有 1-2 毫秒。
1.6
? ?
數(shù)據(jù)庫
一般情況下用戶請(qǐng)求的數(shù)據(jù)大部分都被緩存住，但緩存的命中率不可能達(dá)到 100%，穿透過來的請(qǐng)求還是要訪問數(shù)據(jù)庫。為了高可用數(shù)據(jù)庫層面一般要做到以下幾個(gè)層面：
主從分離
一般互聯(lián)網(wǎng)應(yīng)用來說，都是讀多寫少，為此可以將讀寫分離，寫請(qǐng)求訪問主庫，讀請(qǐng)求訪問從庫，根據(jù)讀請(qǐng)求的量來決定從庫的數(shù)量。
分庫分表
一般單臺(tái)服務(wù)器的磁盤容量通常在 T 級(jí)別，而大型互聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)總量一般在百 T 甚至千 T 級(jí)別，顯然單機(jī)無法承載，因此要對(duì)數(shù)據(jù)庫進(jìn)行分庫。另一方面單表查詢的性能會(huì)隨著容量增加而逐漸衰減，一般情況下單表容量要控制在千萬行級(jí)別，因此也需要對(duì)數(shù)據(jù)庫進(jìn)行分表。分庫分表一般有兩個(gè)維度，一個(gè)是時(shí)間維度，不同時(shí)間的數(shù)據(jù)存儲(chǔ)在不同的表上，這樣單張表的容量就有限了；一個(gè)是訪問維度，比如以用戶 ID 為維度，按照用戶 ID 進(jìn)行 hash，把不同用戶 ID 的訪問分散到不同的數(shù)據(jù)庫端口上。
基本按照以上架構(gòu)支撐百萬級(jí) DAU 的用戶訪問通常是沒問題的，但對(duì)于千萬級(jí)甚至億級(jí)以上 DAU 的系統(tǒng)來說， 只有在各層都支持自動(dòng)擴(kuò)縮容并配合快速降級(jí)等手段，才能在面對(duì)突發(fā)峰值流量時(shí)不至于崩潰。筆者結(jié)合過去十年在一線互聯(lián)網(wǎng)公司的實(shí)際經(jīng)歷，總結(jié)了千萬級(jí) DAU 以上系統(tǒng)架構(gòu)需要做出的改進(jìn)。
2
? ?
混合云架構(gòu)
當(dāng)用戶的請(qǐng)求經(jīng)過 DNS 解析后，就決定了要訪問哪個(gè)機(jī)房。首先要求機(jī)房出口總帶寬要足夠大，這是用戶流量的入口，如果帶寬打滿用戶請(qǐng)求就失敗了。一般情況下，機(jī)房出口帶寬是固定的，不能實(shí)時(shí)擴(kuò)容，所以要預(yù)留足夠的冗余。但實(shí)際情況下，各公司機(jī)房出口帶寬不可能無限擴(kuò)容。為此可以利用公有云來解決機(jī)房出口帶寬有限的問題，可以將業(yè)務(wù)部署在公有云機(jī)房，日常情況下流量主要走私有機(jī)房，當(dāng)流量上漲超出私有機(jī)房出口帶寬的承載值時(shí)，可以把一部分流量切換到公有云上，這就要求系統(tǒng)能支持混合云架構(gòu)。
混合云架構(gòu)要求業(yè)務(wù)不僅要能部署在私有云機(jī)房，還要能部署在公有云。首先要求私有云和公有云機(jī)房之間的網(wǎng)絡(luò)互通，對(duì)于千萬級(jí) DAU 以上的系統(tǒng)來說，通常需要專線才能保證帶寬和穩(wěn)定性需求。其次要考慮哪些層部署在公有云上，一個(gè)可以參考的架構(gòu)如下圖所示。
以上混合云架構(gòu)要求業(yè)務(wù)在私有云和公有云上都能夠部署服務(wù)，這對(duì)業(yè)務(wù)來說是一個(gè)比較大的挑戰(zhàn)，需要有相應(yīng)的混合云平臺(tái)支撐，不僅要向業(yè)務(wù)屏蔽公有云和私有云的資源差異，還要能支持業(yè)務(wù)同時(shí)部署在公有云和私有云上。一個(gè)比較好的解決方案是企業(yè)在現(xiàn)有的運(yùn)維基礎(chǔ)設(shè)施上集成開源算力引擎 BridgX（https://github.com/galaxy-future/bridgx/），它支持從不同的公有云上獲取資源，并管理私有云和公有云的機(jī)器，通過 Kubernetes 切割并以固定 IP 形式輸出等功能，只需要很小的開發(fā)成本即可支持混合云部署。
3
? ?
全鏈路彈性擴(kuò)容
當(dāng)用戶流量訪問超過現(xiàn)有機(jī)房的承載能力時(shí)，可以把一部分流量切換到公有云上，這時(shí)候就要求公有云上部署的四七層、服務(wù)端、緩存和數(shù)據(jù)庫都要能支撐流量。
3.1
? ?
四七層
云上四層單個(gè) SLB 能承載的并發(fā)連接數(shù)可達(dá)百萬級(jí)，因此在四層預(yù)留多幾臺(tái) SLB 即可支撐幾百萬連，因?yàn)?SLB 是按照流量收費(fèi)的, 日常沒有流量成本也很低。而七層可以根據(jù)流量來實(shí)時(shí)彈性擴(kuò)容，以 Nginx 為例，單臺(tái) Nginx 的承載能力通常在十萬級(jí)，可以根據(jù)實(shí)際的 QPS 來決定需要 Nginx 的數(shù)量，彈性擴(kuò)容后實(shí)時(shí)掛載到 SLB 上。
3.2
? ?
服務(wù)端
通常服務(wù)端是無狀態(tài)的，可以根據(jù)流量實(shí)時(shí)彈性來應(yīng)對(duì)。但這一層的彈性擴(kuò)容不能簡(jiǎn)單的根據(jù) QPS 來判定，還需要考慮耗時(shí)、慢速比等因素。一個(gè)通用的解決方案是根據(jù)接口的耗時(shí)分布對(duì) QSP 加權(quán)，擬合服務(wù)端實(shí)際的壓力值，再通過壓測(cè)獲取服務(wù)端最大承載能力，那么最大承載能力除以實(shí)際壓力值就是服務(wù)端的實(shí)時(shí)冗余度，最后劃定最高冗余度和最低冗余度兩條線，即可自動(dòng)擴(kuò)縮容。目前有一個(gè)比較好的開源解決方案 CudgX（https://github.com/galaxy-future/cudgx），它可以通過各類服務(wù)的多維度、大規(guī)模的日志數(shù)據(jù)采集以及機(jī)器學(xué)習(xí)訓(xùn)練分析，對(duì)服務(wù)進(jìn)行數(shù)字化、指標(biāo)化度量，從而使業(yè)務(wù)能夠做更加精準(zhǔn)的服務(wù)自動(dòng)擴(kuò)縮容。
3.3
? ?
緩存和數(shù)據(jù)庫
為了應(yīng)對(duì)千萬級(jí) DAU 以上的系統(tǒng)訪問，緩存也要支持?jǐn)U容。但由于緩存加載熱數(shù)據(jù)需要時(shí)間，往往以天為單位，如果是業(yè)務(wù)流量上漲比較快，這時(shí)候靠彈性擴(kuò)容往往難以應(yīng)對(duì)，最好預(yù)留足夠的冗余度。與緩存擴(kuò)容類似，數(shù)據(jù)庫的彈性擴(kuò)容也需要較長(zhǎng)時(shí)間，因?yàn)樯婕暗綌?shù)據(jù)同步，以 MySQL 的擴(kuò)容為例，若一個(gè)端口的數(shù)據(jù)量在 T 級(jí)別的話，數(shù)據(jù)同步往往在小時(shí)級(jí)以上。如果是流量上漲比較快的業(yè)務(wù)，則數(shù)據(jù)庫層面也要保持充足的冗余度。
4
? ?
三級(jí)降級(jí)機(jī)制
為了保障千萬 DAU 級(jí)的業(yè)務(wù)，業(yè)務(wù)除了要支持全鏈路彈性擴(kuò)容以外，還要能夠支持降級(jí)。降級(jí)一般是主動(dòng)犧牲某些系統(tǒng)功能和用戶體驗(yàn)，為了能夠快速釋放系統(tǒng)冗余度的自保措施。為了最大限度的降低降級(jí)帶來的影響，通常降級(jí)要分為三級(jí)：
一級(jí)降級(jí)是用戶感知不到的降級(jí)，降級(jí)能釋放的冗余度往往有限，通常在 30%以下；
二級(jí)降級(jí)是用戶可以感知到的降級(jí)，降級(jí)也能釋放一定的冗余度，通常在 50%以下；
三級(jí)降級(jí)是比較嚴(yán)重的降級(jí)，對(duì)用戶體驗(yàn)的影響比較嚴(yán)重，釋放的冗余度可達(dá)到 50%-100%，不到最后時(shí)刻一般不會(huì)采用。
實(shí)際在保障千萬級(jí) DAU 的系統(tǒng)時(shí)，除了要做到混合云架構(gòu)、全鏈路彈性擴(kuò)容、三級(jí)降級(jí)機(jī)制以外，還需要有各種各樣的配套機(jī)制，比如決策支持系統(tǒng)、值班報(bào)警機(jī)制等。
5
? ?
活動(dòng)預(yù)告
為了更深入的與企業(yè)交流云原生架構(gòu)主題，星漢未來將在1月23號(hào)下午1: 30舉辦北京站第二次Meetup，圍繞“自動(dòng)擴(kuò)縮容&在離線混部核心技術(shù)”為大家?guī)硪韵路窒恚?/span>
百度云原生混部技術(shù)解密 —— 百度基礎(chǔ)架構(gòu)部云原生團(tuán)隊(duì)高級(jí)研發(fā)工程師 星龍
如何借助自動(dòng)擴(kuò)縮容實(shí)現(xiàn)在離線混部的分 ———星漢未來 CTO 舒超
支持通用Web自動(dòng)擴(kuò)縮容的智能運(yùn)維引擎CudgX的詳細(xì)產(chǎn)品體驗(yàn) ———星漢未來聯(lián)合創(chuàng)始人&CPO 胡忠想
現(xiàn)場(chǎng)產(chǎn)品體驗(yàn)
本次Meetup現(xiàn)場(chǎng)還會(huì)首發(fā)《星漢未來在離線混部解決方案白皮書》，與會(huì)者將第一時(shí)間獲取。歡迎掃描下圖二維碼或者點(diǎn)擊【閱讀原文】報(bào)名，我們會(huì)審核后發(fā)出確認(rèn)邀請(qǐng)，期待行業(yè)伙伴們一起參與。