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

[[152146]]

云計算雙雄——谷歌和亞馬遜

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

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

下面我們簡單介紹一下這三篇論文的重點：

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

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

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

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

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

谷歌的三篇論文奠定了互聯網大規模分布式系統的架構基礎，掀啟了大數據時代的帷幕。谷歌的貢獻主要是基于其自身的業務需求，在對比傳統分布式架構優劣勢的基礎上，提出了一套全新的分布式存儲、分布式并行計算和分布式數據庫的架構。其特點還是在集中管理下的可擴展分布式系統。

谷歌是首先提出云計算概念的公司，而另一個首創云計算業務模式的亞馬遜也不甘落后，于2007年發表了Dynamo分布式數據庫論文。與谷歌相同的是，亞馬遜也是根據自身的業務特點來做創新，都將系統出錯作為常態處理;而與谷歌不同的是，亞馬遜采用了一個無中心、完全分布式的架構。下面我們簡單介紹Dynamo論文的要點：

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

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

互聯網雙雄的這幾篇論文，內容非常詳實，基本上公開了從設計到實施的細節。當時在Yahoo的Doug Cutting受到Google三篇論文的啟發，組織了Hadoop項目組，開發了風靡一時的Hadoop大數據平臺。Hadoop的HDFS實際上是GFS的開源實現，HBase是BigTable的實現，Hadoop的MapReduce也是Google的MapReduce的開源實現。著名的Cassandra數據庫則是結合Dynamo和BigTable兩者的優勢實現的NoSQL數據庫。

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

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

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