摘要：回頭一想嚇一大跳自己并不是后臺(tái)工程師科班出身，從來對(duì)語言和框架的爭(zhēng)論無感無力，網(wǎng)絡(luò)編程的基礎(chǔ)知識(shí)更是差強(qiáng)人意，但是憑著小米步槍，憑著奇技淫巧，憑著持續(xù)思考和不斷嘗試，居然也能搭建起一個(gè)支撐千萬級(jí)別用戶的后臺(tái)框架。

三年前，原本我只是個(gè)不學(xué)無術(shù)的數(shù)據(jù)小碼農(nóng)，空有一腔熱情；而當(dāng)時(shí)公司也處在艱難的轉(zhuǎn)型期，舊產(chǎn)品不見起色，新產(chǎn)品前途未卜。想見著也不可能用這么小的數(shù)據(jù)玩出花來，而新產(chǎn)品的數(shù)據(jù)也不是一時(shí)半會(huì)能成規(guī)模。還是本著最大限度學(xué)習(xí)的心思，鼓足勇氣和老板提換崗，要去扛后臺(tái)開發(fā)的大旗，最大程度參與到產(chǎn)品的一線去。一個(gè)小決定，換來的是整整半年的不眠之夜，眼見著第1個(gè)用戶到第500萬個(gè)用戶，眼見著1臺(tái)到4臺(tái)再到10臺(tái)服務(wù)器，眼見著后臺(tái)業(yè)務(wù)由單一的播放到能播放能上傳再到有完整的社交交互。從剛開始三天兩頭崩潰出事故，到最終一點(diǎn)不怕市場(chǎng)的同事搞拉新的活動(dòng)，什么狀況都能做到心中有數(shù)、遇事不慌?；仡^一想嚇一大跳：自己并不是后臺(tái)工程師科班出身，從來對(duì)語言和框架的爭(zhēng)論無感無力，網(wǎng)絡(luò)編程的基礎(chǔ)知識(shí)更是差強(qiáng)人意，但是憑著小米步槍，憑著奇技淫巧，憑著持續(xù)思考和不斷嘗試，居然也能搭建起一個(gè)支撐千萬級(jí)別用戶的后臺(tái)框架。總結(jié)那半年，留下了5條事關(guān)生死的建議，在這里泣血奉上。

一個(gè)完整的后臺(tái)服務(wù)，組件其實(shí)就只分3種：接入、邏輯和數(shù)據(jù)。這好比一家飯店，后臺(tái)工程師就是開店的老板，客人數(shù)量小于1萬，服務(wù)流程是第一位的，老板們吭哧吭哧忙著寫邏輯；1萬到10萬之間，接入組件的設(shè)計(jì)會(huì)是重中之重：一個(gè)店的服務(wù)能力有限，老板們忙著多開幾個(gè)分店，讓客人分流，而決定客人到哪一個(gè)分店的，就是接入組件；但是用戶一旦大于10萬，數(shù)據(jù)的讀寫能力就決定了這家超級(jí)飯店的服務(wù)容量，不管開多少個(gè)分店，都要保證數(shù)據(jù)是一致的，讀起來又快又準(zhǔn)，而寫數(shù)據(jù)不會(huì)影響到讀的性能。表結(jié)構(gòu)怎么設(shè)計(jì)，數(shù)據(jù)庫(kù)怎么分布（主從、讀寫分離、分庫(kù)、分表），緩存怎么選怎么分布，就是老板們最重要的工作（讓老板高興的是，名片也可以改印個(gè)高大上的抬頭：架構(gòu)師）。

一旦用戶量過了十萬，要再想光靠數(shù)據(jù)庫(kù)一部卡車打天下就不太現(xiàn)實(shí)了，而緩存（物理存儲(chǔ)地在內(nèi)存，天生比數(shù)據(jù)庫(kù)讀寫性能強(qiáng)）這匹野馬的出現(xiàn)就滿足了我們對(duì)于速度的極致需求。緩存對(duì)服務(wù)器的架構(gòu)帶來了兩個(gè)深遠(yuǎn)的影響：一是熱數(shù)據(jù)和冷數(shù)據(jù)的分離：熱數(shù)據(jù)訪問的人多，緩存擋在前面，為數(shù)據(jù)庫(kù)分擔(dān)巨大的讀壓力；而熱數(shù)據(jù)從產(chǎn)品的角度也更應(yīng)獲得快速的響應(yīng)。二是數(shù)據(jù)一致性的門檻提高，更新數(shù)據(jù)庫(kù)的同時(shí)必須更新緩存，一旦緩存更新失敗，數(shù)據(jù)庫(kù)也一定要回滾而保證數(shù)據(jù)的一致性，不能鬧給客人上冷菜的笑話。當(dāng)然緩存存什么、怎么存，也是大有一番學(xué)問，容我下一小節(jié)再講。但緩存的重要性總結(jié)一句話：沒有緩存是萬萬不能的。無論你是選老馬Memcached還是火熱的頭馬Redis，一定要在數(shù)據(jù)庫(kù)感受到壓力之前上馬，并且做好緩存?zhèn)浞莺突謴?fù)的預(yù)案。當(dāng)然，平安無事你是沒辦法感受到緩存的好處的，它就像一個(gè)平時(shí)提醒你吃飯睡覺多喝熱水的備胎，只有當(dāng)她棄你而去之時(shí)，你看著服務(wù)器嘩嘩成百倍上漲的響應(yīng)時(shí)間，恨不得找塊豆腐一頭撞死。

Web時(shí)代，由于翻頁(yè)前后用戶出現(xiàn)了界面的切換，用戶對(duì)于列表本身的變化并不敏感（假如翻頁(yè)的同時(shí)列表新加入了內(nèi)容，只要保證用戶瀏覽的這個(gè)片段沒有重復(fù)就可以），但是移動(dòng)端這種滾動(dòng)列表的設(shè)計(jì)簡(jiǎn)直就是所有后臺(tái)工程師的夢(mèng)魘（加入用戶上拉列表獲取更多的同時(shí)新加入了內(nèi)容，那用戶會(huì)看到相鄰兩個(gè)重復(fù)的內(nèi)容，然后就氣炸了，什么破APP！），應(yīng)對(duì)「列表重復(fù)」這個(gè)難題的方法出一本書都?jí)蛄恕Ｒ驗(yàn)檫@個(gè)需求，我們只能放棄了原有的自增ID，采用時(shí)間戳作為獲取列表片段的方式：簡(jiǎn)單來講，就是客戶端每次都上報(bào)一個(gè)當(dāng)前頁(yè)最后一個(gè)內(nèi)容的時(shí)間戳，服務(wù)器再去取比這個(gè)時(shí)間更舊的若干個(gè)內(nèi)容。這里必須要感謝Redis的作者提供了如此豐富的緩存使用的API，我覺得Redis最出色的一點(diǎn)就是把列表的所有使用場(chǎng)景都設(shè)想得很通透。

實(shí)體就是熱數(shù)據(jù)，熱數(shù)據(jù)的緩存有兩問：一是存什么？有人會(huì)說簡(jiǎn)單，把整個(gè)結(jié)構(gòu)體轉(zhuǎn)化為一個(gè)JSON存進(jìn)去不就得了？但這其實(shí)是有問題的，當(dāng)你的服務(wù)器要面對(duì)數(shù)十萬同時(shí)到來的用戶，可能短短一瞬就要做數(shù)以千萬計(jì)的JSON到結(jié)構(gòu)體之間的來回切換，而這個(gè)過程的效率實(shí)際上是很不理想的，那么也許你要想一些更快的方案（此處買個(gè)關(guān)子）。二是怎么存？雪崩效應(yīng)并不罕見，一旦源數(shù)據(jù)改變，一時(shí)間許多個(gè)線程同時(shí)去訪問更新緩存的API，服務(wù)器瞬間堵死，想到后臺(tái)工程師會(huì)因此而失業(yè)，我默默加了一個(gè)鎖。

小張是端菜的服務(wù)員，這次上菜，他要先去涼菜區(qū)取個(gè)土豆絲、再去葷菜區(qū)取個(gè)東坡肉、順到素菜區(qū)取個(gè)手撕包菜、最后到飲料區(qū)再拎兩瓶果汁，聽起來很低效，對(duì)不？這和數(shù)據(jù)獲取的過程是類似的，數(shù)據(jù)庫(kù)的表設(shè)計(jì)首要考慮的是歸類，比如用戶的信息存一張表，用戶和小組的關(guān)系再存一張表，那么如果有一個(gè)場(chǎng)景需要讀用戶以及他最后訪問過的小組，就得做兩次的數(shù)據(jù)表讀取，一旦這個(gè)場(chǎng)景頻繁出現(xiàn)，適當(dāng)?shù)臄?shù)據(jù)冗余（把用戶最后訪問的小組ID加入到用戶表的字段中）就能夠降低數(shù)據(jù)庫(kù)的讀取壓力。所以表設(shè)計(jì)一定一定一定（重要的事情說三遍）要考慮業(yè)務(wù)場(chǎng)景。

有的小盆友跑來問我，我這個(gè)服務(wù)器框架選的牛啊，異步多線程的，單進(jìn)程并發(fā)一萬多輕而易舉，怎么還是慢啊？我說，「異步」這個(gè)詞可不要說得太輕松，底層異步了，流程里的每個(gè)步驟是不是異步的呢？數(shù)據(jù)庫(kù)讀寫、緩存讀寫、外部接口的訪問，這些都不能異步吧？既然不是異步，卡在哪里你還不知道呢，還不趕緊打日志。還是說說最令我崩潰的一個(gè)案例：某次服務(wù)器炸了，打多少次日志都沒辦法定位到卡住的原因。最后猜是怎么著？竟然是日志組件（Log4j）就不是異步的，打日志這個(gè)步驟就卡住了，欲哭無淚。

一個(gè)高級(jí)飯店要有廚師，要有大堂經(jīng)理，要有端盤子的，要有收銀的，但千萬別忘了還要有保安。他雖然不是飯店成功與否的核心因素，但是如果缺了他，危機(jī)時(shí)刻就會(huì)應(yīng)付不來。下面這三位哥們就是服務(wù)器的保安：日志、監(jiān)控和有損服務(wù)。

先說日志，日志是很微妙的，打多了不行，影響性能、占據(jù)空間，打少了，關(guān)鍵問題排查不出原因。那么哪些是必打的呢？我認(rèn)為有三點(diǎn)：一是行為的基本屬性，無非是何時(shí)何地何人，時(shí)間、用戶ID、IP、版本（存下來除了排錯(cuò)，還可以用來做數(shù)據(jù)分析）；二是往返的參數(shù)，尤其是客戶端上報(bào)的參數(shù)，服務(wù)器返回的數(shù)據(jù)也許會(huì)很大，不建議所有都打印，可以打印統(tǒng)計(jì)數(shù)據(jù)，比如返回了多少個(gè)小組之類；三是報(bào)錯(cuò)信息，底層一定要catch所有的出錯(cuò)信息，并把它打到多帶帶的日志里。

再說監(jiān)控，日志是一旦發(fā)現(xiàn)了問題幫助我們找出問題的原因的工具，那么什么能幫我們發(fā)現(xiàn)問題呢？答案是監(jiān)控和告警。監(jiān)控與日志不同，要抓核心的數(shù)據(jù)，不能多，我建議取三個(gè)數(shù)據(jù)：用戶的并發(fā)訪問數(shù)、讀取的人均響應(yīng)時(shí)間、寫入的人均響應(yīng)時(shí)間，告警的話再加上服務(wù)器的崩潰、重啟的次數(shù)，以及主機(jī)性能相關(guān)的指標(biāo)（CPU、內(nèi)存、硬盤等）。

「發(fā)生這種事，大家都不想的。餓不餓，我給你煮碗面？」，服務(wù)器運(yùn)氣不好崩潰了，我便常常用這句TVB的經(jīng)典臺(tái)詞與小伙伴們調(diào)侃。其實(shí)無論事前機(jī)關(guān)算盡，成長(zhǎng)期的APP總會(huì)遇到服務(wù)器出狀況的。但是，以我有限的經(jīng)驗(yàn)，服務(wù)器的問題往往不出在自身，而是它所依賴組件導(dǎo)致的問題，比如Memcached機(jī)器dump、轉(zhuǎn)碼服務(wù)隊(duì)列阻塞、或者圖片存儲(chǔ)空間爆滿等等。那么在問題被解決之前，總不能干瞪眼，看著用戶投訴一波波來吧？我們會(huì)想，對(duì)于現(xiàn)在的業(yè)務(wù)來說，最不能崩潰的場(chǎng)景是什么？比如播放是我們的最基礎(chǔ)服務(wù)，那我們死也要保證任何外部組件的崩潰都不能影響熱門內(nèi)容的播放，因此我們要把這部分少而重要的熱數(shù)據(jù)加載到內(nèi)存，以防止外部存儲(chǔ)出了什么問題，服務(wù)器自己還有碗面吃。真正是，自己的事情自己干，靠天靠地靠祖宗，不算是好漢。

服務(wù)器體系越長(zhǎng)越大，我們首要做的事情是分封，兒子長(zhǎng)大了，總要給他一塊地盤，當(dāng)個(gè)小王，從此自己打拼去。于是數(shù)據(jù)讀寫被抽象成服務(wù)了，同時(shí)對(duì)APP和前端負(fù)責(zé)，做最大的一個(gè)王；編碼解碼抽象成服務(wù)了，反正編碼解碼是給UGC用戶提供的，想當(dāng)明星的人總要等得起；日志存儲(chǔ)和解析也抽象成服務(wù)了，反正有少許的丟失我們也不介意。表面看來服務(wù)器被拆得支離破碎，增加了網(wǎng)絡(luò)時(shí)延，是一筆不劃算的生意，但實(shí)際上對(duì)服務(wù)器的穩(wěn)定性大有助益。為什么？一是大王國(guó)被拆成小王國(guó)了，定位問題更容易，遷移和復(fù)制也更簡(jiǎn)單，數(shù)據(jù)讀寫有壓力？沒問題！再給兩塊地盤。二是在整個(gè)鏈條上，任何一個(gè)環(huán)節(jié)都是多點(diǎn)，俗話說，不把雞蛋都放在一個(gè)籃子，任何一臺(tái)服務(wù)器dump都不會(huì)要了我們的命。

細(xì)枝末節(jié)且不提，總結(jié)當(dāng)時(shí)半年內(nèi)服務(wù)器高速發(fā)展期留下來的經(jīng)驗(yàn)，我認(rèn)為最重要的就是這五點(diǎn)，業(yè)務(wù)場(chǎng)景不同，服務(wù)器的架構(gòu)和側(cè)重點(diǎn)也肯定會(huì)略有差異；不過這五點(diǎn)基本等同于錦囊，等同于基石，等同于保命符，做好了，這飯店生意一定蒸蒸日上。恭喜你，老板！

更多精彩內(nèi)容，歡迎關(guān)注微信公眾號(hào)「碼農(nóng)咖啡館」