編者注：本文轉(zhuǎn)自 InfoQ。在 2014 年 4 月 11 日的騰訊分享日活動(dòng)上，騰訊 OMG 移動(dòng)媒體產(chǎn)品部助總鄭堅(jiān)分享了有關(guān)騰訊新聞海量服務(wù)的一些技術(shù)技術(shù)原則。本文根據(jù)這次分享內(nèi)容整理而成。
騰訊很多海量服務(wù)的意識(shí)和規(guī)則都是從 QQ 演化出來(lái)的，即使從移動(dòng)互聯(lián)網(wǎng)的角度來(lái)看，當(dāng)時(shí)的很多規(guī)則也很貼切。我下面的分享主要從兩點(diǎn)展開：
跟產(chǎn)品、運(yùn)營(yíng)的合作的一些技術(shù)原則;
移動(dòng)端海量服務(wù)的特點(diǎn)。
我負(fù)責(zé)的移動(dòng)新聞客戶端，在兩年半前接手的時(shí)候還是比較小的，到現(xiàn)在安裝量早已過億，日活躍用戶量在千萬(wàn)級(jí)，很多用戶從微信和手機(jī) QQ 進(jìn)來(lái)。從比較小的規(guī)模成長(zhǎng)到現(xiàn)在這么大的規(guī)模，遇到很多問題。
移動(dòng)新聞?lì)惙?wù)有幾個(gè)特點(diǎn)：
新聞是基礎(chǔ)需求之一，使用頻率屬于次高級(jí)別，比通訊類服務(wù)低，比電商類服務(wù)高。有些很重要的新聞，雖然用戶不一定要看細(xì)節(jié)，但必須要知道這件事，所以要 push 給所有的用戶;
覆蓋面廣，不同的人群、地域、運(yùn)營(yíng)商都要覆蓋到;
突發(fā)性強(qiáng)，尤其是重大新聞爆發(fā)時(shí)，瞬間 push 的流量是日常流量的好幾倍，對(duì)服務(wù)質(zhì)量的要求也很高。
下面從產(chǎn)品、技術(shù)、運(yùn)營(yíng)這三個(gè)層面分享一下我們的感受。
產(chǎn)品
聚焦核心需求，少即是多：我們從非常小的產(chǎn)品長(zhǎng)起來(lái)，最初要做的比較小，功能少，現(xiàn)在的專題、直播、圖文、離線都是后來(lái)加的。一開始是因?yàn)槿撕唾Y源有限，必須逼迫自己要去聚焦最核心的需求;隨著發(fā)展慢慢就會(huì)覺得很多東西可以做，但像是新聞這種基礎(chǔ)性的服務(wù)，用戶對(duì)產(chǎn)品是有預(yù)期的，他會(huì)預(yù)期一個(gè)新聞?lì)惪蛻舳四軌驖M足他的什么需求，所以，一定要把基礎(chǔ)需求做到極致，之后才能考慮做別的，否則做了效果也不好。
不要過度設(shè)計(jì)，考慮普適性：海量產(chǎn)品是要接受所有用戶群的。App 客戶端跟 HTML 網(wǎng)頁(yè)有一個(gè)不同在于，HTML 對(duì)于各種交互應(yīng)該如何處理都有約定俗成的規(guī)則，用戶對(duì)一個(gè)網(wǎng)頁(yè)會(huì)如何響應(yīng)自己是有預(yù)期的;而 App 則可以想怎么做就怎么做，比如 Flipboard 就做出很好的體驗(yàn)來(lái)，但是有這種自由度，反而會(huì)陷入怪圈。比如，新聞?dòng)幸粋€(gè)基礎(chǔ)需求是要切換頻道，一開始所有的客戶端都是把導(dǎo)航欄平鋪的。后來(lái)有段時(shí)間有個(gè)趨勢(shì)，很多 App 把導(dǎo)航系統(tǒng)改成了左劃的方式。比較新穎的設(shè)計(jì)方式有一個(gè)問題，就是會(huì)導(dǎo)致用戶要去想。對(duì)于比較新的設(shè)計(jì)，我們有一個(gè)簡(jiǎn)單的衡量方式：看看家里的老人能不能用這個(gè) App，只需要觀察一陣就知道適不適合上了。測(cè)試之后，我們覺得還是很土的設(shè)計(jì)比較沒有障礙，就沒有改。
要 90% 不要 80%：一個(gè)功能至少要做到 90%，最好是接近 100%。千萬(wàn)不要做很多功能，每個(gè)都是 80 分，找不到特別好的點(diǎn)。其實(shí)我們的 App 做了這么多東西，90 分的東西非常少。一共四個(gè) tab 頁(yè)面，圖片跟視頻占了兩個(gè)，但是用戶點(diǎn)進(jìn)去之前預(yù)期是什么?點(diǎn)進(jìn)去之后預(yù)期能不能達(dá)到?第二天用戶會(huì)不會(huì)回來(lái)?這些問題現(xiàn)在都沒有很好的解答，事實(shí)上現(xiàn)在我們 90% 的任務(wù)是在第一個(gè)新聞頁(yè)卡完成的，后面的 tab 都沒有做到 90 分。產(chǎn)品、技術(shù)都要想清楚，一個(gè)是因?yàn)橹挥羞@么多資源，哪個(gè)能做好就專注做好哪個(gè);另外也因?yàn)橛脩舻淖⒁饬τ邢蓿灰貌缓玫臇|西轉(zhuǎn)移他的注意力。海量產(chǎn)品的每一個(gè)位置都要想清楚它能不能達(dá)到要求。
功能多閉環(huán)，多問 now what：相對(duì)垂直小眾的產(chǎn)品，用戶使用的比較深入，可以一直往下做;但是通用產(chǎn)品很難這樣做。如果你有很多想法和設(shè)計(jì)思路，做完了原型之后要問一句：now what?舉個(gè)最簡(jiǎn)單的例子，社交化、個(gè)性化的演化。騰訊有 qq 關(guān)系鏈，所以就有人提議新聞客戶端做好友閱讀圈，看別人閱讀過、評(píng)論過的東西。于是原型做出來(lái)，用了幾天之后，有一個(gè)問題：讀了之后干什么?這是新聞，不像小說，新聞的特點(diǎn)是短、時(shí)效性強(qiáng)，用戶進(jìn)來(lái)好友閱讀圈，看幾天前看過的東西有什么用?另一個(gè)例子，就是個(gè)人中心，做個(gè)性化，比如點(diǎn)擊別人的頭像可以打開這個(gè)人發(fā)表過的評(píng)論。做了之后發(fā)現(xiàn)也有問題：進(jìn)去一看，質(zhì)量也不高，內(nèi)容也是老的，而且是流水賬居多。用戶下一步做什么?這樣的個(gè)人中心設(shè)計(jì)就很不好。所以，如果沒想清楚一個(gè)東西做出來(lái)能干什么，就不要放出去，否則收不回來(lái)。一旦放出去就會(huì)有很多挑戰(zhàn)和壓力，團(tuán)隊(duì)難以控制。
開發(fā)
快速迭代，小步快跑(動(dòng)態(tài)運(yùn)營(yíng)的開發(fā)模式)：非常多子系統(tǒng)和功能都是這么做的，這是非移動(dòng)互聯(lián)網(wǎng)就已經(jīng)認(rèn)同的原則。
快和穩(wěn)定超過精巧性：這個(gè)和干干凈凈做系統(tǒng)也是符合的，這樣做出來(lái)的東西，下一步演化、debug 問題都很輕松。
快、允許出錯(cuò)：這一點(diǎn)可能跟上面說不要隨便加?xùn)|西有些矛盾，說到底還是一個(gè)度的問題。大方向是一定要把握的，不能亂放;但是細(xì)節(jié)調(diào)整是可以更快的放出去。運(yùn)行一個(gè)版本要可以很快的糾正，這就是說你心里要有糾正的預(yù)期，放出去之前就要把功能開關(guān)都做進(jìn)去。
邊重構(gòu)邊生活：新聞客戶端的后臺(tái)從是騰訊網(wǎng)延續(xù)過來(lái)的，有很多基礎(chǔ)服務(wù)，比如評(píng)論是 5、6 年前構(gòu)建的，很老，后來(lái)的一些新功能，比如聚合回復(fù)、帶上地理位置、支持上傳圖片和短視頻，都是升級(jí)迭代上去的。這些功能的加入過程可以說是客戶端和后臺(tái)團(tuán)隊(duì)互相牽拉著走，有些時(shí)候我們客戶端送到蘋果應(yīng)用商店審核的時(shí)候后臺(tái)都還沒做好，可能審核通過的時(shí)候是后臺(tái)剛出來(lái)的時(shí)候，而且剛開始上線的時(shí)候機(jī)器、容量都沒有放到最大，都是在運(yùn)行中提高的。
運(yùn)營(yíng)
快速灰度：我們的新聞客戶端做比較快速的灰度，比如常規(guī)灰度是按周，這邊則是按天甚至小時(shí)來(lái)做灰度。為什么這樣做呢，第一，我們產(chǎn)品客戶端本身的迭代速度比較快，一般 4~6 周就有一個(gè)東西出去;第二，一個(gè)功能放出去如果不能很快灰度到一定數(shù)量級(jí)，就看不出表現(xiàn)，因?yàn)槲覀兊募夹g(shù)功能跟運(yùn)營(yíng)商分布、網(wǎng)絡(luò)穩(wěn)定性有關(guān)，灰度太小，即使放到 20%，這 20% 里面又有 20% 的波動(dòng)，誤差太大，真實(shí)的效果就看不出來(lái)。所以我們的策略就是快速推出去，實(shí)在出問題就回滾，責(zé)任我這邊擔(dān)著。
有損服務(wù)：要分清哪些業(yè)務(wù)可以有損，哪些必須無(wú)損，另外無(wú)損也有嚴(yán)格的和非嚴(yán)格的。有損服務(wù)這塊下面我會(huì)詳細(xì)介紹。
扛住再優(yōu)化：這個(gè)不需要多說。
立體監(jiān)控：很早以前我們是按網(wǎng)站的監(jiān)控級(jí)別，可能是 5 分鐘抓一次數(shù)據(jù)，這樣到移動(dòng)端就不行了，可能監(jiān)控出來(lái)有問題的時(shí)候就早已經(jīng)崩潰了，回頭看監(jiān)控?cái)?shù)據(jù)也不知道什么時(shí)間來(lái)的峰值、峰值到了多少?，F(xiàn)在我們是按 5 秒的監(jiān)控級(jí)別。
下面介紹一個(gè)有損服務(wù)實(shí)例，就是我們突發(fā)新聞 push 的一次經(jīng)驗(yàn)：
突發(fā)新聞的特點(diǎn)是瞬間峰值極高，這點(diǎn)跟其他億級(jí)產(chǎn)品有一些不同。比如馬航失聯(lián)的新聞，我們推送 iOS 客戶端在千萬(wàn)級(jí)，Android 客戶端千萬(wàn)級(jí)，發(fā)送時(shí)長(zhǎng) 2 分鐘，點(diǎn)擊率大約在 25%。我們還配了頭圖專題和圖文直播。實(shí)際上這里面還有個(gè)情況，就是我們北方節(jié)點(diǎn)的部分用戶沒有 push 到，因?yàn)楸狈焦?jié)點(diǎn)有三分之一的機(jī)器配置比其他機(jī)器低一些，但我們 push 的時(shí)候沒有調(diào)整分配規(guī)則，就導(dǎo)致這三分之一的機(jī)器死掉了，流量跑到剩下的三分之二的機(jī)器上，又把這三分之二也搞崩潰了。中間我們導(dǎo)流北方用戶到深圳節(jié)點(diǎn)，后來(lái)深圳節(jié)點(diǎn)無(wú)法承擔(dān)全國(guó)流量，又導(dǎo)回了北方?？傊歼@樣下來(lái)，最終我們的訪問量是 7 倍于日常的訪問流量，以及 3 倍于日常的接口調(diào)用數(shù)。
對(duì)于本次新聞，我們制定了如下的有損服務(wù)規(guī)則：
重點(diǎn)接口重點(diǎn)保障，次要接口有損保障：28 原則，用 60-70% 的資源保證 20% 的重要接口。另外就是緊急降級(jí)，把圖文直播自動(dòng)刷新、下拉自動(dòng)刷新等造成不必要的資源請(qǐng)求的功能取消。
緩存前移，分布化，用大量 memcache。前端 proxy 緩存，后面是 mc 集群，解決超熱 key 問題和大 key(>200K)的問題。另外設(shè)置了 5 秒的 timeout，相當(dāng)于是有損服務(wù)。
優(yōu)化 TCP 協(xié)議，提高 TCP 初始化擁塞窗口大小(從 3 改到 10)，減少 RTT，提高數(shù)據(jù)傳輸速度。
容量模型，接口設(shè)置最大連接數(shù)，通過預(yù)知及早拒絕，防止雪崩?，F(xiàn)在已經(jīng)有一些預(yù)知能力。
APC 緩存，高并發(fā)時(shí)底層頁(yè)靜態(tài)化以降低后臺(tái)請(qǐng)求。另外就是分區(qū)域保障，一線城市做為重點(diǎn)，二線城市提供有損服務(wù)。
對(duì)于新聞客戶端未來(lái)的挑戰(zhàn)，我覺得有兩點(diǎn)：
一個(gè)是視頻時(shí)代的挑戰(zhàn)。越來(lái)越多的內(nèi)容帶有視頻，而視頻帶來(lái)的流量跟圖片的數(shù)量級(jí)完全不同。這是關(guān)于突發(fā)、大流量支持方面，新聞客戶端未來(lái)的挑戰(zhàn)。
第二個(gè)是直播互動(dòng)化的挑戰(zhàn)。傳統(tǒng)媒體可能是電視或者廣播直播，一對(duì)多的模式，頂多加上熱線電話撥入做為互動(dòng)方式。而現(xiàn)在的直播是可以讓用戶直接接入并呈現(xiàn)他們的接入，這種模式會(huì)更加復(fù)雜。手機(jī)隨時(shí)隨地讓用戶可以跟蹤，參與一場(chǎng)多媒體的互動(dòng)直播。如果這個(gè) scale 推廣到微信新聞，手 Q 新聞的規(guī)模呢?在很快的將來(lái)，這些就會(huì)到來(lái)。
