從技術演變的角度看互聯網後臺架構

 

這是去年在部門內部作的一個面向後臺開發新同窗的課程，由於其餘BG一些同窗要求分享，因此發一下。

其實內容都是些常見開源組件的high level描述，好比flask, express框架，中間件的演化，micro service的概念，一些對nosql/column based db的概念介紹，docker的一些簡單概念等等。從單個概念來講，這只是一些科普。

可是爲何當時要開這門課呢？重點是我發現不少新入職的後臺開發同窗並不太清楚本身作的東西在現代互聯網總體架構中處於一個什麼樣的角色，而在IEG內部則由於遊戲開發和互聯網開發的一些歷史性差別，有些概念並不清晰。

拿中間件來講，不少web application不用啥中間件同樣能夠跑很好，那麼是否是都要上redis？到底解決什麼問題？中間件又存在什麼問題？中臺和中間件又是個什麼關係？若是開個mq就是中間件，微服務又是要作啥？

若是能從這十多年來互聯網應用的整個tech stack變化去看待backend architecture的一些改變，應該是一件有趣也有意思的事情。這是當時寫這個ppt開課的初衷。

我不敢說我在這個ppt裏面的一些私貨概念就是對的，可是也算是我的這麼多年的一些認知理解，拋磚引玉吧。

強調一點，這個ppt的初衷是但願從近十多年來不一樣時代不一樣熱點下技術棧的變化來看看咱們是如何從最先的php/asp/jsp<=>mysql這樣的兩層架構，一個階段一個階段演變到如今繁複的大數據、機器學習、消息驅動、微服務架構這樣的體系，而後在針對其中比較重要的幾個方面來給新入門後臺開發的同窗起個「提綱目錄」的做用。若是要對每一個方面都深刻去談，那確定不是一兩頁PPT就能作到的事情。

下面咱們開始。首先看第一頁以下圖：什麼是System Design?什麼是架構設計？爲何要談架構設計？

之因此拋出這個問題，是由於平時經常聽到兩個互相矛盾的說法：一方面不少人愛說「架構師都是不幹活誇誇其談」，另外一方面又有不少人苦惱限於平常業務需求開發，沒法或者沒有機會去從總體架構思考，不知道怎麼成長爲架構師。

上面ppt中頗有趣的是第一句英文，翻譯過來剛好能夠反映了論壇上常常有人問的「如何學習架構」的問題：不少leader一來就是扔幾本書（書名）給新同窗，指望他們讀完書就立刻升級。。。這種通常都只會帶來失望。

何爲架構師？不寫代碼只畫PPT？

不是的，架構師的基本職責是要在項目早期就能設計好基本的框架，這個框架可以確保團隊成員順利coding知足近期內業務需求的變化，又能爲進一步的發展留出空間（所謂scalability），這便是所謂技術選型。如何確保選型正確？對於簡單的應用，或者沒有新意徹底是實踐過屢次的相同方案，確實靠幾頁PPT足矣。可是對於新的領域新的複雜需求，這個需求未必都是業務需求，也包括根據團隊自身特色（人員太多、太少、某些環節成員不熟悉須要剝離開）來進行新的設計，對現有技術從新分解組合，這時候就須要架構師本身編碼實現原型並驗證思路正確性。

要達到這樣的目標難不難？難！可是如今不是2000年了，是2019年了，大量的框架(framework)、開源工具和各類best practice，其實都是在幫咱們解決這件事情。而這些框架並非憑空而來，而是在這十多年互聯網的演化中由於要解決各類具體業務難點而一點一點積累進化而來。不管是從mysql到mongodb到cassandra到time series db，或者從memcached到redis，從lucene到solr到elasticsearch，從離線批處理到hadoop到storm到spark到flink，技術不是忽然出現的，老是站在前人的肩膀上不斷演變的。而要能在浩如煙海的現代互聯網技術棧中選擇合適的來組裝本身的方案，則須要對技術的來源和歷史有必定的瞭解。不然就會出現一些新人張口ELK，閉口tensorflow，而後一個簡單的異步消息處理就會讓他們張口結舌的現象。

20多年前的經典著做DesignPatterns中講過學習設計模式的意義，放在這裏很是經典：學習設計模式並非要你學習一種新的技術或者編程語言，而是創建一種交流的共同語言和詞彙，在方案設計時方便溝通，同時也幫助人們從更抽象的層次去分析問題本質，而不被一些實現的細枝末節所困擾。同時，當咱們能把不少問題抽象出來以後，也能幫咱們更深刻更好地去了解現有系統-------這些意義，對於今天的後端系統設計來講，也仍然是正確的。

下圖是咱們要談的幾個主要方面。

上面的幾個主題中，第一個後臺架構的演化是本身從業十多年來，體會到的互聯網技術架構的總體變遷。而後分紅後臺前端應用框架、middleware和存儲三大塊談一下，最後兩節微服務和docker則是給剛進入後臺開發的同窗作一些概念普及。其中我的以爲最有趣的，是第一部分後臺架構的演化和第三部分的中間件，由於這二者是很好地反映了過去十多年互聯網發展期間技術棧的變化，從LAMP到MEAN Stack，從各類繁複的中間層到漸漸統一的消息驅動+流處理，每一個階段的業界熱點都至關有表明性。

固然，不是說web框架、數據存儲就不是熱點了，姑且不說這幾年web前端的複雜化，光後端應用框架，node的express，python的django/flask，go在國內的盛行，都是至關有趣的。在數據存儲領域，列存儲和時序數據隨着物聯網的發展也是備受重視。可是篇幅所限，在這個課程中這些話題也就只能一帶而過，由於這些與其說是技術的演變過程，不如說是不一樣的技術選型和方向了，好比說Mysql適合OLTP（Online Transaction Processing），而Cassandra/Hbase等則適合OLAP(Online Analyical Processing)，並不能說後者就優於前者。

下面咱們先來看後臺架構的演化

嚴格說這是個很大的標題，從2000年到如今的故事太多了，我這裏只能盡力而爲從我的體驗來分析。

首先是2008年之前，我把它稱爲網站時代。爲何這麼說？由於那時候的後臺開發就是寫網站，並且一般是頁面代碼和後臺數據邏輯一塊兒寫。你只要能寫JSP/PHP/ASP來讀寫Mysql或者SQL Server，基本就能保證一份不錯的工做了。

要強調一下，這種簡單的兩層結構並不能說就是落後。在如今各個企業、公司以及小團隊的大量web應用包括移動App的後端服務中，採用這種架構的不在少數，尤爲是不少公司、學校、企業的內部服務，用這種架構已經足夠了。

注意一個時間節點：2008。

固然，這個節點是我YY的。這個節點能夠是2007，或者2006。這個時間段發生了兩個影響到如今的事情：google上市，facebook開始推開

我我的相信前者上市加上它發表的那三篇大數據paper影響了後來業界的技術方向，後者的火熱則形成了社交成爲業務熱點。恰恰社交網站對大數據處理有着自然的需求，技術的積累和業務的需求就這麼陰差陽錯完美結合了起來，直接影響了大海那邊後面的科技發展。

同時在中國，那個時候倒是網絡遊戲MMO的黃金年代，對單機單服高併發實時交互的需求，遠遠壓過了對海量數據data mining的須要，在這個時間點，中美兩邊的互聯網科技樹發生了比較大的分叉。這卻是並無優劣之說，只是業務場景的重要性致使了技能樹的側重。直到今天，單機(包括簡單的多服務器方案)高併發、高QPS仍然也是國內業界所追求的目標，而在美國那邊，這只是一個業務指標而已，更看重的是如何進行水平擴展(horizontal scaling)和分散壓力。

國內和美國的科技樹回到一條線上，大數據的業務需求和相關技術發展緊密結合起來，可能要到2014年左右，隨着互聯網創業的盛行，O2O業務對大數據實時處理、機器學習推薦提出了真正的需求時，纔是國內業界首次出現技術驅動業務，算法驅動產品的現象，從新和美國灣區那邊站在了一條線上，而這則是後話了。

到了2010年先後，facebook在全球已是現象級產品，當時微軟直接放棄了windows live，就是爲了不在社交領域硬懟facebook。八卦一下當時在美國灣區那邊聚餐的時候，若是誰說他是facebook的，那基本就是全場羨慕的焦點。

facebook的崛起也帶動了其餘大量的社交網站開始出現，社交網站最大的特色就是頻繁的用戶搜索、推薦，當用戶上億的時候，這就是前面傳統的兩層架構沒法處理的問題了。所以這就帶動了中間件的發展。實際上在國外不多有人用中間件或者middelware這個詞，更可能是探討如何把各類service集成在一塊兒，像國內這樣強行分紅frontend/middleware/storage的概念是沒聽人這麼談過的，後面中間件再說這問題。當時的一個慣例是用php作所謂的膠水語言(glue language)，而後經過hessian這些協議工具來把其餘java服務鏈接到一塊兒。與此同時，爲了提升訪問速度，下降後端查詢壓力，memcached/redis也開始大量使用。基於lucene的搜索（2010左右不少是自行開發）或者solr也被用在用戶搜索、推薦以及type ahead這些場景中。

我記憶中在2012年以前消息隊列的使用還不是太頻繁，不像後來這麼重要。當時常見的應該就是beanstalkd/rabbitmq, zeromq其實我在灣區那邊不多聽人用，卻是後來回國後看到國內用的人還很多。Kafka在2011年已經出現了，有少部分公司開始用，不過還不是主流。

2013年以後就是大數據+雲的時代了，若是你們回想一下，基本上國內也是差很少在2014年左右開始叫出了雲+大數據的口號（2013年國內還在手遊狂潮中...）。不談國外，在中國那段時間就是互聯網創業的時代，從千團大戰到手遊爆發到15年開始的O2O，業務的發展也帶動了技術棧的飛速進步。左上角大體上也寫了這個時代互聯網業界的主要技術熱點，實際上這也就是如今的熱點。不管國內國外，絕大部分公司還並無離開雲+大數據這個時代。不管是大數據的實時處理、數據挖掘、推薦系統、Docker化，包括A/B測試，這些都是不少企業還正在努力全面解決的問題。

可是在少數站在業界技術頂端或者沒有歷史技術包袱的新興公司，從某個角度上來講，他們已經開始在往下一個時代前進：機器學習AI驅動的時代

2018年開始，實際上多是2017年中開始，AI驅動成了各大公司口號。上圖是facebook和uber的機器學習平臺使用狀況，基本上已經所有進入業務核心。固然並非說全部公司企業都要AI驅動，顯然最近發生的波音737事件就說明該用傳統的就該傳統，別啥都往並不成熟的AI上堆。但另外一方面，不少新興公司的業務自己就是基於大數據或者算法的，所以他們在這個領域也每每走得比較激進。因爲這個AI驅動還並無一個很明確的定義和概念，還處於一種早期萌芽的階段，在這裏也就很少YY了。

互聯網後臺架構發展的簡單過程就在這裏講得差很少了，而後咱們快速談一下web開發框架。

首先在前面我提到，在後端架構中其實也有所謂的frontend(前臺）開發存在，通常來講這是指響應用戶請求，實現具體業務邏輯的業務邏輯層。固然這麼定義略微粗糙了些，不少中間存儲、消息服務也會封裝一些業務相關邏輯。總之web開發框架每每就是爲了更方便地實現這些業務邏輯而存在的。

前文提到在一段較長時間內，國內的技術熱點是單機高併發高QPS，所以不少那個時代走過來的人會本能地質疑web框架的性能，而更偏好TCP長連接甚至UDP協議。然而這每每是自尋煩惱，由於除開特別的強實時系統，不管是休閒手遊、視頻點播仍是信息流，都已是基於HTTP的了。

上圖所提到的兩個問題中，我想強調的是第一點：全部的業務，在能知足需求的狀況下，首選HTTP協議進行數據交互。準確點說，首選JSON，使用web API。

Why? 這就是上圖第一個問題所回答的：無狀態、易調試易修改、通常沒有80端口限制。

最爲詬病的無非是性能，然而實際上對非實時應用，晚個半秒一秒不該該是大問題，要考慮的是水平擴展scalability，不是實時響應（由於前提就是非實時應用）；其次實在不行你還有websocket能夠用。

這一部分是簡單列舉了一下不一樣框架的使用，能夠看出不一樣框架的概念其實差很少。重點是要注意到middleware這個說法在web framework和後端架構中的意義不一樣。在web framework中是指具體處理GET/POST這些請求以前的一個通用處理（每每是鏈式調用），好比能夠把鑑權、一些日誌處理和請求記錄放在這裏。但在後端架構設計中的middleware則是指相似消息隊列、緩存這些在最終數據庫以前的中間服務組件。

 

最後這裏是想說web framework並非包治百病，實際上那只是提供了基礎功能的一個library，做爲開發者則更多須要考慮如何定義配置文件，一些敏感參數如token、密碼怎麼傳進來，開發環境和生產環境的配置如何自動切換，單元測試怎麼搞，代碼目錄怎麼組織。有時候咱們能夠用一些好比Yeoman之類的scaffold工具來自動生成項目代碼框架，或者相似django這種也可能自動生成基本目錄結構。

下面進入Middleware環節。again，強調一下這裏只是根據我的經驗和感覺談談演化過程。

這一頁只是大體講一下怎麼定義中間件middleware。說句題外話，在美國灣區那邊提這個概念的不多，而阿里又特別喜歡說中間件，二者相互的交流很是頭痛。灣區那邊很多google、facebook還有pinterest/uber這些的朋友好幾回都在羣裏問說啥叫中間件。

中間件這個概念很含糊，應該是阿里提出來的，對應於middleware（不過彷佛也不是徹底對應），多是由於早期java的EJB那些概念裏面比較強調middleware這一點吧（我的猜的）。大體上，若是咱們把web後端分爲直接處理用戶請求的frontend，最後對數據進行持久存儲(persistant storage)這兩塊，那麼中間對數據的全部處理環節均可以視爲middleware。

和中間件對應的另外一個阿里發明的概念是中臺。近一年多阿里的中臺概念都至關引人注意，這裏對中臺不作太多描述。整體來講中臺更可能是偏向業務和組織架構劃分，不能說是一個技術概念，也不是面向開發人員的。而中間件middleware是標準的技術組件服務。

那麼咱們天然會有一個問題：爲何要用中間件？

談到爲何要用middlware，這裏用推薦系統舉例。

推薦系統，對數據少用戶少的狀況下，簡單的mysql便可，好比早期論壇的什麼top 10熱門話題啊，最多回復的話題啊，均可以視爲簡單的推薦，數據量又不大的狀況下，直接select就能夠了。

若是是用戶推薦的話，用戶量不大的狀況下，也能夠如法炮製，選擇同一區域（城市）年齡至關的異性，最後隨機挑幾個給你，相信世紀佳緣之類的交友網站早期實現也就是相似的模式。

那麼，若是用戶量多了呢？每次都去搜數據庫，同時在線用戶又多，那對數據庫的壓力就巨大了。這時候就是引入緩存，memcached、redis就出現了。

簡單的作法就是把搜索條件做爲key，把結果做爲value存入緩存。打個比方你能夠把key存爲 20:40:beijing:male (20到40歲之間北京的男性），而後把第一次搜索的結果所有打亂shuffle後，存前1000個，10分鐘過時，再有人用相似條件搜索，就直接把緩存數據隨機挑幾個返回。放心，通常來講不會有人10分鐘就把1000個用戶的資料都看完了，中間偶有重複也沒人在乎（用世紀佳緣、百合網啥的時候看到太重複的吧）。

不過話又說回來，現代數據庫，尤爲是相似mongodb/es這些大量佔用內存的nosql，已經對常常查詢的數據作了緩存，在這之上再加cache，未必真的頗有效，這須要case by case去分析了，總之盲目加cache也並不推薦。

加緩存是爲了解決訪問速度，減輕數據庫壓力，可是並不提升推薦精準度。若是咱們要提升推薦效果呢？在2015年以前機器學習還沒那麼普及成熟的時候，咱們怎麼搞呢？

提升推薦效果，在機器學習以前有兩種作法：

- 引入基於lucene的搜索引擎，在搜索的同時經過定製方案實現scoring，好比我能夠利用lucene對用戶的年齡、性別、地址等進行indexing，可是再返回結果時我再根據用戶和查詢者兩人的具體信息進行關聯，自定義返回的score（能夠視爲推薦相關係數）

- 採用離線批處理。當然能夠用hadoop，可是就太殺雞用牛刀了。常見的是定時批處理任務，按某種規則劃分用戶羣體，對每一個羣體再作全量計算後把推薦結果寫入緩存。這種能夠作很繁複準確的計算，雖然慢，但效果每每不錯。這種作法也經常使用在手機遊戲的PvP對戰列表裏面。

這些處理方法對社交網絡/手遊這類型的其實已經足夠了，可是新的業務是不斷出現的。隨着uber/滴滴/餓了麼/美團這些須要實時處理數據的app崛起，做爲一個司機，並不想你上線後過幾分鐘纔有客人來吧，你但願你開到一個熱點區域，一開機就立刻接單。

因此這種對數據進行實時（近實時）處理的需求也帶動了後端體系的大發展，kafka/spark等等流處理大行其道。這時候的後端體系就漸漸引入了消息驅動的模式，所謂消息驅動，就是對新的生產數據會有多個消費者，有的是知足實時計算的需求（好比司機信息須要馬上可以被快速檢索到，又不能每次都作全量indexing，就須要用到spark），有的只是爲了數據分析，寫入相似cassandra這些數據庫裏，還有的多是爲了生成定時報表，寫入到mysql。

大數據的處理一直是業界熱點領域。記得2015年硅谷一個朋友就是從一家小公司作php跳去另外一家物聯網公司作spark相關的工做，以前還很擔憂玩不轉，搞了兩年就儼然業界大佬被oracle挖去負責雲平臺～～～

anyway，這時候對後端體系的要求是一方面能快速知足實時需求，另外一方面又能知足各類耗時長的數據分析、data lake存儲等等，以及當時漸漸普及的機器學習模型（當時2015年初和幾個朋友搞startup，其中一個是walmart lab的機器學習專家，上來就一堆模型，啥數據和用戶都尚未就把模型擺上來了，後來搞得很是頭痛。當時沒有keras/pytorch/tf這些，那堆模型是真心搞不太懂，可是又不敢扔，要靠那東西去包裝拿投資的。。。）

可是咱們再看上面的圖，是否是感受比較亂呢？各類系統的數據寫來寫去，是否是有點messy？當公司團隊增多，系統複雜度愈來愈高的時候，咱們該怎麼梳理？

到了2017以後，前面千奇百怪的後端體系基本上都趨同了。kafka的實時消息隊列，spark的流處理（固然如今也能夠換成flink，不過大部分應該仍是spark），而後後端的存儲，基於hive的數據分析查詢，而後根據業務的模型訓練平臺。各個公司反正都差很少這一套，在具體細節上根據業務有所差別，或者有些實力強大的公司會把中間一些環節替換成本身的實現，不過無論怎麼變幻無窮，總體思路基本都一致了。

這裏能夠看到機器學習和AI模型的引入。我的認爲，machine learning的很大一個好處，是簡化業務邏輯，簡化後臺流程，否則一套業務一套實現，各類數據和業務規則很難用一個總體的技術平臺來完成。相比前面一頁的後臺架構，這一頁要清晰許多，並且是一個DAG有向無環圖的形式，數據流向很明確。咱們在下面再來講這個機器學習對業務數據流程的簡化。

在傳統後端系統中，業務邏輯其實和數據是客觀分離的，邏輯規則和數據之間並不存在客觀聯繫，而是人爲主觀加入，並沒造成閉環，如上圖左上所示。而基於機器學習的平臺，這個閉環就造成了，從業務數據->AI模型->業務邏輯->影響用戶行爲->新的業務數據這個流程是自給自足的。這在不少推薦系統中表現得很明顯，經過用戶行爲數據訓練模型，模型對頁面信息流進行調整，從而影響用戶行爲，而後用新的用戶行爲數據再次調整模型。而在機器學習以前，這些觀察工做是交給運營人員去手工猜想調整。

上圖右邊談的是機器學習相關後臺架構和傳統web後臺的一些差異，重點是耗時太長，必須異步處理。所以消息驅動機制對機器學習後臺是一個必須的設計。

這頁是一些我的的感覺，現代的後端數據處理愈來愈偏向於DAG的形態，Spark不說了，DAG是最大特點；神經網絡自己也能夠看做是一個DAG（RNN其實也能夠看做無數個單向DNN的組合）；tensorflow也是強調其Graph是DAG，另外編程模式上，Reactive編程也很受追捧。

其實DAG的形態重點強調的就是數據自己是immutable（不可修改），只能transform後成爲新的數據進入下一環。這個思惟其實能夠貫穿到現代後臺系統設計的每一個環節，好比trakcing、analytics、數據表設計、microservice等等，但具體實施仍是要case by case了。

不管如何，數據，數據的跟蹤tracking，數據的流向，是現代後臺系統的核心問題，只有data flow和data pipeline清晰了，整個後臺架構纔會清楚。

數據庫是個很是複雜的領域，在下面對幾個基本經常使用的概念作一些介紹。注意一點是graph database在這裏沒有提到，由於平常使用較少，相對來講facebook提出的GraphQL卻是個有趣的概念，但也只是在傳統db上的一個概念封裝。

上圖是2018年12月初熱門數據庫的排名，咱們能夠看到關係數據庫RDBMS和NOSQL數據庫基本上勢均力敵。而NOSQL中實際上又能夠分爲key-value storage（包括文檔型）及column based DB.

mysql這個沒啥好講，大概提一下就是。有趣的是曾經看到一篇文章是aws CTO談的一些內容，其中印象深入是：若是你的用戶還不到100萬，就別折騰了，無腦使用mysql吧）

在2015年以前的一個趨勢是很多公司使用mysql做爲數據存儲，可是把indexing放在外部去作。這個思路最先彷佛是friendster提出的，後來uber也模仿這種作法設計了本身的數據庫schemaless。然而隨着postgreSQL的普及(postgreSQL支持對json的索引)，這種作法是否還有意義就值得商榷了。

 

nosql最先的使用就是key-value的查找，典型的就是redis。實際上後來的像mongo這些documentbased db也是相似的key value，只是它對document中的內容又作了一次index (inverted index)，用空間換時間來提供查找數據，這也是cs不變的思惟。

mongo/elasticsearch收到熱捧主要是由於它們的schemaless屬性，也就是不須要提早定義數據格式，只要是json就存，還都能根據每一個field搜索，這很是方便程序員快速出demo。可是實際上數據量大以後仍是要規範數據結構，定義須要indexing的field的。

這裏提一個比較好玩的開源project nodebb, 這是個node.js開發的論壇系統。在我前幾年看到這個的時候它其實只支持redis，而後當時由於一個項目把它改造了讓他支持mysql。去年再看的時候發現它同時支持了redis/postres/mongo，若是對比一下一樣的功能他如何在這三種db實現的，相信會頗有幫助。

稍微談談列存儲。常見mysql你在select的時候其實每每會把整行都讀出來，再在其中挑那麼一兩個你須要的屬性，很是浪費。而mongo這些文件型db，又不支持常見SQL。而列存儲DB的好處就是快，不用把一行全部信息讀出來，只是按列讀取你須要的，對如今的大數據分析特別是OLAP(Online Analytical Processing)來講特別重要。然而據另外的說法，實際上像casssandra/hbase這些並非真正的列存儲，而只是借用了一些概念。這個我也沒深刻去了解，有興趣的同窗能夠本身研究研究。

列存儲的一個重要領域是時序數據庫，物聯網用得多。其特點是大量寫入，只增不改（不修改數據），可是讀的次數相對於不多（想一想物聯網的特色，隨時有數據寫入，可是你不會隨時都在看你家小米電器的狀態。。。）

注意說write/read是正交的。這意思是每次寫入是一次一行，而讀是按列，加上又不會修改數據，所以各自都能保持極快的速度

下面簡單談一下微服務，大部分直接看PPT就能夠了，有幾頁略微談一下我的思考。

上面這頁說說，其實微服務所謂的服務發現/name service不要被忽悠以爲是多神奇的東西。最簡單的Nginx/Apache這些都能作（域名轉向，proxy），或者你要寫個name : address的對應關係到db裏面也徹底能夠，再配一個定時healthcheck的服務，最簡單的服務發現也就好了。

高級點用到zookeeper/etcd等等，或者SpringCloud全家桶，那只是簡化配置，原理都同樣。從開發角度來看，微服務的開發並非難點，難點是微服務的配置和部署。最近一段時間微服務部署也是業界熱點，除了全家桶形態的SpringCloud，也能夠看看lstio這些開源工具。

上圖主要大體對比一下，看看從早期的Spring到如今Spring Cloud的變化。想來用過Java Tomcat的朋友都能體會Java這一套Config based development的繁瑣，開發的精力不少不是在業務代碼上，每每會化很多精力去折騰配置文件。固然，Spring Cloud在這方面簡化了很多，不過我的仍是不太喜歡java，搞不少複雜的設計模式，封裝了又封裝。

這裏要說並非微服務解決一切，熱門的Python Django儘管有restful-framework，可是它其實是一個典型的Monolithic體系。對不少核心業務，其實未必要拆開成微服務。

這二者是互補關係，不是替代關係。

下面的docker我就不仔細談了，PPT基本表達了我想表述的概念，主要意思是

- docker可以簡化部署，簡化開發，可以在某種程度上讓開發環境和產品環境儘可能接近

- 不要擔憂docker的性能，它不是虛擬機，能夠看做在server上運行的一個process。

 

 

上圖是描述docker以前開發人員的常見開發環境，首先在本身機器上裝一大堆服務，像mysql, redis, tomcat啥的。也有直接在遠程服務器安裝環境後，多人共同登陸遠端開發，各自使用一個端口避免衝突…. 實際上這種土法煉鋼的形態，在2019年的今天仍然在國內很是普及。

這種形態的後果就是在最後發佈到生產環境時，不一樣開發人員會經歷長時間的「聯調」，各類端口、權限、腳本、環境設置在生產環境再來一遍…這也是過去運維人員的主要工做。

上一頁提到的問題，並非必定要docker來解決。在這以前，虛擬機VM的出現，以及vagrant這樣的工具，都讓開發環境的搭建多少輕鬆了一些。不過思路仍然是把VM做爲一個獨立服務器使用，只是由於快照、鏡像和輔助工具，讓環境的配置、統一和遷移更加簡單快捷。

上圖是對比程序運行在物理服務器、VM及docker時的資源共享狀況，能夠看到運行在Docker的應用，並無比並發運行在物理服務器上佔用更多資源。

下圖是簡單的docker使用，不作贅述。

這一頁主要是強調Docker並不等同於虛擬機。虛擬機所佔資源是獨享的，好比你啓動一個VM，分配2G內存，那麼這個VM裏無論是否運行程序都會佔用2G內存。然而若是你啓動一個Docker，裏面運行一個簡單web服務，在不強制指定內存佔用狀況下，若是沒有請求進入，沒有額外佔用內存，那麼這個docker服務對整機的內存佔用幾乎爲0（固然仍然存在一些開銷，但主要是根據該程序自身的運行情況而定）。

最後Kubernetes這裏大概說說host-pod-container的關係，一個host能夠是物理機或者vm，pod不是一個docker，而是能夠看做有一個ip的...（不知道怎麼形容），總之一個pod能夠包括多個container(docker)，pod之中的container能夠共享該pod的資源（ip，storage等）。不過現實中彷佛大可能是一個pod對一個container。

對互聯網一些熱門概念和演變過程的一個很簡略的描述就到這裏了，謝謝。

原文： https://cloud.tencent.com/developer/article/1404117