從技術(shù)演變的角度看互聯(lián)網(wǎng)后臺架構(gòu)
這是去年在部門內(nèi)部做的一個面向后臺開發(fā)新同學(xué)的課程，因為其他BG一些同學(xué)要求分享，所以發(fā)一下。
其實內(nèi)容都是些常見開源組件的high level描述，比如flask, express框架，中間件的演化，micro service的概念，一些對nosql/column based db的概念介紹，docker的一些簡單概念等等。從單個概念來說，這只是一些科普。
但是為什么當時要開這門課呢?重點是我發(fā)現(xiàn)很多新入職的后臺開發(fā)同學(xué)并不太清楚自己做的東西在現(xiàn)代互聯(lián)網(wǎng)整體架構(gòu)中處于一個什么樣的角色，而在IEG內(nèi)部則因為游戲開發(fā)和互聯(lián)網(wǎng)開發(fā)的一些歷史性差異，有些概念并不清晰。
拿中間件來說，很多web application不用啥中間件一樣可以跑很好，那么是不是都要上redis?到底解決什么問題?中間件又存在什么問題?中臺和中間件又是個什么關(guān)系?如果開個mq就是中間件，微服務(wù)又是要做啥?
如果能從這十多年來互聯(lián)網(wǎng)應(yīng)用的整個tech stack變化去看待backend architecture的一些改變，應(yīng)該是一件有趣也有意思的事情。這是當時寫這個ppt開課的初衷。
我不敢說我在這個ppt里面的一些私貨概念就是對的，但是也算是個人這么多年的一些認知理解，拋磚引玉吧。
強調(diào)一點，這個ppt的初衷是希望從近十多年來不同時代不同熱點下技術(shù)棧的變化來看看我們是如何從最早的php/asp/jsp<=>mysql這樣的兩層架構(gòu)，一個階段一個階段演變到現(xiàn)在繁復(fù)的大數(shù)據(jù)、機器學(xué)習(xí)、消息驅(qū)動、微服務(wù)架構(gòu)這樣的體系，然后在針對其中比較重要的幾個方面來給新入門后臺開發(fā)的同學(xué)起個“提綱目錄”的作用。如果要對每個方面都深入去談，那肯定不是一兩頁PPT就能做到的事情。
下面我們開始。首先看***頁如下圖：什么是System Design?什么是架構(gòu)設(shè)計?為什么要談架構(gòu)設(shè)計?
之所以拋出這個問題，是因為平時常常聽到兩個互相矛盾的說法：一方面很多人愛說“架構(gòu)師都是不干活夸夸其談”，另一方面又有很多人苦惱限于日常業(yè)務(wù)需求開發(fā)，無法或者沒有機會去從整體架構(gòu)思考，不知道怎么成長為架構(gòu)師。
上面ppt中很有趣的是***句英文，翻譯過來恰好可以反映了論壇上經(jīng)常有人問的“如何學(xué)習(xí)架構(gòu)”的問題：很多l(xiāng)eader一來就是扔幾本書(書名)給新同學(xué)，期望他們讀完書就馬上升級。。。這種一般都只會帶來失望。
何為架構(gòu)師?不寫代碼只畫PPT?
不是的，架構(gòu)師的基本職責是要在項目早期就能設(shè)計好基本的框架，這個框架能夠確保團隊成員順利coding滿足近期內(nèi)業(yè)務(wù)需求的變化，又能為進一步的發(fā)展留出空間(所謂scalability)，這即是所謂技術(shù)選型。如何確保選型正確?對于簡單的應(yīng)用，或者沒有新意完全是實踐過多次的相同方案，確實靠幾頁PPT足矣。但是對于新的領(lǐng)域新的復(fù)雜需求，這個需求未必都是業(yè)務(wù)需求，也包括根據(jù)團隊自身特點(人員太多、太少、某些環(huán)節(jié)成員不熟悉需要剝離開)來進行新的設(shè)計，對現(xiàn)有技術(shù)重新分解組合，這時候就需要架構(gòu)師自己編碼實現(xiàn)原型并驗證思路正確性。
要達到這樣的目標難不難?難!但是現(xiàn)在不是2000年了，是2019年了，大量的框架(framework)、開源工具和各種best practice，其實都是在幫我們解決這件事情。而這些框架并不是憑空而來，而是在這十多年互聯(lián)網(wǎng)的演化中因為要解決各種具體業(yè)務(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ù)棧中選擇合適的來組裝自己的方案，則需要對技術(shù)的來源和歷史有一定的了解。否則就會出現(xiàn)一些新人張口ELK，閉口tensorflow，然后一個簡單的異步消息處理就會讓他們張口結(jié)舌的現(xiàn)象。
20多年前的經(jīng)典著作DesignPatterns中講過學(xué)習(xí)設(shè)計模式的意義，放在這里非常經(jīng)典：學(xué)習(xí)設(shè)計模式并不是要你學(xué)習(xí)一種新的技術(shù)或者編程語言，而是建立一種交流的共同語言和詞匯，在方案設(shè)計時方便溝通，同時也幫助人們從更抽象的層次去分析問題本質(zhì)，而不被一些實現(xiàn)的細枝末節(jié)所困擾。同時，當我們能把很多問題抽象出來之后，也能幫我們更深入更好地去了解現(xiàn)有系統(tǒng)-------這些意義，對于今天的后端系統(tǒng)設(shè)計來說，也仍然是正確的。
下圖是我們要談的幾個主要方面。
上面的幾個主題中，***個后臺架構(gòu)的演化是自己從業(yè)十多年來，體會到的互聯(lián)網(wǎng)技術(shù)架構(gòu)的整體變遷。然后分成后臺前端應(yīng)用框架、middleware和存儲三大塊談一下，***兩節(jié)微服務(wù)和docker則是給剛進入后臺開發(fā)的同學(xué)做一些概念普及。其中個人覺得最有趣的，是***部分后臺架構(gòu)的演化和第三部分的中間件，因為這兩者是很好地反映了過去十多年互聯(lián)網(wǎng)發(fā)展期間技術(shù)棧的變化，從LAMP到MEAN Stack，從各種繁復(fù)的中間層到漸漸統(tǒng)一的消息驅(qū)動+流處理，每個階段的業(yè)界熱點都相當有代表性。
當然，不是說web框架、數(shù)據(jù)存儲就不是熱點了，姑且不說這幾年web前端的復(fù)雜化，光后端應(yīng)用框架，node的express，python的django/flask，go在國內(nèi)的盛行，都是相當有趣的。在數(shù)據(jù)存儲領(lǐng)域，列存儲和時序數(shù)據(jù)隨著物聯(lián)網(wǎng)的發(fā)展也是備受重視。但是篇幅所限，在這個課程中這些話題也就只能一帶而過，因為這些與其說是技術(shù)的演變過程，不如說是不同的技術(shù)選型和方向了，比如說Mysql適合OLTP(Online Transaction Processing)，而Cassandra/Hbase等則適合OLAP(Online Analyical Processing)，并不能說后者就優(yōu)于前者。
下面我們先來看后臺架構(gòu)的演化：
嚴格說這是個很大的標題，從2000年到現(xiàn)在的故事太多了，我這里只能盡力而為從個人體驗來分析。
首先是2008年以前，我把它稱為網(wǎng)站時代。為什么這么說?因為那時候的后臺開發(fā)就是寫網(wǎng)站，而且通常是頁面代碼和后臺數(shù)據(jù)邏輯一起寫。你只要能寫JSP/PHP/ASP來讀寫Mysql或者SQL Server，基本就能保證一份不錯的工作了。
要強調(diào)一下，這種簡單的兩層結(jié)構(gòu)并不能說就是落后。在現(xiàn)在各個企業(yè)、公司以及小團隊的大量web應(yīng)用包括移動App的后端服務(wù)中，采用這種架構(gòu)的不在少數(shù)，尤其是很多公司、學(xué)校、企業(yè)的內(nèi)部服務(wù)，用這種架構(gòu)已經(jīng)足夠了。
注意一個時間節(jié)點：2008。
當然，這個節(jié)點是我YY的。這個節(jié)點可以是2007，或者2006。這個時間段發(fā)生了兩個影響到現(xiàn)在的事情：google上市，facebook開始推開
我個人相信前者上市加上它發(fā)表的那三篇大數(shù)據(jù)paper影響了后來業(yè)界的技術(shù)方向，后者的火熱則造成了社交成為業(yè)務(wù)熱點。偏偏社交網(wǎng)站對大數(shù)據(jù)處理有著天然的需求，技術(shù)的積累和業(yè)務(wù)的需求就這么陰差陽錯***結(jié)合了起來，直接影響了大海那邊后面的科技發(fā)展。
同時在中國，那個時候卻是網(wǎng)絡(luò)游戲MMO的黃金年代，對單機單服高并發(fā)實時交互的需求，遠遠壓過了對海量數(shù)據(jù)data mining的需要，在這個時間點，中美兩邊的互聯(lián)網(wǎng)科技樹發(fā)生了比較大的分叉。這倒是并沒有優(yōu)劣之說，只是業(yè)務(wù)場景的重要性導(dǎo)致了技能樹的側(cè)重。直到今天，單機(包括簡單的多服務(wù)器方案)高并發(fā)、高QPS仍然也是國內(nèi)業(yè)界所追求的目標，而在美國那邊，這只是一個業(yè)務(wù)指標而已，更看重的是如何進行水平擴展(horizontal scaling)和分散壓力。
國內(nèi)和美國的科技樹回到一條線上，大數(shù)據(jù)的業(yè)務(wù)需求和相關(guān)技術(shù)發(fā)展緊密結(jié)合起來，可能要到2014年左右，隨著互聯(lián)網(wǎng)創(chuàng)業(yè)的盛行，O2O業(yè)務(wù)對大數(shù)據(jù)實時處理、機器學(xué)習(xí)推薦提出了真正的需求時，才是國內(nèi)業(yè)界***出現(xiàn)技術(shù)驅(qū)動業(yè)務(wù)，算法驅(qū)動產(chǎn)品的現(xiàn)象，重新和美國灣區(qū)那邊站在了一條線上，而這則是后話了。
到了2010年前后，facebook在全球已經(jīng)是現(xiàn)象級產(chǎn)品，當時微軟直接放棄了windows live，就是為了避免在社交領(lǐng)域硬懟facebook。八卦一下當時在美國灣區(qū)那邊聚餐的時候，如果誰說他是facebook的，那基本就是全場羨慕的焦點。
facebook的崛起也帶動了其他大量的社交網(wǎng)站開始出現(xiàn)，社交網(wǎng)站***的特點就是頻繁的用戶搜索、推薦，當用戶上億的時候，這就是前面?zhèn)鹘y(tǒng)的兩層架構(gòu)無法處理的問題了。因此這就帶動了中間件的發(fā)展。實際上在國外很少有人用中間件或者middelware這個詞，更多是探討如何把各種service集成在一起，像國內(nèi)這樣強行分成frontend/middleware/storage的概念是沒聽人這么談過的，后面中間件再說這問題。當時的一個慣例是用php做所謂的膠水語言(glue language)，然后通過hessian這些協(xié)議工具來把其他java服務(wù)連接到一起。與此同時，為了提高訪問速度，降低后端查詢壓力，memcached/redis也開始大量使用?；趌ucene的搜索(2010左右很多是自行開發(fā))或者solr也被用在用戶搜索、推薦以及type ahead這些場景中。
我記憶中在2012年之前消息隊列的使用還不是太頻繁，不像后來這么重要。當時常見的應(yīng)該就是beanstalkd/rabbitmq, zeromq其實我在灣區(qū)那邊很少聽人用，倒是后來回國后看到國內(nèi)用的人還不少。Kafka在2011年已經(jīng)出現(xiàn)了，有少部分公司開始用，不過還不是主流。
2013年之后就是大數(shù)據(jù)+云的時代了，如果大家回想一下，基本上國內(nèi)也是差不多在2014年左右開始叫出了云+大數(shù)據(jù)的口號(2013年國內(nèi)還在手游狂潮中...)。不談國外，在中國那段時間就是互聯(lián)網(wǎng)創(chuàng)業(yè)的時代，從千團大戰(zhàn)到手游爆發(fā)到15年開始的O2O，業(yè)務(wù)的發(fā)展也帶動了技術(shù)棧的飛速進步。左上角大致上也寫了這個時代互聯(lián)網(wǎng)業(yè)界的主要技術(shù)熱點，實際上這也就是現(xiàn)在的熱點。無論國內(nèi)國外，絕大部分公司還并沒有離開云+大數(shù)據(jù)這個時代。無論是大數(shù)據(jù)的實時處理、數(shù)據(jù)挖掘、推薦系統(tǒng)、Docker化，包括A/B測試，這些都是很多企業(yè)還正在努力全面解決的問題。
但是在少數(shù)站在業(yè)界技術(shù)頂端或者沒有歷史技術(shù)包袱的新興公司，從某個角度上來說，他們已經(jīng)開始在往下一個時代前進：機器學(xué)習(xí)AI驅(qū)動的時代
2018年開始，實際上可能是2017年中開始，AI驅(qū)動成了各大公司口號。上圖是facebook和uber的機器學(xué)習(xí)平臺使用情況，基本上已經(jīng)全部進入業(yè)務(wù)核心。當然并不是說所有公司企業(yè)都要AI驅(qū)動，顯然最近發(fā)生的波音737事件就說明該用傳統(tǒng)的就該傳統(tǒng)，別啥都往并不成熟的AI上堆。但另一方面，很多新興公司的業(yè)務(wù)本身就是基于大數(shù)據(jù)或者算法的，因此他們在這個領(lǐng)域也往往走得比較激進。由于這個AI驅(qū)動還并沒有一個很明確的定義和概念，還處于一種早期萌芽的階段，在這里也就不多YY了。
互聯(lián)網(wǎng)后臺架構(gòu)發(fā)展的簡單過程就在這里講得差不多了，然后我們快速談一下web開發(fā)框架。
首先在前面我提到，在后端架構(gòu)中其實也有所謂的frontend(前臺)開發(fā)存在，一般來說這是指響應(yīng)用戶請求，實現(xiàn)具體業(yè)務(wù)邏輯的業(yè)務(wù)邏輯層。當然這么定義略微粗糙了些，很多中間存儲、消息服務(wù)也會封裝一些業(yè)務(wù)相關(guān)邏輯?？傊畐eb開發(fā)框架往往就是為了更方便地實現(xiàn)這些業(yè)務(wù)邏輯而存在的。
前文提到在一段較長時間內(nèi)，國內(nèi)的技術(shù)熱點是單機高并發(fā)高QPS，因此很多那個時代走過來的人會本能地質(zhì)疑web框架的性能，而更偏好TCP長鏈接甚至UDP協(xié)議。然而這往往是自尋煩惱，因為除開特別的強實時系統(tǒng)，無論是休閑手游、視頻點播還是信息流，都已經(jīng)是基于HTTP的了。
上圖所提到的兩個問題中，我想強調(diào)的是***點：所有的業(yè)務(wù)，在能滿足需求的情況下，***HTTP協(xié)議進行數(shù)據(jù)交互。準確點說，***JSON，使用web API。
Why? 這就是上圖***個問題所回答的：無狀態(tài)、易調(diào)試易修改、一般沒有80端口限制。
最為詬病的無非是性能，然而實際上對非實時應(yīng)用，晚個半秒一秒不應(yīng)該是大問題，要考慮的是水平擴展scalability，不是實時響應(yīng)(因為前提就是非實時應(yīng)用);其次實在不行你還有websocket可以用。
這一部分是簡單列舉了一下不同框架的使用，可以看出不同框架的概念其實差不多。重點是要注意到middleware這個說法在web framework和后端架構(gòu)中的意義不同。在web framework中是指具體處理GET/POST這些請求之前的一個通用處理(往往是鏈式調(diào)用)，比如可以把鑒權(quán)、一些日志處理和請求記錄放在這里。但在后端架構(gòu)設(shè)計中的middleware則是指類似消息隊列、緩存這些在最終數(shù)據(jù)庫之前的中間服務(wù)組件。
***這里是想說web framework并不是包治百病，實際上那只是提供了基礎(chǔ)功能的一個library，作為開發(fā)者則更多需要考慮如何定義配置文件，一些敏感參數(shù)如token、密碼怎么傳進來，開發(fā)環(huán)境和生產(chǎn)環(huán)境的配置如何自動切換，單元測試怎么搞，代碼目錄怎么組織。有時候我們可以用一些比如Yeoman之類的scaffold工具來自動生成項目代碼框架，或者類似django這種也可能自動生成基本目錄結(jié)構(gòu)。
下面進入Middleware環(huán)節(jié)。again，強調(diào)一下這里只是根據(jù)個人經(jīng)驗和感受談?wù)勓莼^程。
這一頁只是大致講一下怎么定義中間件middleware。說句題外話，在美國灣區(qū)那邊提這個概念的很少，而阿里又特別喜歡說中間件，兩者相互的交流非常頭痛。灣區(qū)那邊不少google、facebook還有pinterest/uber這些的朋友好幾次都在群里問說啥叫中間件。
中間件這個概念很含糊，應(yīng)該是阿里提出來的，對應(yīng)于middleware(不過似乎也不是完全對應(yīng))，可能是因為早期java的EJB那些概念里面比較強調(diào)middleware這一點吧(個人猜的)。大致上，如果我們把web后端分為直接處理用戶請求的frontend，***對數(shù)據(jù)進行持久存儲(persistant storage)這兩塊，那么中間對數(shù)據(jù)的所有處理環(huán)節(jié)都可以視為middleware。
和中間件對應(yīng)的另一個阿里發(fā)明的概念是中臺。近一年多阿里的中臺概念都相當引人注意，這里對中臺不做太多描述?？傮w來說中臺更多是偏向業(yè)務(wù)和組織架構(gòu)劃分，不能說是一個技術(shù)概念，也不是面向開發(fā)人員的。而中間件middleware是標準的技術(shù)組件服務(wù)。
那么我們自然會有一個問題：為什么要用中間件?
談到為什么要用middlware，這里用推薦系統(tǒng)舉例。
推薦系統(tǒng)，對數(shù)據(jù)少用戶少的情況下，簡單的mysql即可，比如早期論壇的什么top 10熱門話題啊，最多回復(fù)的話題啊，都可以視為簡單的推薦，數(shù)據(jù)量又不大的情況下，直接select就可以了。
如果是用戶推薦的話，用戶量不大的情況下，也可以如法炮制，選擇同一區(qū)域(城市)年齡相當?shù)漠愋裕?**隨機挑幾個給你，相信世紀佳緣之類的交友網(wǎng)站早期實現(xiàn)也就是類似的模式。
那么，如果用戶量多了呢?每次都去搜數(shù)據(jù)庫，同時在線用戶又多，那對數(shù)據(jù)庫的壓力就巨大了。這時候就是引入緩存，memcached、redis就出現(xiàn)了。
簡單的做法就是把搜索條件作為key，把結(jié)果作為value存入緩存。打個比方你可以把key存為 20:40:beijing:male (20到40歲之間北京的男性)，然后把***次搜索的結(jié)果全部打亂shuffle后，存前1000個，10分鐘過期，再有人用類似條件搜索，就直接把緩存數(shù)據(jù)隨機挑幾個返回。放心，一般來說不會有人10分鐘就把1000個用戶的資料都看完了，中間偶有重復(fù)也沒人在意(用世紀佳緣、百合網(wǎng)啥的時候看到過重復(fù)的吧)。
不過話又說回來，現(xiàn)代數(shù)據(jù)庫，尤其是類似mongodb/es這些大量占用內(nèi)存的nosql，已經(jīng)對經(jīng)常查詢的數(shù)據(jù)做了緩存，在這之上再加cache，未必真的很有效，這需要case by case去分析了，總之盲目加cache也并不推薦。
加緩存是為了解決訪問速度，減輕數(shù)據(jù)庫壓力，但是并不提高推薦精準度。如果我們要提高推薦效果呢?在2015年之前機器學(xué)習(xí)還沒那么普及成熟的時候，我們怎么搞呢?
提高推薦效果，在機器學(xué)習(xí)之前有兩種做法：
- 引入基于lucene的搜索引擎，在搜索的同時通過定制方案實現(xiàn)scoring，比如我可以利用lucene對用戶的年齡、性別、地址等進行indexing，但是再返回結(jié)果時我再根據(jù)用戶和查詢者兩人的具體信息進行關(guān)聯(lián)，自定義返回的score(可以視為推薦相關(guān)系數(shù))
- 采用離線批處理。固然可以用hadoop，但是就太殺雞用牛刀了。常見的是定時批處理任務(wù)，按某種規(guī)則劃分用戶群體，對每個群體再做全量計算后把推薦結(jié)果寫入緩存。這種可以做很繁復(fù)準確的計算，雖然慢，但效果往往不錯。這種做法也常用在手機游戲的PvP對戰(zhàn)列表里面。
這些處理方法對社交網(wǎng)絡(luò)/手游這類型的其實已經(jīng)足夠了，但是新的業(yè)務(wù)是不斷出現(xiàn)的。隨著uber/滴滴/餓了么/美團這些需要實時處理數(shù)據(jù)的app崛起，作為一個司機，并不想你上線后過幾分鐘才有客人來吧，你希望你開到一個熱點區(qū)域，一開機就馬上接單。
所以這種對數(shù)據(jù)進行實時(近實時)處理的需求也帶動了后端體系的大發(fā)展，kafka/spark等等流處理大行其道。這時候的后端體系就漸漸引入了消息驅(qū)動的模式，所謂消息驅(qū)動，就是對新的生產(chǎn)數(shù)據(jù)會有多個消費者，有的是滿足實時計算的需求(比如司機信息需要立刻能夠被快速檢索到，又不能每次都做全量indexing，就需要用到spark)，有的只是為了數(shù)據(jù)分析，寫入類似cassandra這些數(shù)據(jù)庫里，還有的可能是為了生成定時報表，寫入到mysql。
大數(shù)據(jù)的處理一直是業(yè)界熱點領(lǐng)域。記得2015年硅谷一個朋友就是從一家小公司做php跳去另一家物聯(lián)網(wǎng)公司做spark相關(guān)的工作，之前還很擔心玩不轉(zhuǎn)，搞了兩年就儼然業(yè)界大佬被oracle挖去負責云平臺～～～
anyway，這時候?qū)蠖梭w系的要求是一方面能快速滿足實時需求，另一方面又能滿足各種耗時長的數(shù)據(jù)分析、data lake存儲等等，以及當時漸漸普及的機器學(xué)習(xí)模型(當時2015年初和幾個朋友搞startup，其中一個是walmart lab的機器學(xué)習(xí)專家，上來就一堆模型，啥數(shù)據(jù)和用戶都還沒有就把模型擺上來了，后來搞得非常頭痛。當時沒有keras/pytorch/tf這些，那堆模型是真心搞不太懂，但是又不敢扔，要靠那東西去包裝拿投資的。。。)
但是我們再看上面的圖，是不是感覺比較亂呢?各種系統(tǒng)的數(shù)據(jù)寫來寫去，是不是有點messy?當公司團隊增多，系統(tǒng)復(fù)雜度越來越高的時候，我們該怎么梳理?
到了2017之后，前面千奇百怪的后端體系基本上都趨同了。kafka的實時消息隊列，spark的流處理(當然現(xiàn)在也可以換成flink，不過大部分應(yīng)該還是spark)，然后后端的存儲，基于hive的數(shù)據(jù)分析查詢，然后根據(jù)業(yè)務(wù)的模型訓(xùn)練平臺。各個公司反正都差不多這一套，在具體細節(jié)上根據(jù)業(yè)務(wù)有所差異，或者有些實力強大的公司會把中間一些環(huán)節(jié)替換成自己的實現(xiàn)，不過不管怎么千變?nèi)f化，整體思路基本都一致了。
這里可以看到機器學(xué)習(xí)和AI模型的引入。個人認為，machine learning的很大一個好處，是簡化業(yè)務(wù)邏輯，簡化后臺流程，不然一套業(yè)務(wù)一套實現(xiàn)，各種數(shù)據(jù)和業(yè)務(wù)規(guī)則很難用一個整體的技術(shù)平臺來完成。相比前面一頁的后臺架構(gòu)，這一頁要清晰許多，而且是一個DAG有向無環(huán)圖的形式，數(shù)據(jù)流向很明確。我們在下面再來說這個機器學(xué)習(xí)對業(yè)務(wù)數(shù)據(jù)流程的簡化。
在傳統(tǒng)后端系統(tǒng)中，業(yè)務(wù)邏輯其實和數(shù)據(jù)是客觀分離的，邏輯規(guī)則和數(shù)據(jù)之間并不存在客觀聯(lián)系，而是人為主觀加入，并沒形成閉環(huán)，如上圖左上所示。而基于機器學(xué)習(xí)的平臺，這個閉環(huán)就形成了，從業(yè)務(wù)數(shù)據(jù)->AI模型->業(yè)務(wù)邏輯->影響用戶行為->新的業(yè)務(wù)數(shù)據(jù)這個流程是自給自足的。這在很多推薦系統(tǒng)中表現(xiàn)得很明顯，通過用戶行為數(shù)據(jù)訓(xùn)練模型，模型對頁面信息流進行調(diào)整，從而影響用戶行為，然后用新的用戶行為數(shù)據(jù)再次調(diào)整模型。而在機器學(xué)習(xí)之前，這些觀察工作是交給運營人員去手工猜測調(diào)整。
上圖右邊談的是機器學(xué)習(xí)相關(guān)后臺架構(gòu)和傳統(tǒng)web后臺的一些差別，重點是耗時太長，必須異步處理。因此消息驅(qū)動機制對機器學(xué)習(xí)后臺是一個必須的設(shè)計。
這頁是一些個人的感受，現(xiàn)代的后端數(shù)據(jù)處理越來越偏向于DAG的形態(tài)，Spark不說了，DAG是***特色;神經(jīng)網(wǎng)絡(luò)本身也可以看作是一個DAG(RNN其實也可以看作無數(shù)個單向DNN的組合);tensorflow也是強調(diào)其Graph是DAG，另外編程模式上，Reactive編程也很受追捧。
其實DAG的形態(tài)重點強調(diào)的就是數(shù)據(jù)本身是immutable(不可修改)，只能transform后成為新的數(shù)據(jù)進入下一環(huán)。這個思維其實可以貫穿到現(xiàn)代后臺系統(tǒng)設(shè)計的每個環(huán)節(jié)，比如trakcing、analytics、數(shù)據(jù)表設(shè)計、microservice等等，但具體實施還是要case by case了。
無論如何，數(shù)據(jù)，數(shù)據(jù)的跟蹤tracking，數(shù)據(jù)的流向，是現(xiàn)代后臺系統(tǒng)的核心問題，只有data flow和data pipeline清晰了，整個后臺架構(gòu)才會清楚。
數(shù)據(jù)庫是個非常復(fù)雜的領(lǐng)域，在下面對幾個基本常用的概念做一些介紹。注意一點是graph database在這里沒有提到，因為日常使用較少，相對來說facebook提出的GraphQL倒是個有趣的概念，但也只是在傳統(tǒng)db上的一個概念封裝。
上圖是2018年12月初熱門數(shù)據(jù)庫的排名，我們可以看到關(guān)系數(shù)據(jù)庫RDBMS和NOSQL數(shù)據(jù)庫基本上平分秋色。而NOSQL中實際上又可以分為key-value storage(包括文檔型)及column based DB.
mysql這個沒啥好講，大概提一下就是。有趣的是曾經(jīng)看到一篇文章是aws CTO談的一些內(nèi)容，其中印象深刻是：如果你的用戶還不到100萬，就別折騰了，無腦使用mysql吧)
在2015年之前的一個趨勢是不少公司使用mysql作為數(shù)據(jù)存儲，但是把indexing放在外部去做。這個思路最早似乎是friendster提出的，后來uber也模仿這種做法設(shè)計了自己的數(shù)據(jù)庫schemaless。然而隨著postgreSQL的普及(postgreSQL支持對json的索引)，這種做法是否還有意義就值得商榷了。
nosql最早的使用就是key-value的查找，典型的就是redis。實際上后來的像mongo這些documentbased db也是類似的key value，只是它對document中的內(nèi)容又做了一次index (inverted index)，用空間換時間來提供查找數(shù)據(jù)，這也是cs不變的思維。
mongo/elasticsearch收到熱捧主要是因為它們的schemaless屬性，也就是不需要提前定義數(shù)據(jù)格式，只要是json就存，還都能根據(jù)每個field搜索，這非常方便程序員快速出demo。但是實際上數(shù)據(jù)量大之后還是要規(guī)范數(shù)據(jù)結(jié)構(gòu)，定義需要indexing的field的。
這里提一個比較好玩的開源project nodebb, 這是個node.js開發(fā)的論壇系統(tǒng)。在我前幾年看到這個的時候它其實只支持redis，然后當時因為一個項目把它改造了讓他支持mysql。去年再看的時候發(fā)現(xiàn)它同時支持了redis/postres/mongo，如果對比一下同樣的功能他如何在這三種db實現(xiàn)的，相信會很有幫助。
稍微談?wù)劻写鎯?。常見mysql你在select的時候其實往往會把整行都讀出來，再在其中挑那么一兩個你需要的屬性，非常浪費。而mongo這些文件型db，又不支持常見SQL。而列存儲DB的好處就是快，不用把一行所有信息讀出來，只是按列讀取你需要的，對現(xiàn)在的大數(shù)據(jù)分析特別是OLAP(Online Analytical Processing)來說特別重要。然而據(jù)另外的說法，實際上像casssandra/hbase這些并不是真正的列存儲，而只是借用了一些概念。這個我也沒深入去了解，有興趣的同學(xué)可以自己研究研究。
列存儲的一個重要領(lǐng)域是時序數(shù)據(jù)庫，物聯(lián)網(wǎng)用得多。其特色是大量寫入，只增不改(不修改數(shù)據(jù))，但是讀的次數(shù)相對于很少(想想物聯(lián)網(wǎng)的特點，隨時有數(shù)據(jù)寫入，但是你不會隨時都在看你家小米電器的狀態(tài)。。。)
注意說write/read是正交的。這意思是每次寫入是一次一行，而讀是按列，加上又不會修改數(shù)據(jù)，因此各自都能保持極快的速度
下面簡單談一下微服務(wù)，大部分直接看PPT就可以了，有幾頁略微談一下個人思考。
上面這頁說說，其實微服務(wù)所謂的服務(wù)發(fā)現(xiàn)/name service不要被忽悠覺得是多神奇的東西。最簡單的Nginx/Apache這些都能做(域名轉(zhuǎn)向，proxy)，或者你要寫個name : address的對應(yīng)關(guān)系到db里面也完全可以，再配一個定時healthcheck的服務(wù)，最簡單的服務(wù)發(fā)現(xiàn)也就行了。
高級點用到zookeeper/etcd等等，或者SpringCloud全家桶，那只是簡化配置，原理都一樣。從開發(fā)角度來看，微服務(wù)的開發(fā)并不是難點，難點是微服務(wù)的配置和部署。最近一段時間微服務(wù)部署也是業(yè)界熱點，除了全家桶形態(tài)的SpringCloud，也可以看看lstio這些開源工具。
上圖主要大致對比一下，看看從早期的Spring到現(xiàn)在Spring Cloud的變化。想來用過Java Tomcat的朋友都能體會Java這一套Config based development的繁瑣，開發(fā)的精力很多不是在業(yè)務(wù)代碼上，往往會化不少精力去折騰配置文件。當然，Spring Cloud在這方面簡化了不少，不過個人還是不太喜歡java，搞很多復(fù)雜的設(shè)計模式，封裝了又封裝。
這里要說并不是微服務(wù)解決一切，熱門的Python Django盡管有restful-framework，但是它實際上是一個典型的Monolithic體系。對很多核心業(yè)務(wù)，其實未必要拆開成微服務(wù)。
這兩者是互補關(guān)系，不是替代關(guān)系。
下面的docker我就不仔細談了，PPT基本表達了我想表述的概念，主要意思是
- docker能夠簡化部署，簡化開發(fā)，能夠在某種程度上讓開發(fā)環(huán)境和產(chǎn)品環(huán)境盡量接近
- 不要擔心docker的性能，它不是虛擬機，可以看作在server上運行的一個process。
上圖是描述docker之前開發(fā)人員的常見開發(fā)環(huán)境，首先在自己機器上裝一大堆服務(wù)，像mysql, redis, tomcat啥的。也有直接在遠程服務(wù)器安裝環(huán)境后，多人共同登錄遠端開發(fā)，各自使用一個端口避免沖突…. 實際上這種土法煉鋼的形態(tài)，在2019年的今天仍然在國內(nèi)非常普及。
這種形態(tài)的后果就是在***發(fā)布到生產(chǎn)環(huán)境時，不同開發(fā)人員會經(jīng)歷長時間的“聯(lián)調(diào)”，各種端口、權(quán)限、腳本、環(huán)境設(shè)置在生產(chǎn)環(huán)境再來一遍…這也是過去運維人員的主要工作。
上一頁提到的問題，并不是一定要docker來解決。在這之前，虛擬機VM的出現(xiàn)，以及vagrant這樣的工具，都讓開發(fā)環(huán)境的搭建多少輕松了一些。不過思路仍然是把VM作為一個獨立服務(wù)器使用，只是因為快照、鏡像和輔助工具，讓環(huán)境的配置、統(tǒng)一和遷移更加簡單快捷。
上圖是對比程序運行在物理服務(wù)器、VM及docker時的資源共享情況，可以看到運行在Docker的應(yīng)用，并沒有比并發(fā)運行在物理服務(wù)器上占用更多資源。
下圖是簡單的docker使用，不做贅述。
這一頁主要是強調(diào)Docker并不等同于虛擬機。虛擬機所占資源是獨享的，比如你啟動一個VM，分配2G內(nèi)存，那么這個VM里不管是否運行程序都會占用2G內(nèi)存。然而如果你啟動一個Docker，里面運行一個簡單web服務(wù)，在不強制指定內(nèi)存占用情況下，如果沒有請求進入，沒有額外占用內(nèi)存，那么這個docker服務(wù)對整機的內(nèi)存占用幾乎為0(當然仍然存在一些開銷，但主要是根據(jù)該程序自身的運行狀況而定)。
***Kubernetes這里大概說說host-pod-container的關(guān)系，一個host可以是物理機或者vm，pod不是一個docker，而是可以看作有一個ip的...(不知道怎么形容)，總之一個pod可以包括多個container(docker)，pod之中的container可以共享該pod的資源(ip，storage等)。不過現(xiàn)實中似乎大多是一個pod對一個container。
對互聯(lián)網(wǎng)一些熱門概念和演變過程的一個很簡略的描述就到這里了，謝謝。
【本文為51CTO專欄作者“騰訊技術(shù)工程”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者(微信號：Tencent_TEG)】
