【原標(biāo)題：【不厚的后臺(tái)】沒(méi)硬學(xué)歷怎樣賺錢(qián) 從技術(shù)演變后臺(tái)架構(gòu)】財(cái)金網(wǎng)消息 其實(shí)內(nèi)容都是些常見(jiàn)開(kāi)源組件的high level描述，比如Flask，Express框架，中間件的演化，Microservices的概念，一些對(duì)NoSQL/Column based DB的概念介紹，Docker的一些簡(jiǎn)單概念等等。從單個(gè)概念來(lái)說(shuō)，這只是一些科普。

但是為什么當(dāng)時(shí)要開(kāi)這門(mén)課呢？重點(diǎn)是我發(fā)現(xiàn)很多新入職的后臺(tái)開(kāi)發(fā)同學(xué)并不太清楚自己做的東西在現(xiàn)代互聯(lián)網(wǎng)整體架構(gòu)中處于一個(gè)什么樣的角色，而在IEG內(nèi)部則因?yàn)橛螒蜷_(kāi)發(fā)和互聯(lián)網(wǎng)開(kāi)發(fā)的一些歷史性差異，有些概念并不清晰。

拿中間件來(lái)說(shuō)，很多Web application不用啥中間件一樣可以跑很好，那么是不是都要上Redis？到底解決什么問(wèn)題？中間件又存在什么問(wèn)題？中臺(tái)和中間件又是個(gè)什么關(guān)系？如果開(kāi)個(gè)MQ就是中間件，微服務(wù)又是要做啥？

如果能從這十多年來(lái)互聯(lián)網(wǎng)應(yīng)用的整個(gè)Tech stack變化去看待backend architecture的一些改變，應(yīng)該是一件有趣也有意思的事情。這是當(dāng)時(shí)寫(xiě)這個(gè)PPT開(kāi)課的初衷。

我不敢說(shuō)我在這個(gè)PPT里面的一些私貨概念就是對(duì)的，但是也算是個(gè)人這么多年的一些認(rèn)知理解，拋磚引玉吧。

強(qiáng)調(diào)一點(diǎn)，這個(gè)PPT的初衷是希望從近十多年來(lái)不同時(shí)代不同熱點(diǎn)下技術(shù)棧的變化來(lái)看看我們是如何從最早的PHP/ASP/JSP<=>MySQL這樣的兩層架構(gòu)，一個(gè)階段一個(gè)階段演變到現(xiàn)在繁復(fù)的大數(shù)據(jù)、機(jī)器學(xué)習(xí)、消息驅(qū)動(dòng)、微服務(wù)架構(gòu)這樣的體系，然后在針對(duì)其中比較重要的幾個(gè)方面來(lái)給新入門(mén)后臺(tái)開(kāi)發(fā)的同學(xué)起個(gè)“提綱目錄”的作用。如果要對(duì)每個(gè)方面都深入去談，那肯定不是一兩頁(yè)P(yáng)PT就能做到的事情。

下面我們開(kāi)始。首先看第一頁(yè)如下圖：什么是System Design？什么是架構(gòu)設(shè)計(jì)？為什么要談架構(gòu)設(shè)計(jì)？

之所以拋出這個(gè)問(wèn)題，是因?yàn)槠綍r(shí)常常聽(tīng)到兩個(gè)互相矛盾的說(shuō)法：一方面很多人愛(ài)說(shuō)“架構(gòu)師都是不干活夸夸其談”，另一方面又有很多人苦惱限于日常業(yè)務(wù)需求開(kāi)發(fā)，無(wú)法或者沒(méi)有機(jī)會(huì)去從整體架構(gòu)思考，不知道怎么成長(zhǎng)為架構(gòu)師。

上面PPT中很有趣的是第一句英文，翻譯過(guò)來(lái)恰好可以反映了論壇上經(jīng)常有人問(wèn)的“如何學(xué)習(xí)架構(gòu)”的問(wèn)題：很多l(xiāng)eader一來(lái)就是扔幾本書(shū)（書(shū)名）給新同學(xué)，期望他們讀完書(shū)就馬上升級(jí)……這種一般都只會(huì)帶來(lái)失望。

何為架構(gòu)師？不寫(xiě)代碼只畫(huà)PPT？

不是的，架構(gòu)師的基本職責(zé)是要在項(xiàng)目早期就能設(shè)計(jì)好基本的框架，這個(gè)框架能夠確保團(tuán)隊(duì)成員順利coding滿足近期內(nèi)業(yè)務(wù)需求的變化，又能為進(jìn)一步的發(fā)展留出空間（所謂scalability），這即是所謂技術(shù)選型。如何確保選型正確？對(duì)于簡(jiǎn)單的應(yīng)用，或者沒(méi)有新意完全是實(shí)踐過(guò)多次的相同方案，確實(shí)靠幾頁(yè)P(yáng)PT足矣。但是對(duì)于新的領(lǐng)域新的復(fù)雜需求，這個(gè)需求未必都是業(yè)務(wù)需求，也包括根據(jù)團(tuán)隊(duì)自身特點(diǎn)（人員太多、太少、某些環(huán)節(jié)成員不熟悉需要?jiǎng)冸x開(kāi)）來(lái)進(jìn)行新的設(shè)計(jì)，對(duì)現(xiàn)有技術(shù)重新分解組合，這時(shí)候就需要架構(gòu)師自己編碼實(shí)現(xiàn)原型并驗(yàn)證思路正確性。

要達(dá)到這樣的目標(biāo)難不難？難！但是現(xiàn)在不是2000年了，是2019年了，大量的框架（framework）、開(kāi)源工具和各種best practice，其實(shí)都是在幫我們解決這件事情。而這些框架并不是憑空而來(lái)，而是在這十多年互聯(lián)網(wǎng)的演化中因?yàn)橐鉀Q各種具體業(yè)務(wù)難點(diǎn)而一點(diǎn)一點(diǎn)積累進(jìn)化而來(lái)。無(wú)論是從MySQL到MongoDB到Cassandra到Time Series DB，或者從Memcached到Redis，從Lucene到Solr到Elasticsearch，從離線批處理到Hadoop到Storm到Spark到Flink，技術(shù)不是突然出現(xiàn)的，總是站在前人的肩膀上不斷演變的。而要能在浩如煙海的現(xiàn)代互聯(lián)網(wǎng)技術(shù)棧中選擇合適的來(lái)組裝自己的方案，則需要對(duì)技術(shù)的來(lái)源和歷史有一定的了解。否則就會(huì)出現(xiàn)一些新人張口ELK，閉口TensorFlow，然后一個(gè)簡(jiǎn)單的異步消息處理就會(huì)讓他們張口結(jié)舌的現(xiàn)象。

20多年前的經(jīng)典著作DesignPatterns中講過(guò)學(xué)習(xí)設(shè)計(jì)模式的意義，放在這里非常經(jīng)典：學(xué)習(xí)設(shè)計(jì)模式并不是要你學(xué)習(xí)一種新的技術(shù)或者編程語(yǔ)言，而是建立一種交流的共同語(yǔ)言和詞匯，在方案設(shè)計(jì)時(shí)方便溝通，同時(shí)也幫助人們從更抽象的層次去分析問(wèn)題本質(zhì)，而不被一些實(shí)現(xiàn)的細(xì)枝末節(jié)所困擾。同時(shí)，當(dāng)我們能把很多問(wèn)題抽象出來(lái)之后，也能幫我們更深入更好地去了解現(xiàn)有系統(tǒng)-------這些意義，對(duì)于今天的后端系統(tǒng)設(shè)計(jì)來(lái)說(shuō)，也仍然是正確的。

下圖是我們要談的幾個(gè)主要方面。

上面的幾個(gè)主題中，第一個(gè)后臺(tái)架構(gòu)的演化是自己從業(yè)十多年來(lái)，體會(huì)到的互聯(lián)網(wǎng)技術(shù)架構(gòu)的整體變遷。然后分成后臺(tái)前端應(yīng)用框架、Middleware和存儲(chǔ)三大塊談一下，最后兩節(jié)微服務(wù)和Docker則是給剛進(jìn)入后臺(tái)開(kāi)發(fā)的同學(xué)做一些概念普及。其中個(gè)人覺(jué)得最有趣的，是第一部分后臺(tái)架構(gòu)的演化和第三部分的中間件，因?yàn)檫@兩者是很好地反映了過(guò)去十多年互聯(lián)網(wǎng)發(fā)展期間技術(shù)棧的變化，從LAMP到MEAN Stack，從各種繁復(fù)的中間層到漸漸統(tǒng)一的消息驅(qū)動(dòng)+流處理，每個(gè)階段的業(yè)界熱點(diǎn)都相當(dāng)有代表性。

當(dāng)然，不是說(shuō)Web框架、數(shù)據(jù)存儲(chǔ)就不是熱點(diǎn)了，姑且不說(shuō)這幾年Web前端的復(fù)雜化，光后端應(yīng)用框架，Node的Express，Python的Django/Flask，Go在國(guó)內(nèi)的盛行，都是相當(dāng)有趣的。在數(shù)據(jù)存儲(chǔ)領(lǐng)域，列存儲(chǔ)和時(shí)序數(shù)據(jù)隨著物聯(lián)網(wǎng)的發(fā)展也是備受重視。但是篇幅所限，在這個(gè)課程中這些話題也就只能一帶而過(guò)，因?yàn)檫@些與其說(shuō)是技術(shù)的演變過(guò)程，不如說(shuō)是不同的技術(shù)選型和方向了，比如說(shuō)MySQL適合OLTP（Online Transaction Processing），而Cassandra/HBase等則適合OLAP（Online Analyical Processing），并不能說(shuō)后者就優(yōu)于前者。

下面我們先來(lái)看后臺(tái)架構(gòu)的演化。

嚴(yán)格說(shuō)這是個(gè)很大的標(biāo)題，從2000年到現(xiàn)在的故事太多了，我這里只能盡力而為從個(gè)人體驗(yàn)來(lái)分析。

首先是2008年以前，我把它稱為網(wǎng)站時(shí)代。為什么這么說(shuō)？因?yàn)槟菚r(shí)候的后臺(tái)開(kāi)發(fā)就是寫(xiě)網(wǎng)站，而且通常是頁(yè)面代碼和后臺(tái)數(shù)據(jù)邏輯一起寫(xiě)。你只要能寫(xiě)JSP/PHP/ASP來(lái)讀寫(xiě)MySQL或者SQL Server，基本就能保證一份不錯(cuò)的工作了。

要強(qiáng)調(diào)一下，這種簡(jiǎn)單的兩層結(jié)構(gòu)并不能說(shuō)就是落后。在現(xiàn)在各個(gè)企業(yè)、公司以及小團(tuán)隊(duì)的大量Web應(yīng)用包括移動(dòng)App的后端服務(wù)中，采用這種架構(gòu)的不在少數(shù)，尤其是很多公司、學(xué)校、企業(yè)的內(nèi)部服務(wù)，用這種架構(gòu)已經(jīng)足夠了。

注意一個(gè)時(shí)間節(jié)點(diǎn)：2008。

當(dāng)然，這個(gè)節(jié)點(diǎn)是我YY的。這個(gè)節(jié)點(diǎn)可以是2007，或者2006。這個(gè)時(shí)間段發(fā)生了兩個(gè)影響到現(xiàn)在的事情：Google上市，F(xiàn)acebook開(kāi)始推開(kāi)。

我個(gè)人相信前者上市加上它發(fā)表的那三篇大數(shù)據(jù)paper影響了后來(lái)業(yè)界的技術(shù)方向，后者的火熱則造成了社交成為業(yè)務(wù)熱點(diǎn)。偏偏社交網(wǎng)站對(duì)大數(shù)據(jù)處理有著天然的需求，技術(shù)的積累和業(yè)務(wù)的需求就這么陰差陽(yáng)錯(cuò)完美結(jié)合了起來(lái)，直接影響了大海那邊后面的科技發(fā)展。

同時(shí)在中國(guó)，那個(gè)時(shí)候卻是網(wǎng)絡(luò)游戲MMO的黃金年代，對(duì)單機(jī)單服高并發(fā)實(shí)時(shí)交互的需求，遠(yuǎn)遠(yuǎn)壓過(guò)了對(duì)海量數(shù)據(jù)Data mining的需要，在這個(gè)時(shí)間點(diǎn)，中美兩邊的互聯(lián)網(wǎng)科技樹(shù)發(fā)生了比較大的分叉。這倒是并沒(méi)有優(yōu)劣之說(shuō)，只是業(yè)務(wù)場(chǎng)景的重要性導(dǎo)致了技能樹(shù)的側(cè)重。直到今天，單機(jī)（包括簡(jiǎn)單的多服務(wù)器方案）高并發(fā)、高QPS仍然也是國(guó)內(nèi)業(yè)界所追求的目標(biāo)，而在美國(guó)那邊，這只是一個(gè)業(yè)務(wù)指標(biāo)而已，更看重的是如何進(jìn)行水平擴(kuò)展（horizontal scaling）和分散壓力。

國(guó)內(nèi)和美國(guó)的科技樹(shù)回到一條線上，大數(shù)據(jù)的業(yè)務(wù)需求和相關(guān)技術(shù)發(fā)展緊密結(jié)合起來(lái)，可能要到2014年左右，隨著互聯(lián)網(wǎng)創(chuàng)業(yè)的盛行，O2O業(yè)務(wù)對(duì)大數(shù)據(jù)實(shí)時(shí)處理、機(jī)器學(xué)習(xí)推薦提出了真正的需求時(shí)，才是國(guó)內(nèi)業(yè)界首次出現(xiàn)技術(shù)驅(qū)動(dòng)業(yè)務(wù)，算法驅(qū)動(dòng)產(chǎn)品的現(xiàn)象，重新和美國(guó)灣區(qū)那邊站在了一條線上，而這則是后話了。

到了2010年前后，F(xiàn)acebook在全球已經(jīng)是現(xiàn)象級(jí)產(chǎn)品，當(dāng)時(shí)微軟直接放棄了Windows Live，就是為了避免在社交領(lǐng)域硬懟Facebook。八卦一下當(dāng)時(shí)在美國(guó)灣區(qū)那邊聚餐的時(shí)候，如果誰(shuí)說(shuō)他是Facebook的，那基本就是全場(chǎng)羨慕的焦點(diǎn)。

Facebook的崛起也帶動(dòng)了其他大量的社交網(wǎng)站開(kāi)始出現(xiàn)，社交網(wǎng)站最大的特點(diǎn)就是頻繁的用戶搜索、推薦，當(dāng)用戶上億的時(shí)候，這就是前面?zhèn)鹘y(tǒng)的兩層架構(gòu)無(wú)法處理的問(wèn)題了。因此這就帶動(dòng)了中間件的發(fā)展。實(shí)際上在國(guó)外很少有人用中間件或者M(jìn)iddelware這個(gè)詞，更多是探討如何把各種Service集成在一起，像國(guó)內(nèi)這樣強(qiáng)行分成Frontend/Middleware/Storage的概念是沒(méi)聽(tīng)人這么談過(guò)的，后面中間件再說(shuō)這問(wèn)題。當(dāng)時(shí)的一個(gè)慣例是用PHP做所謂的膠水語(yǔ)言（glue language），然后通過(guò)Hessian這些協(xié)議工具來(lái)把其他Java服務(wù)連接到一起。與此同時(shí)，為了提高訪問(wèn)速度，降低后端查詢壓力，Memcached/Redis也開(kāi)始大量使用?；贚ucene的搜索（2010左右很多是自行開(kāi)發(fā)）或者Solr也被用在用戶搜索、推薦以及Typeahead這些場(chǎng)景中。

我記憶中在2012年之前消息隊(duì)列的使用還不是太頻繁，不像后來(lái)這么重要。當(dāng)時(shí)常見(jiàn)的應(yīng)該就是Beanstalkd/RabbitMQ，ZeroMQ其實(shí)我在灣區(qū)那邊很少聽(tīng)人用，倒是后來(lái)回國(guó)后看到國(guó)內(nèi)用的人還不少。Kafka在2011年已經(jīng)出現(xiàn)了，有少部分公司開(kāi)始用，不過(guò)還不是主流。

2013年之后就是大數(shù)據(jù)+云的時(shí)代了，如果大家回想一下，基本上國(guó)內(nèi)也是差不多在2014年左右開(kāi)始叫出了云+大數(shù)據(jù)的口號(hào)（2013年國(guó)內(nèi)還在手游狂潮中……）。不談國(guó)外，在中國(guó)那段時(shí)間就是互聯(lián)網(wǎng)創(chuàng)業(yè)的時(shí)代，從千團(tuán)大戰(zhàn)到手游爆發(fā)到15年開(kāi)始的O2O，業(yè)務(wù)的發(fā)展也帶動(dòng)了技術(shù)棧的飛速進(jìn)步。左上角大致上也寫(xiě)了這個(gè)時(shí)代互聯(lián)網(wǎng)業(yè)界的主要技術(shù)熱點(diǎn)，實(shí)際上這也就是現(xiàn)在的熱點(diǎn)。無(wú)論國(guó)內(nèi)國(guó)外，絕大部分公司還并沒(méi)有離開(kāi)云+大數(shù)據(jù)這個(gè)時(shí)代。無(wú)論是大數(shù)據(jù)的實(shí)時(shí)處理、數(shù)據(jù)挖掘、推薦系統(tǒng)、Docker化，包括A/B測(cè)試，這些都是很多企業(yè)還正在努力全面解決的問(wèn)題。

但是在少數(shù)站在業(yè)界技術(shù)頂端或者沒(méi)有歷史技術(shù)包袱的新興公司，從某個(gè)角度上來(lái)說(shuō)，他們已經(jīng)開(kāi)始在往下一個(gè)時(shí)代前進(jìn)：機(jī)器學(xué)習(xí)AI驅(qū)動(dòng)的時(shí)代。

2018年開(kāi)始，實(shí)際上可能是2017年中開(kāi)始，AI驅(qū)動(dòng)成了各大公司口號(hào)。上圖是Facebook和Uber的機(jī)器學(xué)習(xí)平臺(tái)使用情況，基本上已經(jīng)全部進(jìn)入業(yè)務(wù)核心。當(dāng)然并不是說(shuō)所有公司企業(yè)都要AI驅(qū)動(dòng)，顯然最近發(fā)生的波音737事件就說(shuō)明該用傳統(tǒng)的就該傳統(tǒng)，別啥都往并不成熟的AI上堆。但另一方面，很多新興公司的業(yè)務(wù)本身就是基于大數(shù)據(jù)或者算法的，因此他們?cè)谶@個(gè)領(lǐng)域也往往走得比較激進(jìn)。由于這個(gè)AI驅(qū)動(dòng)還并沒(méi)有一個(gè)很明確的定義和概念，還處于一種早期萌芽的階段，在這里也就不多YY了。

互聯(lián)網(wǎng)后臺(tái)架構(gòu)發(fā)展的簡(jiǎn)單過(guò)程就在這里講得差不多了，然后我們快速談一下Web開(kāi)發(fā)框架。

首先在前面我提到，在后端架構(gòu)中其實(shí)也有所謂的Frontend（前臺(tái)）開(kāi)發(fā)存在，一般來(lái)說(shuō)這是指響應(yīng)用戶請(qǐng)求，實(shí)現(xiàn)具體業(yè)務(wù)邏輯的業(yè)務(wù)邏輯層。當(dāng)然這么定義略微粗糙了些，很多中間存儲(chǔ)、消息服務(wù)也會(huì)封裝一些業(yè)務(wù)相關(guān)邏輯?？傊甒eb開(kāi)發(fā)框架往往就是為了更方便地實(shí)現(xiàn)這些業(yè)務(wù)邏輯而存在的。

前文提到在一段較長(zhǎng)時(shí)間內(nèi)，國(guó)內(nèi)的技術(shù)熱點(diǎn)是單機(jī)高并發(fā)高QPS，因此很多那個(gè)時(shí)代走過(guò)來(lái)的人會(huì)本能地質(zhì)疑Web框架的性能，而更偏好TCP長(zhǎng)鏈接甚至UDP協(xié)議。然而這往往是自尋煩惱，因?yàn)槌_(kāi)特別的強(qiáng)實(shí)時(shí)系統(tǒng)，無(wú)論是休閑手游、視頻點(diǎn)播還是信息流，都已經(jīng)是基于HTTP的了。

上圖所提到的兩個(gè)問(wèn)題中，我想強(qiáng)調(diào)的是第一點(diǎn)：所有的業(yè)務(wù)，在能滿足需求的情況下，首選HTTP協(xié)議進(jìn)行數(shù)據(jù)交互。準(zhǔn)確點(diǎn)說(shuō)，首選JSON，使用Web API。

Why？這就是上圖第一個(gè)問(wèn)題所回答的：無(wú)狀態(tài)、易調(diào)試易修改、一般沒(méi)有80端口限制。

最為詬病的無(wú)非是性能，然而實(shí)際上對(duì)非實(shí)時(shí)應(yīng)用，晚個(gè)半秒一秒不應(yīng)該是大問(wèn)題，要考慮的是水平擴(kuò)展scalability，不是實(shí)時(shí)響應(yīng)（因?yàn)榍疤峋褪欠菍?shí)時(shí)應(yīng)用）；其次實(shí)在不行你還有WebSocket可以用。

這一部分是簡(jiǎn)單列舉了一下不同框架的使用，可以看出不同框架的概念其實(shí)差不多。重點(diǎn)是要注意到Middleware這個(gè)說(shuō)法在Web Framework和后端架構(gòu)中的意義不同。在Web Framework中是指具體處理GET/POST這些請(qǐng)求之前的一個(gè)通用處理（往往是鏈?zhǔn)秸{(diào)用），比如可以把鑒權(quán)、一些日志處理和請(qǐng)求記錄放在這里。但在后端架構(gòu)設(shè)計(jì)中的Middleware則是指類似消息隊(duì)列、緩存這些在最終數(shù)據(jù)庫(kù)之前的中間服務(wù)組件。

最后這里是想說(shuō)Web Framework并不是包治百病，實(shí)際上那只是提供了基礎(chǔ)功能的一個(gè)library，作為開(kāi)發(fā)者則更多需要考慮如何定義配置文件，一些敏感參數(shù)如token、密碼怎么傳進(jìn)來(lái)，開(kāi)發(fā)環(huán)境和生產(chǎn)環(huán)境的配置如何自動(dòng)切換，單元測(cè)試怎么搞，代碼目錄怎么組織。有時(shí)候我們可以用一些比如Yeoman之類的Scaffold工具來(lái)自動(dòng)生成項(xiàng)目代碼框架，或者類似Django這種也可能自動(dòng)生成基本目錄結(jié)構(gòu)。

下面進(jìn)入Middleware環(huán)節(jié)。Again，強(qiáng)調(diào)一下這里只是根據(jù)個(gè)人經(jīng)驗(yàn)和感受談?wù)勓莼^(guò)程。

這一頁(yè)只是大致講一下怎么定義中間件Middleware。說(shuō)句題外話，在美國(guó)灣區(qū)那邊提這個(gè)概念的很少，而阿里又特別喜歡說(shuō)中間件，兩者相互的交流非常頭痛。灣區(qū)那邊不少Google、Facebook還有Pinterest/Uber這些的朋友好幾次都在群里問(wèn)說(shuō)啥叫中間件。

中間件這個(gè)概念很含糊，應(yīng)該是阿里提出來(lái)的，對(duì)應(yīng)于Middleware（不過(guò)似乎也不是完全對(duì)應(yīng)），可能是因?yàn)樵缙贘ava的EJB那些概念里面比較強(qiáng)調(diào)Middleware這一點(diǎn)吧（個(gè)人猜的）。大致上，如果我們把Web后端分為直接處理用戶請(qǐng)求的Frontend，最后對(duì)數(shù)據(jù)進(jìn)行持久存儲(chǔ)（persistant storage）這兩塊，那么中間對(duì)數(shù)據(jù)的所有處理環(huán)節(jié)都可以視為Middleware。

和中間件對(duì)應(yīng)的另一個(gè)阿里發(fā)明的概念是中臺(tái)。近一年多阿里的中臺(tái)概念都相當(dāng)引人注意，這里對(duì)中臺(tái)不做太多描述?？傮w來(lái)說(shuō)中臺(tái)更多是偏向業(yè)務(wù)和組織架構(gòu)劃分，不能說(shuō)是一個(gè)技術(shù)概念，也不是面向開(kāi)發(fā)人員的。而中間件Middleware是標(biāo)準(zhǔn)的技術(shù)組件服務(wù)。

那么我們自然會(huì)有一個(gè)問(wèn)題：為什么要用中間件？

談到為什么要用Middlware，這里用推薦系統(tǒng)舉例。

推薦系統(tǒng)，對(duì)數(shù)據(jù)少用戶少的情況下，簡(jiǎn)單的MySQL即可，比如早期論壇的什么top 10熱門(mén)話題啊，最多回復(fù)的話題啊，都可以視為簡(jiǎn)單的推薦，數(shù)據(jù)量又不大的情況下，直接select就可以了。

如果是用戶推薦的話，用戶量不大的情況下，也可以如法炮制，選擇同一區(qū)域（城市）年齡相當(dāng)?shù)漠愋裕詈箅S機(jī)挑幾個(gè)給你，相信世紀(jì)佳緣之類的交友網(wǎng)站早期實(shí)現(xiàn)也就是類似的模式。

那么，如果用戶量多了呢？每次都去搜數(shù)據(jù)庫(kù)，同時(shí)在線用戶又多，那對(duì)數(shù)據(jù)庫(kù)的壓力就巨大了。這時(shí)候就是引入緩存，Memcached、Redis就出現(xiàn)了。

簡(jiǎn)單的做法就是把搜索條件作為key，把結(jié)果作為value存入緩存。打個(gè)比方你可以把key存為 20:40:beijing:male（20到40歲之間北京的男性），然后把第一次搜索的結(jié)果全部打亂shuffle后，存前1000個(gè)，10分鐘過(guò)期，再有人用類似條件搜索，就直接把緩存數(shù)據(jù)隨機(jī)挑幾個(gè)返回。放心，一般來(lái)說(shuō)不會(huì)有人10分鐘就把1000個(gè)用戶的資料都看完了，中間偶有重復(fù)也沒(méi)人在意（用世紀(jì)佳緣、百合網(wǎng)啥的時(shí)候看到過(guò)重復(fù)的吧）。

不過(guò)話又說(shuō)回來(lái)，現(xiàn)代數(shù)據(jù)庫(kù)，尤其是類似MongoDB/ES這些大量占用內(nèi)存的NoSQL，已經(jīng)對(duì)經(jīng)常查詢的數(shù)據(jù)做了緩存，在這之上再加cache，未必真的很有效，這需要case by case去分析了，總之盲目加cache也并不推薦。

加緩存是為了解決訪問(wèn)速度，減輕數(shù)據(jù)庫(kù)壓力，但是并不提高推薦精準(zhǔn)度。如果我們要提高推薦效果呢？在2015年之前機(jī)器學(xué)習(xí)還沒(méi)那么普及成熟的時(shí)候，我們?cè)趺锤隳兀?/p>

提高推薦效果，在機(jī)器學(xué)習(xí)之前有兩種做法：

引入基于Lucene的搜索引擎，在搜索的同時(shí)通過(guò)定制方案實(shí)現(xiàn)scoring，比如我可以利用Lucene對(duì)用戶的年齡、性別、地址等進(jìn)行indexing，但是再返回結(jié)果時(shí)我再根據(jù)用戶和查詢者兩人的具體信息進(jìn)行關(guān)聯(lián)，自定義返回的score（可以視為推薦相關(guān)系數(shù)）

采用離線批處理。固然可以用Hadoop，但是就太殺雞用牛刀了。常見(jiàn)的是定時(shí)批處理任務(wù)，按某種規(guī)則劃分用戶群體，對(duì)每個(gè)群體再做全量計(jì)算后把推薦結(jié)果寫(xiě)入緩存。這種可以做很繁復(fù)準(zhǔn)確的計(jì)算，雖然慢，但效果往往不錯(cuò)。這種做法也常用在手機(jī)游戲的PvP對(duì)戰(zhàn)列表里面。

這些處理方法對(duì)社交網(wǎng)絡(luò)/手游這類型的其實(shí)已經(jīng)足夠了，但是新的業(yè)務(wù)是不斷出現(xiàn)的。隨著Uber/滴滴/餓了么/美團(tuán)這些需要實(shí)時(shí)處理數(shù)據(jù)的App崛起，作為一個(gè)司機(jī)，并不想你上線后過(guò)幾分鐘才有客人來(lái)吧，你希望你開(kāi)到一個(gè)熱點(diǎn)區(qū)域，一開(kāi)機(jī)就馬上接單。

所以這種對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)（近實(shí)時(shí)）處理的需求也帶動(dòng)了后端體系的大發(fā)展，Kafka/Spark等等流處理大行其道。這時(shí)候的后端體系就漸漸引入了消息驅(qū)動(dòng)的模式，所謂消息驅(qū)動(dòng)，就是對(duì)新的生產(chǎn)數(shù)據(jù)會(huì)有多個(gè)消費(fèi)者，有的是滿足實(shí)時(shí)計(jì)算的需求（比如司機(jī)信息需要立刻能夠被快速檢索到，又不能每次都做全量indexing，就需要用到Spark），有的只是為了數(shù)據(jù)分析，寫(xiě)入類似Cassandra這些數(shù)據(jù)庫(kù)里，還有的可能是為了生成定時(shí)報(bào)表，寫(xiě)入到MySQL。

大數(shù)據(jù)的處理一直是業(yè)界熱點(diǎn)領(lǐng)域。記得2015年硅谷一個(gè)朋友就是從一家小公司做PHP跳去另一家物聯(lián)網(wǎng)公司做Spark相關(guān)的工作，之前還很擔(dān)心玩不轉(zhuǎn)，搞了兩年就儼然業(yè)界大佬被Oracle挖去負(fù)責(zé)云平臺(tái)。

Anyway，這時(shí)候?qū)蠖梭w系的要求是一方面能快速滿足實(shí)時(shí)需求，另一方面又能滿足各種耗時(shí)長(zhǎng)的數(shù)據(jù)分析、Data lake存儲(chǔ)等等，以及當(dāng)時(shí)漸漸普及的機(jī)器學(xué)習(xí)模型（當(dāng)時(shí)2015年初和幾個(gè)朋友搞Startup，其中一個(gè)是Walmart Lab的機(jī)器學(xué)習(xí)專家，上來(lái)就一堆模型，啥數(shù)據(jù)和用戶都還沒(méi)有就把模型擺上來(lái)了，后來(lái)搞得非常頭痛。當(dāng)時(shí)沒(méi)有Keras/PyTorch/tf這些，那堆模型是真心搞不太懂，但是又不敢扔，要靠那東西去包裝拿投資的。）

但是我們?cè)倏瓷厦娴膱D，是不是感覺(jué)比較亂呢？各種系統(tǒng)的數(shù)據(jù)寫(xiě)來(lái)寫(xiě)去，是不是有點(diǎn)messy？當(dāng)公司團(tuán)隊(duì)增多，系統(tǒng)復(fù)雜度越來(lái)越高的時(shí)候，我們?cè)撛趺词崂恚?/p>

到了2017之后，前面千奇百怪的后端體系基本上都趨同了。Kafka的實(shí)時(shí)消息隊(duì)列，Spark的流處理（當(dāng)然現(xiàn)在也可以換成Flink，不過(guò)大部分應(yīng)該還是Spark），然后后端的存儲(chǔ)，基于Hive的數(shù)據(jù)分析查詢，然后根據(jù)業(yè)務(wù)的模型訓(xùn)練平臺(tái)。各個(gè)公司反正都差不多這一套，在具體細(xì)節(jié)上根據(jù)業(yè)務(wù)有所差異，或者有些實(shí)力強(qiáng)大的公司會(huì)把中間一些環(huán)節(jié)替換成自己的實(shí)現(xiàn)，不過(guò)不管怎么千變?nèi)f化，整體思路基本都一致了。

這里可以看到機(jī)器學(xué)習(xí)和AI模型的引入。個(gè)人認(rèn)為，Machine Learning的很大一個(gè)好處，是簡(jiǎn)化業(yè)務(wù)邏輯，簡(jiǎn)化后臺(tái)流程，不然一套業(yè)務(wù)一套實(shí)現(xiàn)，各種數(shù)據(jù)和業(yè)務(wù)規(guī)則很難用一個(gè)整體的技術(shù)平臺(tái)來(lái)完成。相比前面一頁(yè)的后臺(tái)架構(gòu)，這一頁(yè)要清晰許多，而且是一個(gè)DAG有向無(wú)環(huán)圖的形式，數(shù)據(jù)流向很明確。我們?cè)谙旅嬖賮?lái)說(shuō)這個(gè)機(jī)器學(xué)習(xí)對(duì)業(yè)務(wù)數(shù)據(jù)流程的簡(jiǎn)化。

在傳統(tǒng)后端系統(tǒng)中，業(yè)務(wù)邏輯其實(shí)和數(shù)據(jù)是客觀分離的，邏輯規(guī)則和數(shù)據(jù)之間并不存在客觀聯(lián)系，而是人為主觀加入，并沒(méi)形成閉環(huán)，如上圖左上所示。而基于機(jī)器學(xué)習(xí)的平臺(tái)，這個(gè)閉環(huán)就形成了，從業(yè)務(wù)數(shù)據(jù)->AI模型->業(yè)務(wù)邏輯->影響用戶行為->新的業(yè)務(wù)數(shù)據(jù)這個(gè)流程是自給自足的。這在很多推薦系統(tǒng)中表現(xiàn)得很明顯，通過(guò)用戶行為數(shù)據(jù)訓(xùn)練模型，模型對(duì)頁(yè)面信息流進(jìn)行調(diào)整，從而影響用戶行為，然后用新的用戶行為數(shù)據(jù)再次調(diào)整模型。而在機(jī)器學(xué)習(xí)之前，這些觀察工作是交給運(yùn)營(yíng)人員去手工猜測(cè)調(diào)整。

上圖右邊談的是機(jī)器學(xué)習(xí)相關(guān)后臺(tái)架構(gòu)和傳統(tǒng)Web后臺(tái)的一些差別，重點(diǎn)是耗時(shí)太長(zhǎng)，必須異步處理。因此消息驅(qū)動(dòng)機(jī)制對(duì)機(jī)器學(xué)習(xí)后臺(tái)是一個(gè)必須的設(shè)計(jì)。

這頁(yè)是一些個(gè)人的感受，現(xiàn)代的后端數(shù)據(jù)處理越來(lái)越偏向于DAG的形態(tài)，Spark不說(shuō)了，DAG是最大特色；神經(jīng)網(wǎng)絡(luò)本身也可以看作是一個(gè)DAG（RNN其實(shí)也可以看作無(wú)數(shù)個(gè)單向DNN的組合）；TensorFlow也是強(qiáng)調(diào)其Graph是DAG，另外編程模式上，Reactive編程也很受追捧。

其實(shí)DAG的形態(tài)重點(diǎn)強(qiáng)調(diào)的就是數(shù)據(jù)本身是immutable（不可修改），只能transform后成為新的數(shù)據(jù)進(jìn)入下一環(huán)。這個(gè)思維其實(shí)可以貫穿到現(xiàn)代后臺(tái)系統(tǒng)設(shè)計(jì)的每個(gè)環(huán)節(jié)，比如Trakcing、Analytics、數(shù)據(jù)表設(shè)計(jì)、Microservice等等，但具體實(shí)施還是要case by case了。

無(wú)論如何，數(shù)據(jù)，數(shù)據(jù)的跟蹤Tracking，數(shù)據(jù)的流向，是現(xiàn)代后臺(tái)系統(tǒng)的核心問(wèn)題，只有Dataflow和Data Pipeline清晰了，整個(gè)后臺(tái)架構(gòu)才會(huì)清楚。

數(shù)據(jù)庫(kù)是個(gè)非常復(fù)雜的領(lǐng)域，在下面對(duì)幾個(gè)基本常用的概念做一些介紹。注意一點(diǎn)是Graph database在這里沒(méi)有提到，因?yàn)槿粘Ｊ褂幂^少，相對(duì)來(lái)說(shuō)Facebook提出的GraphQL倒是個(gè)有趣的概念，但也只是在傳統(tǒng)DB上的一個(gè)概念封裝。

上圖是2018年12月初熱門(mén)數(shù)據(jù)庫(kù)的排名，我們可以看到關(guān)系數(shù)據(jù)庫(kù)RDBMS和NOSQL數(shù)據(jù)庫(kù)基本上平分秋色。而NoSQL中實(shí)際上又可以分為key-value storage（包括文檔型）及Column based DB。

MySQL這個(gè)沒(méi)啥好講，大概提一下就是。有趣的是曾經(jīng)看到一篇文章是AWS CTO談的一些內(nèi)容，其中印象深刻是：如果你的用戶還不到100萬(wàn)，就別折騰了，無(wú)腦使用MySQL吧。

在2015年之前的一個(gè)趨勢(shì)是不少公司使用MySQL作為數(shù)據(jù)存儲(chǔ)，但是把indexing放在外部去做。這個(gè)思路最早似乎是Friendster提出的，后來(lái)Uber也模仿這種做法設(shè)計(jì)了自己的數(shù)據(jù)庫(kù)Schemaless。然而隨著PostgreSQL的普及（PostgreSQL支持對(duì)json的索引），這種做法是否還有意義就值得商榷了。

NoSQL最早的使用就是key-value的查找，典型的就是Redis。實(shí)際上后來(lái)的像MongoDB這些Documentbased DB也是類似的key value，只是它對(duì)Document中的內(nèi)容又做了一次index（b-tree），用空間換時(shí)間來(lái)提供查找數(shù)據(jù)，這也是CS不變的思維。

MongoDB/Elasticsearch收到熱捧主要是因?yàn)樗鼈兊腟chemaless屬性，也就是不需要提前定義數(shù)據(jù)格式，只要是json就存，還都能根據(jù)每個(gè)field搜索，這非常方便程序員快速出demo。但是實(shí)際上數(shù)據(jù)量大之后還是要規(guī)范數(shù)據(jù)結(jié)構(gòu)，定義需要indexing的field的。

這里提一個(gè)比較好玩的開(kāi)源Project NodeBB，這是個(gè)Node.js開(kāi)發(fā)的論壇系統(tǒng)。在我前幾年看到這個(gè)的時(shí)候它其實(shí)只支持Redis，然后當(dāng)時(shí)因?yàn)橐粋€(gè)項(xiàng)目把它改造了讓他支持MySQL。去年再看的時(shí)候發(fā)現(xiàn)它同時(shí)支持了Redis/Postres/MongoDB，如果對(duì)比一下同樣的功能他如何在這三種DB實(shí)現(xiàn)的，相信會(huì)很有幫助。

稍微談?wù)劻写鎯?chǔ)。常見(jiàn)MySQL你在select的時(shí)候其實(shí)往往會(huì)把整行都讀出來(lái)，再在其中挑那么一兩個(gè)你需要的屬性，非常浪費(fèi)。而MongoDB這些文件型DB，又不支持常見(jiàn)SQL。而列存儲(chǔ)DB的好處就是快，不用把一行所有信息讀出來(lái)，只是按列讀取你需要的，對(duì)現(xiàn)在的大數(shù)據(jù)分析特別是OLAP（Online Analytical Processing）來(lái)說(shuō)特別重要。然而據(jù)另外的說(shuō)法，實(shí)際上像Casssandra/HBase這些并不是真正的列存儲(chǔ)，而只是借用了一些概念。這個(gè)我也沒(méi)深入去了解，有興趣的同學(xué)可以自己研究研究。

列存儲(chǔ)的一個(gè)重要領(lǐng)域是時(shí)序數(shù)據(jù)庫(kù)，物聯(lián)網(wǎng)用得多。其特色是大量寫(xiě)入，只增不改（不修改數(shù)據(jù)），但是讀的次數(shù)相對(duì)于很少（想想物聯(lián)網(wǎng)的特點(diǎn)，隨時(shí)有數(shù)據(jù)寫(xiě)入，但是你不會(huì)隨時(shí)都在看你家小米電器的狀態(tài)。）

注意說(shuō)Write/Read是正交的。這意思是每次寫(xiě)入是一次一行，而讀是按列，加上又不會(huì)修改數(shù)據(jù)，因此各自都能保持極快的速度。

下面簡(jiǎn)單談一下微服務(wù)，大部分直接看PPT就可以了，有幾頁(yè)略微談一下個(gè)人思考。

上面這頁(yè)說(shuō)說(shuō)，其實(shí)微服務(wù)所謂的服務(wù)發(fā)現(xiàn)/name service不要被忽悠覺(jué)得是多神奇的東西。最簡(jiǎn)單的Nginx/Apache這些都能做（域名轉(zhuǎn)向，Proxy），或者你要寫(xiě)個(gè)name : address的對(duì)應(yīng)關(guān)系到DB里面也完全可以，再配一個(gè)定時(shí)HealthCheck的服務(wù)，最簡(jiǎn)單的服務(wù)發(fā)現(xiàn)也就行了。

高級(jí)點(diǎn)用到ZooKeeper/etcd等等，或者Spring Cloud全家桶，那只是簡(jiǎn)化配置，原理都一樣。從開(kāi)發(fā)角度來(lái)看，微服務(wù)的開(kāi)發(fā)并不是難點(diǎn)，難點(diǎn)是微服務(wù)的配置和部署。最近一段時(shí)間微服務(wù)部署也是業(yè)界熱點(diǎn)，除了全家桶形態(tài)的Spring Cloud，也可以看看Istio這些開(kāi)源工具。

上圖主要大致對(duì)比一下，看看從早期的Spring到現(xiàn)在Spring Cloud的變化。想來(lái)用過(guò)Java Tomcat的朋友都能體會(huì)Java這一套Config based development的繁瑣，開(kāi)發(fā)的精力很多不是在業(yè)務(wù)代碼上，往往會(huì)化不少精力去折騰配置文件。當(dāng)然，Spring Cloud在這方面簡(jiǎn)化了不少，不過(guò)個(gè)人還是不太喜歡Java，搞很多復(fù)雜的設(shè)計(jì)模式，封裝了又封裝。

這里要說(shuō)并不是微服務(wù)解決一切，熱門(mén)的Python Django盡管有REST Framework，但是它實(shí)際上是一個(gè)典型的Monolithic體系。對(duì)很多核心業(yè)務(wù)，其實(shí)未必要拆開(kāi)成微服務(wù)。

這兩者是互補(bǔ)關(guān)系，不是替代關(guān)系。

下面的Docker我就不仔細(xì)談了，PPT基本表達(dá)了我想表述的概念，主要意思是：

Docker能夠簡(jiǎn)化部署，簡(jiǎn)化開(kāi)發(fā)，能夠在某種程度上讓開(kāi)發(fā)環(huán)境和產(chǎn)品環(huán)境盡量接近。

不要擔(dān)心Docker的性能，它不是虛擬機(jī)，可以看作在Server上運(yùn)行的一個(gè)Process。

上圖是描述Docker之前開(kāi)發(fā)人員的常見(jiàn)開(kāi)發(fā)環(huán)境，首先在自己機(jī)器上裝一大堆服務(wù)，像MySQL，Redis，Tomcat啥的。也有直接在遠(yuǎn)程服務(wù)器安裝環(huán)境后，多人共同登錄遠(yuǎn)端開(kāi)發(fā)，各自使用一個(gè)端口避免沖突……實(shí)際上這種土法煉鋼的形態(tài)，在2019年的今天仍然在國(guó)內(nèi)非常普及。

這種形態(tài)的后果就是在最后發(fā)布到生產(chǎn)環(huán)境時(shí)，不同開(kāi)發(fā)人員會(huì)經(jīng)歷長(zhǎng)時(shí)間的“聯(lián)調(diào)”，各種端口、權(quán)限、腳本、環(huán)境設(shè)置在生產(chǎn)環(huán)境再來(lái)一遍…這也是過(guò)去運(yùn)維人員的主要工作。

上一頁(yè)提到的問(wèn)題，并不是一定要Docker來(lái)解決。在這之前，虛擬機(jī)VM的出現(xiàn)，以及Vagrant這樣的工具，都讓開(kāi)發(fā)環(huán)境的搭建多少輕松了一些。不過(guò)思路仍然是把VM作為一個(gè)獨(dú)立服務(wù)器使用，只是因?yàn)榭煺铡㈢R像和輔助工具，讓環(huán)境的配置、統(tǒng)一和遷移更加簡(jiǎn)單快捷。

上圖是對(duì)比程序運(yùn)行在物理服務(wù)器、VM及Docker時(shí)的資源共享情況，可以看到運(yùn)行在Docker的應(yīng)用，并沒(méi)有比并發(fā)運(yùn)行在物理服務(wù)器上占用更多資源。

下圖是簡(jiǎn)單的Docker使用，不做贅述。

這一頁(yè)主要是強(qiáng)調(diào)Docker并不等同于虛擬機(jī)。虛擬機(jī)所占資源是獨(dú)享的，比如你啟動(dòng)一個(gè)VM，分配2G內(nèi)存，那么這個(gè)VM里不管是否運(yùn)行程序都會(huì)占用2G內(nèi)存。然而如果你啟動(dòng)一個(gè)Docker，里面運(yùn)行一個(gè)簡(jiǎn)單Web服務(wù)，在不強(qiáng)制指定內(nèi)存占用情況下，如果沒(méi)有請(qǐng)求進(jìn)入，沒(méi)有額外占用內(nèi)存，那么這個(gè)Docker服務(wù)對(duì)整機(jī)的內(nèi)存占用幾乎為0（當(dāng)然仍然存在一些開(kāi)銷，但主要是根據(jù)該程序自身的運(yùn)行狀況而定）。

最后是Kubernetes，這里大概說(shuō)說(shuō)Host-Pod-Container的關(guān)系，一個(gè)Host可以是物理機(jī)或者VM，Pod不是一個(gè)Docker，而是可以看作有一個(gè)IP的……（不知道怎么形容），總之一個(gè)Pod可以包括多個(gè)Container（Docker），Pod之中的Container可以共享該P(yáng)od的資源（IP，storage等）。不過(guò)現(xiàn)實(shí)中似乎大多是一個(gè)Pod對(duì)一個(gè)Container。

對(duì)互聯(lián)網(wǎng)一些熱門(mén)概念和演變過(guò)程的一個(gè)很簡(jiǎn)略的描述就到這里。

本文轉(zhuǎn)載自公眾號(hào)：騰訊技術(shù)工程，點(diǎn)擊查看原文。

基于Kubernetes的DevOps實(shí)踐培訓(xùn)

基于Kubernetes的DevOps實(shí)踐培訓(xùn)將于2019年5月10日在上海開(kāi)課，3天時(shí)間帶你系統(tǒng)掌握Kubernetes，學(xué)習(xí)效果不好可以繼續(xù)學(xué)習(xí)。本次培訓(xùn)包括：容器特性、鏡像、網(wǎng)絡(luò)；Kubernetes架構(gòu)、核心組件、基本功能；Kubernetes設(shè)計(jì)理念、架構(gòu)設(shè)計(jì)、基本功能、常用對(duì)象、設(shè)計(jì)原則；Kubernetes的數(shù)據(jù)庫(kù)、運(yùn)行時(shí)、網(wǎng)絡(luò)、插件已經(jīng)落地經(jīng)驗(yàn)；微服務(wù)架構(gòu)、組件、監(jiān)控方案等，點(diǎn)擊下方圖片查看詳情。