億級體量的后臺技術(shù)架構(gòu)設(shè)計指南

1、 億級體量的后臺技術(shù)架構(gòu)設(shè)計指南目 錄 TOC o 1-3 h z u HYPERLINK l _Toc60749384 1.一款優(yōu)秀的架構(gòu)，就是要滿足業(yè)務(wù)和用戶的所有需求 PAGEREF _Toc60749384 h 3 HYPERLINK l _Toc60749385 2.海量數(shù)據(jù)存儲所帶來的架構(gòu)壓力 PAGEREF _Toc60749385 h 4 HYPERLINK l _Toc60749386 3.高并發(fā)與業(yè)務(wù)峰值對架構(gòu)的影響 PAGEREF _Toc60749386 h 6 HYPERLINK l _Toc60749387 4.移動網(wǎng)絡(luò)下的億級長鏈接管理 PAGEREF _Toc6

2、0749387 h 9 HYPERLINK l _Toc60749388 5.經(jīng)驗總結(jié) PAGEREF _Toc60749388 h 11隨著國內(nèi)移動互聯(lián)網(wǎng)的逐漸深化，人手一臺智能設(shè)備成為標(biāo)配，每人每天都在產(chǎn)生大量的數(shù)據(jù)。這些數(shù)據(jù)對于企業(yè)來說，如果后臺架構(gòu)能輕松承擔(dān)，其對于業(yè)務(wù)來說就是價值；反之如果無法承擔(dān)這種數(shù)據(jù)體量，那么對于業(yè)務(wù)而言就是風(fēng)險。因此在現(xiàn)階段，構(gòu)建一套強大的、健壯的、可擴展性強的、能夠支撐億級體量的后臺架構(gòu)，對于企業(yè)來說是其“必需品”。就在昨天 5 月 14 日，InfoQ 十分榮幸邀請到了極光推送后臺技術(shù)負(fù)責(zé)人曾振波老師，以線上直播形式，以極光的真實實踐為引，全面闡述了極光是

3、如何在解決其 380 億注冊用戶的信息存儲問題、面對日均百億級別推送需求的同時，來實現(xiàn)其后臺架構(gòu)的高性能運轉(zhuǎn)。一款優(yōu)秀的架構(gòu)，就是要滿足業(yè)務(wù)和用戶的所有需求搭建企業(yè)級后臺架構(gòu)，就要搞明白架構(gòu)在企業(yè)業(yè)務(wù)中能起到怎樣的作用。以極光推送的后臺架構(gòu)為例，其任務(wù)就是要滿足每一名開發(fā)者的請求能夠得到及時有效的響應(yīng)。首先要找到用戶在使用過程中可能存在體驗問題的點，要從用戶使用產(chǎn)品整個流程出發(fā)，以極光為例，其整個流程是：用戶發(fā)起請求 -API 對用戶權(quán)限進行驗證 - 從多維度數(shù)據(jù)中篩選出目標(biāo)用戶 - 從分布式存儲集群中查詢用戶信息數(shù)據(jù) - 選擇對應(yīng)的推送通道 - 實現(xiàn)消息推送。那么極光的后臺架構(gòu)作用就是在上述

4、流程過程中，滿足用戶在使用推送過程中的實時性和觸達率的要求。那這個架構(gòu)的目標(biāo)就很明確了，接下來就是要分解在架構(gòu)設(shè)計過程中將會面臨的棘手的多重挑戰(zhàn)。首先是用戶需求，極光的用戶就是一線開發(fā)者，那么開發(fā)者使用推送的訴求就是對消息的實時性和消息觸達率的準(zhǔn)確性，如開發(fā)消息推送時候能不能及時的推送到目標(biāo)設(shè)備，這個推送任務(wù)觸達率是多少等。其次就是業(yè)務(wù)需求，這也是本次曾振波老師分享的重中之重。要明確構(gòu)建符合企業(yè)業(yè)務(wù)需求的架構(gòu)，要面臨哪些技術(shù)層面的挑戰(zhàn)？那這就是在做架構(gòu)設(shè)計時，需要重點考慮的方向。以極光為例，其架構(gòu)主要面臨以下三重的業(yè)務(wù)挑戰(zhàn)。首先是海量數(shù)據(jù)體量對存儲造成的壓力，極光擁有幾百億的用戶數(shù)據(jù)，在存儲的

5、同時還需要實時推送各個維度的數(shù)據(jù)，并且這些數(shù)據(jù)是在持續(xù)增加的。如何存儲如此大體量的數(shù)據(jù)？如何在大量數(shù)據(jù)集中進行增刪改查，對后臺數(shù)據(jù)架構(gòu)來說是很大的一個挑戰(zhàn)。其次是高并發(fā)和峰值效應(yīng)對架構(gòu)的影響愈發(fā)明顯，每一款產(chǎn)品都有其特定的用戶使用時長高發(fā)期，極光也不例外。中午 12 點和晚 8 點 - 晚 11 點，這兩個時間段是開發(fā)者使用極光推送能力的高峰期。這種時間段往往會產(chǎn)生大量的請求，后臺服務(wù)往往需要同時處理比往常多達二十倍甚至更多的數(shù)據(jù)請求，因此需要后臺架構(gòu)能夠撐起并提供相對穩(wěn)定的服務(wù)。最后是移動網(wǎng)絡(luò)下的億級長連接管理，面對移動互聯(lián)網(wǎng)應(yīng)用，極光的 SDK 產(chǎn)品每天都被曝光在在移動網(wǎng)絡(luò)的環(huán)境下。此類環(huán)

6、境不比 PC 端，“不穩(wěn)定”可以說是移動網(wǎng)絡(luò)的一個典型特征，經(jīng)常會涉及到無法訪問、弱網(wǎng)以及網(wǎng)絡(luò)抖動的各種問題，因此需要盡量保證 SDK 能夠穩(wěn)定的連接到極光的后臺推送架構(gòu)之上。海量數(shù)據(jù)存儲所帶來的架構(gòu)壓力業(yè)務(wù)挑戰(zhàn)從開發(fā)者發(fā)起推送請求之時就已經(jīng)開始了。首先后臺架構(gòu)要能夠快速對消息系統(tǒng)內(nèi)部的數(shù)據(jù)進行梳理并發(fā)送到對應(yīng)的終端設(shè)備之上。上萬名用戶的需求很簡單，百萬、千萬的需求在當(dāng)下大環(huán)境中也不難實現(xiàn)，但是如果面對的是幾百億的數(shù)據(jù)體量呢？這就對極光推送后臺架構(gòu)提出了更高的需求。這種體量的業(yè)務(wù)，往往會對后臺架構(gòu)提出更多要求，如存儲資源、高性能、高可用、可擴展、運維成本等等。面對上面這些問題，極光提出了一系列

7、解決方案。存儲介質(zhì)的選擇極光采用了 MySQL、Redis、PIKA、CouchBase 以及定制化的一個自研存儲，會根據(jù) OPS 數(shù)據(jù)量和數(shù)據(jù)特性，結(jié)合存儲系統(tǒng)本身的特性來選擇所對應(yīng)存儲系統(tǒng)。Redis 的性能很高，但是集群能力很弱，單線程處理很容易造成命令性堵塞；CouchBase 性能很高，集群能力優(yōu)勢明顯，但缺點是對資源的消耗過大；PIKA 本身是用磁盤作為存儲的，因此性能比較低，但相對的成本也較低；MySQL 主要用于存儲幾百億的用戶數(shù)據(jù)，主要負(fù)責(zé)基礎(chǔ)數(shù)據(jù)的插入和更新。數(shù)據(jù)庫優(yōu)化方式為了提高數(shù)據(jù)的存儲效率，我們還對索引還有 SQL 語句進行了優(yōu)化，如盡量避免“字符字段”作為主鍵等。數(shù)

8、據(jù)分片存儲方式極光數(shù)據(jù)存儲采用的是分片 + 多副本的存儲架構(gòu)，這種結(jié)構(gòu)適用于 MySQL 或其它第三方存儲系統(tǒng)。以自研存儲為例，基于 ICE 框架構(gòu)造出 SDK 用戶的狀態(tài)中心，并將其分為管理節(jié)點和數(shù)據(jù)節(jié)點，管理節(jié)點主要負(fù)責(zé)分片策略以及分片的路由信息管理。在數(shù)據(jù)走到管理節(jié)點后，會根據(jù)分片策略將數(shù)據(jù)分發(fā)到一個個對應(yīng)的數(shù)據(jù)分片，其中包含多個副本節(jié)點，這種架構(gòu)既能做到分片處理數(shù)據(jù)，也能夠利用多個副本分散處理請求，極大提升了數(shù)據(jù)存儲能力。讀寫分離策略極光采用一主多從、寫主讀從的策略，進行讀寫分離，只要能確保數(shù)據(jù)一致性的目的即可。并且極光大量采用批量的數(shù)據(jù)處理方式，例如說合并查詢、合并寫 Pipelin

9、e 等等。減少接口的調(diào)用次數(shù)還有請求在網(wǎng)絡(luò)上面的一個傳輸時間，提升極光系統(tǒng)的整體性能。對于非活躍數(shù)據(jù)的處理極光的系統(tǒng)經(jīng)過了幾年的積累，目前數(shù)據(jù)已達到百億級別，這當(dāng)中有很多數(shù)據(jù)是不太活躍的，對于存儲資源來說是極大的浪費，并且大量的非活躍數(shù)據(jù)也影響到了后臺系統(tǒng)的整體性能，因此需要對活躍數(shù)據(jù)和非活躍數(shù)據(jù)進行區(qū)分處理，使用不同的存儲進行分開保存。同時注意活躍數(shù)據(jù)和非活躍數(shù)據(jù)的轉(zhuǎn)換機制，每家企業(yè)都有自己的衡量標(biāo)準(zhǔn)。對于不活躍的數(shù)據(jù)，極光會把這類用戶關(guān)聯(lián)在各個維度的數(shù)據(jù)之下，再全部都轉(zhuǎn)化為非活躍的一個數(shù)據(jù)。高并發(fā)與業(yè)務(wù)峰值對架構(gòu)的影響極光的服務(wù)是 24 小時的，也就意味著每分每秒都有大量用戶在同時使用極光

10、的服務(wù)。從時間上來看，一般來說中午和晚上這兩個時間段是極光的業(yè)務(wù)高峰期。從業(yè)務(wù)角度來看，開發(fā)者使用廣播和標(biāo)簽對于業(yè)務(wù)峰值的影響最高。期間業(yè)務(wù)峰值和低谷期的差距非常大，甚至多達幾十倍。（極光業(yè)務(wù)峰值)這對于無論是存儲資源的訪問，還是對于計算資源的使用，期間都存在非常大的落差。但是作為服務(wù)方，要在業(yè)務(wù)高峰期時保證服務(wù)質(zhì)量，提供穩(wěn)定服務(wù)，并且不同業(yè)務(wù)之間不能產(chǎn)生影響，因此對系統(tǒng)架構(gòu)整體的能力要求就很高。極光采用了以下幾種解決方案業(yè)務(wù)隔離對于極光而言，影響較大的業(yè)務(wù)類型是廣播和標(biāo)簽推送?？梢詫V播和標(biāo)簽這類目標(biāo)數(shù)較多的推送進行單獨隔離，避免影響到其他業(yè)務(wù)類型的推送。存儲資源隔離對特殊的熱點數(shù)據(jù)進行隔離

11、存儲。一般來說當(dāng)開發(fā)者發(fā)起推送請求后，系統(tǒng)內(nèi)部會查詢大量的數(shù)據(jù)。但是如果每個數(shù)據(jù)都去查的話，會極大影響交付效率，無法確保消息的實時性。因此需要提前存儲一些熱點數(shù)據(jù)。因為在極光的業(yè)務(wù)系統(tǒng)中會有部分開發(fā)者將兩三千萬用戶關(guān)聯(lián)到一個標(biāo)簽下，當(dāng)使用這樣一個標(biāo)簽進行推送的時候，極光后臺架構(gòu)就需要查詢這個標(biāo)簽下所有的用戶，這對后臺系統(tǒng)帶來了很大的壓力。因此，就需要提前存儲一些熱點數(shù)據(jù)，對這一類資源進行隔離部署?；钴S數(shù)據(jù) / 非活躍數(shù)據(jù)的處理在前面處理數(shù)據(jù)存儲的時候已經(jīng)做了一個活躍數(shù)據(jù)和非活躍數(shù)據(jù)的存儲隔離，但是在查詢數(shù)據(jù)的時候，還是會查詢到非活躍數(shù)據(jù)。例如廣播推送需要查詢到該應(yīng)用下所有用戶，對于其中的非活躍

12、數(shù)據(jù)會顯示推送失敗，但是這期間從數(shù)據(jù)查詢到后續(xù)的推送處理都是很大的資源浪費。因此需要對活躍和非活躍數(shù)據(jù)做出分離，推送時只需要查詢活躍數(shù)據(jù)，從而節(jié)省數(shù)據(jù)查詢時間和后續(xù)流程處理時間，加快了整個推送鏈路的處理；另外對于活躍比例不大的數(shù)據(jù)可以采用多級緩存（內(nèi)存 + 磁盤）的方式來提高訪問效率。異步處理極光目前的系統(tǒng)中包含數(shù)十個模塊，每天需進行千億次內(nèi)部服務(wù)請求。如果后臺架構(gòu)仍采用同步方式進行服務(wù)請求，那么同步請求所產(chǎn)生的等待時間必然嚴(yán)重影響到實時性。因此需要采用異步的方式進行服務(wù)請求，除非有一些必須使用同步請求的情況才用同步請求。對于極光的業(yè)務(wù)來說，很多業(yè)務(wù)邏輯都是流水線，這時可以把請求封裝為消息再發(fā)

13、送到 MQ。業(yè)務(wù)的下游再到 MQ 去消費消息，再來處理對應(yīng)的業(yè)務(wù)邏輯。只要 MQ 能高效穩(wěn)定的運行，就能夠保證業(yè)務(wù)的正常運行。同時使用 MQ 時候也能夠使各個模塊間進一步解耦，減少相互依賴。對于需要返回結(jié)果的請求來說，極光通過使用 ICE 框架來搭建 RPC 業(yè)務(wù)服務(wù)，確保能夠?qū)Ψ?wù)端發(fā)起的請求做出實時負(fù)載均衡，實現(xiàn)客戶端異步調(diào)用請求和服務(wù)端的異步處理請求。移動網(wǎng)絡(luò)下的億級長鏈接管理極光架構(gòu)下的長鏈接在高峰期的連接數(shù)能夠超過一個億，在凌晨 2 點到 6 點的低谷期也有七、八千萬的體量，為了支撐如此多的長鏈接，極光需要大量使用虛擬機資源。此外 SDK 的大部分鏈接都是使用 2G、3G、4G 等移

14、動網(wǎng)絡(luò)，且同時覆蓋了移動、聯(lián)通、電信三大運營商。在這種億級鏈接的情況下，如果架構(gòu)不成熟，就會暴露出一系列問題。比如需要避免使用太多的虛擬機資源；如此多的虛擬機資源在建立連接時，要確保各個虛擬機之間的負(fù)載要能達到相對平衡的狀態(tài)；此外在使用移動網(wǎng)絡(luò)時還會面臨弱網(wǎng)和網(wǎng)絡(luò)抖動、連接不穩(wěn)定等情況的出現(xiàn)。（極光推送鏈接服務(wù)架構(gòu))首先 SDK 向極光調(diào)度中心發(fā)起請求，調(diào)度中心充分考慮運營商網(wǎng)絡(luò)、SDK 的地域和接入網(wǎng)關(guān)本身的負(fù)載因素，分配一個接入網(wǎng)關(guān)的 IP 地址，SDK 獲得返回接入網(wǎng)關(guān)地址后，向?qū)?yīng)的接入網(wǎng)關(guān)發(fā)起請求建立長鏈接。此外極光配有健康檢測服務(wù)模塊，定時檢測各個接入網(wǎng)關(guān)狀態(tài)并上報到管理中心，管理

15、中心會根據(jù)網(wǎng)關(guān)的狀態(tài)來決定該網(wǎng)關(guān)是否是可以被調(diào)度。如果受到攻擊等因素導(dǎo)致接入網(wǎng)關(guān)大范圍不可用的情況下，接入網(wǎng)關(guān)還可以借助于云主機來實現(xiàn)自動擴容接入網(wǎng)關(guān)，以滿足日常大量的 SDK 接入需求。在這樣一個架構(gòu)之下，極光采用了以下 4 點技術(shù)能力來解決長鏈接管理的問題。單機性能優(yōu)化極光目前的業(yè)務(wù)代碼基本上都采用了模塊化處理，模塊的功能需要盡可能簡單。讓接入網(wǎng)關(guān)只負(fù)責(zé) SDK 端的數(shù)據(jù)收發(fā)，具體的業(yè)務(wù)邏輯都放在后端的業(yè)務(wù)模塊進行處理，不在接入網(wǎng)關(guān)處理業(yè)務(wù)邏輯。此外在接入網(wǎng)關(guān)層面通過采用靜態(tài)內(nèi)存分配來管理各個 SDK 的連接信息以提高內(nèi)存的訪問效率，同時對內(nèi)存進行對齊數(shù)據(jù)，盡可能減少數(shù)據(jù)從內(nèi)存加載到 CP

16、U 緩存的次數(shù)，以提高 CPU 訪問內(nèi)存的效率。此外，通過實現(xiàn)網(wǎng)卡多隊列來并行處理網(wǎng)絡(luò)消息來加快網(wǎng)絡(luò)數(shù)據(jù)包的處理。同時需要單獨進行參數(shù)調(diào)優(yōu)，例如增加網(wǎng)絡(luò)收發(fā)緩沖區(qū)。另外需要關(guān)閉防火墻，避免 conntrack 內(nèi)核模塊影響網(wǎng)絡(luò)數(shù)據(jù)的處理效率。自動化管理接入網(wǎng)關(guān)由于接入網(wǎng)關(guān)面向的是 C 端用戶，經(jīng)常會因為受到攻擊導(dǎo)致接入網(wǎng)關(guān)不可用，因此需要能夠自動化管理接入網(wǎng)關(guān)，定時檢測接入網(wǎng)關(guān)的健康狀況，當(dāng)接入網(wǎng)關(guān)不可用的時候，要做到自動化下線該網(wǎng)關(guān)，當(dāng)接入網(wǎng)關(guān)重新恢復(fù)可用時，能夠?qū)崿F(xiàn)自動化上線。自動擴容 / 縮容能力面臨比較大規(guī)模的網(wǎng)絡(luò)攻擊時，運營商往往因為攻擊量過大直接將一整個 IP 段封禁，這時就會使得大量接入網(wǎng)關(guān)被波及導(dǎo)致不可用。因此自動擴容和縮容能力對于任何一家企業(yè)后臺架構(gòu)來說，都是非常需要的功能之一。采用 K8s 部署接入網(wǎng)關(guān)目前極光通過 180 臺虛擬機來接入網(wǎng)關(guān)，這是一個相對比較繁雜的工作，特別是在升級部署的時候，不僅涉及到程序升級，還要涉及到配置管理，因此會消耗很大的精力去管理程序和配置的版本。因此就需要采用 K8S 能力來部署接入網(wǎng)關(guān)，在節(jié)省了程序和配置管理的同時，接入網(wǎng)關(guān)的自動升級擴容的自動擴容也變得更為便捷。經(jīng)驗總結(jié)在極光構(gòu)造架構(gòu)系統(tǒng)的過程中，曾老師從技術(shù)角度和業(yè)務(wù)角度兩個層面總結(jié)了架構(gòu)設(shè)計的經(jīng)驗和方法論。首先從技術(shù)角度來看，一款優(yōu)秀的架構(gòu)的標(biāo)準(zhǔn)是一定要具備高性能、高