“互聯(lián)網(wǎng)+”架構(gòu)這個題目太大，要談清楚這個架構(gòu)的來龍去脈以及其中演變不容易。稍微不小心就容易掛一漏萬，貽笑大方。所以決定要改變想到哪，寫到哪的習(xí)慣，從總體上做一個規(guī)劃。

[[152146]]

云計(jì)算雙雄——谷歌和亞馬遜

谷歌和亞馬遜引領(lǐng)分布式系統(tǒng)革命的四篇論文(谷歌關(guān)于GFS、Map/Reduce、Bigtable的三篇論文以及亞馬遜一篇關(guān)于Dynamo的論文)為基礎(chǔ)，涉及了云計(jì)算架構(gòu)、Hadoop/Spark大數(shù)據(jù)生態(tài)平臺、軟件定義網(wǎng)絡(luò)、軟件定義存儲、軟件定義數(shù)據(jù)中心、Docker容器、Mesos和Kubernetes容器集群管理、微服務(wù)架構(gòu)、比特幣區(qū)塊鏈、Peer-to-Peer全分布式架構(gòu)、互聯(lián)網(wǎng)+安全架構(gòu)等一系列概念和技術(shù)。而談完基礎(chǔ)架構(gòu)，然后就要針對不同的行業(yè)，討論互聯(lián)網(wǎng)+架構(gòu)的特點(diǎn)，包括金融、電信等。行業(yè)方面的互聯(lián)網(wǎng)+架構(gòu)最難，需要找到具有實(shí)踐經(jīng)驗(yàn)的行業(yè)專家來提供第一手材料。

說完規(guī)劃，我們回過頭來談谷歌的三篇著名論文。2003年到2004年，Google陸續(xù)發(fā)表了關(guān)于GFS、MapReduce和BigTable的三篇論文，基本上公開了谷歌內(nèi)部用于處理搜索海量數(shù)據(jù)的平臺架構(gòu)。GFS是大規(guī)模的分布式文件系統(tǒng)，MapReduce是一個并行處理框架下的編程模式，BigTable是建立在GFS基礎(chǔ)上一個按鍵值方式組織的非關(guān)系型數(shù)據(jù)庫。由于當(dāng)時的技術(shù)、產(chǎn)品和平臺無法滿足谷歌快速增長的業(yè)務(wù)發(fā)展，谷歌根據(jù)搜索業(yè)務(wù)的特點(diǎn)，大膽創(chuàng)新，打破了傳統(tǒng)分布式文件系統(tǒng)的條條框框，開發(fā)了一個支持大規(guī)模擴(kuò)展性的容錯分布式文件系統(tǒng)，并在其基礎(chǔ)上構(gòu)建了并行計(jì)算平臺和分布式數(shù)據(jù)庫，使得谷歌的搜索平臺能處理前所未有并不斷爆炸性增長的海量數(shù)據(jù)。

下面我們簡單介紹一下這三篇論文的重點(diǎn)：

谷歌的第一篇論文是詳實(shí)的介紹了谷歌內(nèi)部使用的分布式文件系統(tǒng)GFS。谷歌的GFS與其它分布式文件系統(tǒng)的設(shè)計(jì)理念不同，首先，GFS特別強(qiáng)調(diào)容錯性。它的設(shè)計(jì)思想是在大規(guī)模分布式系統(tǒng)下，采用廉價硬件來構(gòu)建分布式平臺，系統(tǒng)各環(huán)節(jié)都會出錯，因此出錯不像傳統(tǒng)系統(tǒng)設(shè)計(jì)那樣當(dāng)特例來處理，而是把出錯作為常態(tài)來處理。第二，GFS的設(shè)計(jì)場景是處理多GB級甚至TB級的大文件，與傳統(tǒng)分布式文件系統(tǒng)多數(shù)處理小文件不同。第三，大部分谷歌的搜索應(yīng)用特點(diǎn)是追加文件而不是修改文件，幾乎沒有隨機(jī)寫的情形。寫入后大部分的動作是讀，而且是順序讀。第四，同時設(shè)計(jì)應(yīng)用和文件系統(tǒng)API以提高系統(tǒng)靈活性。例如谷歌提供一個原子追加文件操作，可以讓多客戶端同時對一個文件進(jìn)行追加操作而不需要同步客戶端的操作。GFS采用一個集中式主從架構(gòu)，主節(jié)點(diǎn)(Master)管理元數(shù)據(jù)，從節(jié)點(diǎn)(Chunk Server)存儲數(shù)據(jù)。文件分成一塊塊固定長度64MB的塊，存放在從節(jié)點(diǎn)上。每一塊數(shù)據(jù)都同時存放在多個從節(jié)點(diǎn)上作為冗余備份以提供容錯和高可用性。GFS不提供POSIX兼容支持，因此客戶端不能像傳統(tǒng)分布式文件系統(tǒng)那樣直接掛載，只能通過GFS的客戶端來和主節(jié)點(diǎn)、從節(jié)點(diǎn)通信以讀寫數(shù)據(jù)。除GFS客戶端緩存元數(shù)據(jù)外，客戶端和從節(jié)點(diǎn)不緩存數(shù)據(jù)。GFS通過持續(xù)監(jiān)控、數(shù)據(jù)一致性校驗(yàn)，多副本、快速自動修復(fù)等手段來提供高可用和容錯性。GFS的這些特點(diǎn)，開創(chuàng)性的奠定了大數(shù)據(jù)處理分布式文件系統(tǒng)的基礎(chǔ)。

谷歌的第二篇論文是關(guān)于一個并行分布式處理系統(tǒng)的編程框架——MapReduce。用戶使用Map函數(shù)來處理鍵值對的數(shù)據(jù)，同時生成中間過程的鍵值對，然后通過Reduce函數(shù)來合并相同的所有對應(yīng)相同鍵的值。用戶只需要寫這兩個函數(shù)，然后谷歌的MapReduce運(yùn)行系統(tǒng)會自動的切分?jǐn)?shù)據(jù)，并把任務(wù)分配到不同節(jié)點(diǎn)上，實(shí)現(xiàn)自動調(diào)度、均衡工作負(fù)載，同時自動監(jiān)控、自動修復(fù)錯誤，管理節(jié)點(diǎn)間通信。傳統(tǒng)的并行處理應(yīng)用，需要開發(fā)者掌握MPI編程等技能，一般只是限于高性能計(jì)算領(lǐng)域。而MapReduce框架簡化了并行處理系統(tǒng)的編程，大大降低了開發(fā)者開發(fā)并行處理系統(tǒng)的門檻。和GFS的設(shè)計(jì)思想類似，MapReduce也采用主從架構(gòu)，Master負(fù)責(zé)將任務(wù)分發(fā)給Worker。Map和Reduce的名字來源于MapReduce設(shè)計(jì)者從Lisp語言中的Map和Reduce函數(shù)帶來的靈感。

谷歌的第三篇論文公開的是谷歌內(nèi)部使用的一個分布式數(shù)據(jù)庫——BigTable。該數(shù)據(jù)庫是用來管理PB級的結(jié)構(gòu)化數(shù)據(jù)，并實(shí)現(xiàn)廣泛應(yīng)用性、高擴(kuò)展性、高可用性、高性能的設(shè)計(jì)目標(biāo)。和傳統(tǒng)關(guān)系型數(shù)據(jù)庫不一樣，BigTable不提供關(guān)系數(shù)據(jù)庫接口，它的數(shù)據(jù)模型是非常有特點(diǎn)，一個BigTable是一個稀疏的、分布的、永久的多維排序圖。BigTable采用行鍵(rowkey)、列鍵(columnkey)和時間戳(timestamp)對圖進(jìn)行索引，數(shù)據(jù)是字符串，沒有傳統(tǒng)數(shù)據(jù)庫的字段定義(Schema)，因此BigTable實(shí)際上是一種基于多維鍵值模型的NoSQL數(shù)據(jù)庫。

BigTable也是采用集中式架構(gòu)，BigTable實(shí)現(xiàn)包括三個主要的功能組件：一是庫函數(shù)，鏈接到每個客戶端;二是一個主服務(wù)器;三是許多的Tablet服務(wù)器。Tablet服務(wù)器可以根據(jù)工作負(fù)載的變化，從一個簇中動態(tài)地增加或刪除。主服務(wù)器負(fù)責(zé)把Tablet分配到Tablet服務(wù)器，探測Tablet服務(wù)器的增加和過期，進(jìn)行Tablet服務(wù)器的負(fù)載均衡，以及GFS文件系統(tǒng)中的垃圾收集。除此以外，它還處理模式變化，比如表和列家族創(chuàng)建。每個Tablet服務(wù)器管理一個Tablet集合，通常，在每個Tablet服務(wù)器上會放置10到1000個Tablet。

BigTable客戶端并不是通過主服務(wù)器來讀取數(shù)據(jù)，而是直接從Tablet服務(wù)器上讀取數(shù)據(jù)。因?yàn)锽igTable客戶端并不依賴于主服務(wù)器來獲得Tablet的位置信息，從而使得在實(shí)際應(yīng)用中，主服務(wù)器負(fù)載很小。一個BigTable簇存儲了許多表。每個表都是一個Tablet集合，每個Tablet包含了位于某個域區(qū)間內(nèi)的所有數(shù)據(jù)。在最初階段，每個表只包含一個Tablet。隨著表的增長，它會被自動分解成許多Tablet，每個Tablet默認(rèn)尺寸大約是100到200MB。BigTable的數(shù)據(jù)最后是存放在GFS文件系統(tǒng)上，使用分布式鎖Chubby來保證數(shù)據(jù)一致性。

谷歌的三篇論文奠定了互聯(lián)網(wǎng)大規(guī)模分布式系統(tǒng)的架構(gòu)基礎(chǔ)，掀啟了大數(shù)據(jù)時代的帷幕。谷歌的貢獻(xiàn)主要是基于其自身的業(yè)務(wù)需求，在對比傳統(tǒng)分布式架構(gòu)優(yōu)劣勢的基礎(chǔ)上，提出了一套全新的分布式存儲、分布式并行計(jì)算和分布式數(shù)據(jù)庫的架構(gòu)。其特點(diǎn)還是在集中管理下的可擴(kuò)展分布式系統(tǒng)。

谷歌是首先提出云計(jì)算概念的公司，而另一個首創(chuàng)云計(jì)算業(yè)務(wù)模式的亞馬遜也不甘落后，于2007年發(fā)表了Dynamo分布式數(shù)據(jù)庫論文。與谷歌相同的是，亞馬遜也是根據(jù)自身的業(yè)務(wù)特點(diǎn)來做創(chuàng)新，都將系統(tǒng)出錯作為常態(tài)處理;而與谷歌不同的是，亞馬遜采用了一個無中心、完全分布式的架構(gòu)。下面我們簡單介紹Dynamo論文的要點(diǎn)：

亞馬遜的Dynamo論文公開了分布式鍵值數(shù)據(jù)庫Dynamo的設(shè)計(jì)和實(shí)施細(xì)節(jié)。Dynamo的設(shè)計(jì)主要是針對大規(guī)模電商的應(yīng)用場景，例如購物車，需要提供“Always on”(總是在線)，任何時候用戶都能修改，也就是高可用的客戶體驗(yàn)。其設(shè)計(jì)目標(biāo)是把可用性提到第一位，在某些場合犧牲一致性。Dynamo論文很明確的提出“Eventual Consistency”(最終一致性)的概念。其設(shè)計(jì)理念參考Peer-to-Peer架構(gòu)，整個分布式系統(tǒng)采用無中心架構(gòu)。Dynamo綜合了一些著名的技術(shù)來實(shí)現(xiàn)可伸縮性和可用性：數(shù)據(jù)劃分(Data partitioned)和使用一致性哈希的復(fù)制(replicated)，并通過對象版本(object versioning)提供一致性。在更新時，副本之間的一致性是由仲裁(quorum)中心化的副本同步協(xié)議來維持的。Dynamo中一共涉及三個重要的參數(shù)，其中N代表數(shù)據(jù)的副本數(shù)，W代表一次寫操作的最小必須寫成功節(jié)點(diǎn)數(shù);R達(dá)標(biāo)一次讀操作的最小讀成功節(jié)點(diǎn)數(shù)。要求W+R>N，讀數(shù)據(jù)時，只要有除了Coodinator之外的R-1個節(jié)點(diǎn)返回了數(shù)據(jù)，就算是讀成功(此時可能返回多個版本的數(shù)據(jù))。同理，寫數(shù)據(jù)時，只要有除Coordinator之外的W-1個節(jié)點(diǎn)寫入成功，就算數(shù)據(jù)寫入成功。Dynamo采用了基于gossip協(xié)議分布式故障檢測及成員(membership)協(xié)議。Dynamo只需要很少的人工管理，存儲節(jié)點(diǎn)可以添加和刪除，而不需要任何手動劃分或重新分配(redistribution)。Dynamo很早就成為Amazon電子商務(wù)平臺的核心服務(wù)的底層存儲技術(shù)，它能夠有效地?cái)U(kuò)展到極端高峰負(fù)載，在繁忙的假日購物季節(jié)沒有任何的停機(jī)時間。

Dynamo和BigTable都屬于非關(guān)系型數(shù)據(jù)庫，也就是常說的NoSQL數(shù)據(jù)庫。但兩者設(shè)計(jì)理念有很大的不同。Dynamo是完全無中心的設(shè)計(jì)，其假設(shè)是在內(nèi)部信任網(wǎng)絡(luò)部署，沒有安全的措施。而BigTable是集中式管理，利用權(quán)限控制來提供安全措施。Dynamo的數(shù)據(jù)模型是鍵值模型，而BigTable是多維排序圖。Dynamo采用一致性哈希來實(shí)現(xiàn)分布式元數(shù)據(jù)管理，而BigTable采用集中式的元數(shù)據(jù)管理。兩者的適應(yīng)場景也各不相同。Dynamo主要針對電商購物車應(yīng)用，對可用性要求高，一致性要求不高。在CAP(見上期CAP的解釋)上強(qiáng)調(diào)對A(可用性)和P(分區(qū)容錯性)的要求，是一個典型的AP數(shù)據(jù)庫。而BigTable對一致性和可擴(kuò)展性的要求比較高，比較適合處理結(jié)構(gòu)化的數(shù)據(jù)，是一個典型的CP數(shù)據(jù)庫。

互聯(lián)網(wǎng)雙雄的這幾篇論文，內(nèi)容非常詳實(shí)，基本上公開了從設(shè)計(jì)到實(shí)施的細(xì)節(jié)。當(dāng)時在Yahoo的Doug Cutting受到Google三篇論文的啟發(fā)，組織了Hadoop項(xiàng)目組，開發(fā)了風(fēng)靡一時的Hadoop大數(shù)據(jù)平臺。Hadoop的HDFS實(shí)際上是GFS的開源實(shí)現(xiàn)，HBase是BigTable的實(shí)現(xiàn)，Hadoop的MapReduce也是Google的MapReduce的開源實(shí)現(xiàn)。著名的Cassandra數(shù)據(jù)庫則是結(jié)合Dynamo和BigTable兩者的優(yōu)勢實(shí)現(xiàn)的NoSQL數(shù)據(jù)庫。

看完這幾篇論文，一個很大的感觸是谷歌和亞馬遜的創(chuàng)新，都是基于他們各自實(shí)際的業(yè)務(wù)需求，都是從實(shí)際出發(fā)，突破傳統(tǒng)架構(gòu)的條條框框來做創(chuàng)新。而我們看到更多的IT公司則是跟隨者，甚至是生搬硬套一些當(dāng)下流行的技術(shù)或框架。例如，在大數(shù)據(jù)炙手可熱的今天，我們看到一個“大數(shù)據(jù)宗教”正在興起，不管業(yè)務(wù)場景是什么，言必稱大數(shù)據(jù)，甚至一些用Excel表都能做的數(shù)據(jù)分析，也有很多人不惜搭一個Hadoop平臺來號稱大數(shù)據(jù)項(xiàng)目。這使筆者想起毛澤東生前最反對的就是教條主義，最提倡的是實(shí)事求是。當(dāng)初以王明為首的國際派，就是生搬蘇聯(lián)模式來指導(dǎo)中國革命而造成巨大損失。IT也一樣，必須一切從實(shí)際出發(fā)，從客戶需求出發(fā)，否則就會造成資源浪費(fèi)而不能解決實(shí)際問題。

另外一個感觸，也是一個問題，就是為什么像谷歌和亞馬遜會公開這些這么重要的架構(gòu)設(shè)計(jì)和技術(shù)細(xì)節(jié)?如果單從商業(yè)角度來看，這些都應(yīng)該是高度商業(yè)機(jī)密。但是從另一角度看也容易理解，從谷歌和亞馬遜這些公司來說，掙錢從來就不是他們的唯一目的，引領(lǐng)互聯(lián)網(wǎng)架構(gòu)變革和技術(shù)方向，成為行業(yè)的領(lǐng)軍企業(yè)才是像谷歌和亞馬遜這樣志存高遠(yuǎn)的公司所追求的目標(biāo)。谷歌在這方面一直引領(lǐng)潮流，大幅超越其他IT公司。當(dāng)大部分互聯(lián)網(wǎng)公司還在圍繞著谷歌的老三篇論文或是Hadoop做大數(shù)據(jù)平臺的時候，谷歌在2010年又發(fā)布了后Hadoop時代的新三篇論文，分別是Caffeine、Pregel和Dremel。后續(xù)我們會對新三篇論文進(jìn)行解讀。

【文章來源：云夢園微信公眾號】