Java開發web架構設計原理與分散式系統淺析

引言

在信息產業高速發展的今天，企業間的競爭將更加激烈。隨著規模的不斷擴大和業務的不斷更新，企業迫切需求完整的分散式解決方案，用於管理複雜的異構環境，實現不同硬體設備、軟體系統、網路環境及資料庫系統之間的完整集成。

一丶 web分散式系統的設計原則

搭建和運營一個可伸縮的web站點或者應用程序意味著什麼？在原始層面上這僅僅是用戶通過互聯網連接到遠程資源-使系統變得可伸縮的部分是將資源、或者訪問的資源，分佈於多個伺服器上。

像生活中大多數事情一樣，當構建一個web服務時花時間提前做好計劃從長遠看來還是很有幫助的；了解一些注意事項和大網站背後的權衡原則可以在創建小型網站時做出更明智的決定。以下是一些影響大規模web系統設計的關鍵原則:

可用性:對於很多公司來說一個網站的正常運行時間是非常關鍵的聲譽和功能，像一些大型的在線零售系統，即使一分鐘的宕機都有可能導致數千或者數百萬美元的損失，因此設計系統的時時可用性和彈性的錯誤處理機制既是一個基本業務也是一個技術要求。高可用分散式系統需要仔細考慮關鍵組件的冗餘，分系統失敗后能快速修復，並且當問題出現時優雅型降級。

性能:網站的性能正在變成大多數站點考慮的一個重要的方面，網站的速度影響正常使用和用戶的滿意度，同樣影響搜索的排名，這也是影響網站收益和保留用戶的一個因素。因此，創建一個快速響應和低延遲的系統是非常關鍵的。

可靠性:一個系統需要具備可靠性，比如同一個數據的請求始終返回同樣的數據響應。如果數據改變或者被更新，那麼同樣的數據將返回一個新的數據。用戶需要知道一些東西被寫入系統或者被存儲到系統后，系統會保持不變並且可以在以後恢復到合適的位置。

可伸縮性:當談到任何大型的分散式系統時，規模大小隻是考慮的其中一個方面，同樣重要的是增強處理較大規模的負載性能所做的努力，這通常稱為系統的可伸縮性。可伸縮性可以代表系統很多不同的參數：額外流量的處理量，添加存儲容量的便意性，甚至事務的處理量。

可管理性:設計一個系統可以方便操作是另一個重要的考慮方面，系統的可管理性等同於操作的可伸縮性：維護和升級。可管理性：需要考慮的事情是當問題發生時方便診斷和了解問題，易於升級和修改，以及系統能簡單性的操作（即，例行的操作有沒有失敗和異常？）

成本:成本是一個重要的因素。很明顯這包含硬體和軟體成本，但同樣重要需要考慮的其他方面是部署和維護系統的成本。開發者構建系統花費的大量時間，運維部署時間，甚至培訓時間都需要考慮，成本是總體成本。

以上每個原則都為設計分散式web架構提供了基礎決策。然而，他們也能彼此互斥，例如要實現某個目標就要以另外的作為代價。一個基本的例子：選擇通過單純增加更多的伺服器（可擴展性）來增加地址容量，是以可管理性（你必須操作增加的伺服器）和成本（伺服器的價格）為代價的。

當設計任何的web應用程序時，考慮這些關鍵原則都是很重要的，即使得承認一個設計可能要犧牲它們之中的一個或者多個。

二丶基礎

當設計一個系統架構時，有一些東西是要考慮的：正確的部分是什麼，怎樣讓這些部分很好地融合在一起，以及好的折中方法是什麼。通常在系統架構需要之前就為它的可擴展性投資不是一個聰明的商業抉擇；然而，在設計上的深謀遠慮能在未來節省大量的時間和資源。

這部分關注點是幾乎所有大型web應用程序中心的一些核心因素：服務、冗餘、劃分和錯誤處理。每一個因素都包含了選擇和妥協，特別是上部分提到的設計原則。為了詳細的解析這些，最好是用一個例子來開始。

分散式存儲系統：

1. 結構化存儲

2. 非結構化存儲

3. 半結構化存儲

4. In-memory 存儲

除了這四個子方向之外，分散式存儲系統還有一系列的理論、演算法、技術作為支撐：例如Paxos,CAP,ConsistentHash,Timing(時鐘),2PC, 3PC等等，這些內容我們會在後面提到。現在，我們先來看看上述四個子方向大致都在幹些什麼。

結構化存儲（structured storagesystems）的歷史非常古老，典型的場景就是事務處理系統或者關係型資料庫（RDBMS）。傳統的結構化存儲都是從單機做起的，比如大家耳熟能詳的MySQL。有句話說：MySQL的成長史就是互聯網的成長史。這一點也不為過。除了 MySQL 之外，PostgreSQL也是近幾年來勢頭非常強勁的一個 RDBMS. 我們發現，傳統的結構化存儲系統強調的是：（1）結構化的數據（例如關係表）。（2）強一致性（例如，銀行系統，電商系統等場景）（3）隨機訪問（索引，增刪查改，SQL語言）。然而，正是由於這些性質和限制，結構化存儲系統的可擴展性通常都不是很好，這在一定程度上限制了結構化存儲在大數據環境下的表現。隨著摩爾定律面臨的瓶頸，傳統的單機關係型資料庫系統面臨著巨大的挑戰。不過真的沒辦法了嗎？在此我們先埋下一個伏筆：）

非結構化存儲 （no-structed storagesystems).和結構化存儲不同的是，非結構化存儲強調的是高可擴展性，典型的系統就是分散式文件系統。分散式文件系統也是一個古老的研究話題，比如70 年代的 Xerox Alto, 80 年代的 NFS, AFS, 90 年代 xFS等等。然而，這些早期的分散式文件系統只是起到了網路磁碟的作用, 其最大的問題就是不支持 容錯 （fault tolerance）和錯誤恢復 （fault recovery）。而 Google 在 2003 年 SOSP 上推出的 GFS (google filesystem) 則是做出了里程碑的一步，其開源實現對應為 HDFS. GFS 的主要思想包括：

（1）用 master 來管理 metadata。

（2）文件使用 64MB 的 chunks 來存儲，並且在不同的 server 上保存多個副本。

（3）自動容錯，自動錯誤恢復。

Google 設計 gfs 最初的目的是為了存儲海量的日誌文件以及網頁等文本信息，並且對其進行批量處理（例如配合mapreduce 為文檔建立倒排索引，計算網頁 PageRank等）。和結構化存儲系統相比，雖然分散式文件系統的可擴展性，吞吐率都非常好，但是幾乎無法支持隨機訪問（randomaccess）操作，通常只能進行文件進行追加（append）操作。而這樣的限制使得非結構化存儲系統很難面對那些低延時，實時性較強的應用。

半結構化存儲 （semi-structure storagesystems）的提出便是為了解決結非構化存儲系統隨機訪問性能差的問題。我們通常會聽到一些流行的名詞，比如NoSQL, Key-Value Store, 甚至包括對象存儲，例如 protobuf，thrift等等。這些都屬於半結構化存儲研究的領域，其中以 NoSQL 近幾年的發展勢頭尤為強勁。NoSQL系統既有分散式文件系統所具有的可擴展性，又有結構化存儲系統的隨機訪問能力 （例如隨機update, read操作），系統在設計時通常選擇簡單鍵值（K-V）進行存儲，拋棄了傳統 RDBMS 里複雜 SQL 查詢以及 ACID事務。這樣做可以換取系統最大的限度的可擴展性和靈活性。在 NoSQL 里比較有名系統包括：Google 的 Bigtable,Amazon 的 Dynamo, 以及開源界大名鼎鼎的 HBase，Cassandra 等. 通常這些 NoSQL系統底層都是基於比較成熟的存儲引擎，比如 Bigtable 就是基於 LevelDB ( jeff dean 寫的，非常好的 C++源碼教程) ，底層數據結構採用 LSM-Tree. 除了 LSM-Tree 之外 B-Tree（B+Tree）也是很成熟的存儲引擎數據結構。

In-memory 存儲。隨著業務的併發越來越高，存儲系統對低延遲的要求也越來越高。同時由於摩爾定律以及內存的價格不斷下降，基於內存的存儲系統也開始普及。 In-memory 存儲顧名思義就是將數據存儲在內存中,從而獲得讀寫的高性能。比較有名的系統包括 memcahed ，以及 Redis。 這些基於 K-V鍵值系統的主要目的是為基於磁碟的存儲系統做 cache。還有一些偏向於內存計算的系統，比如可以追溯到普林斯頓 Kai Lee教授早期的研究工作 distributed shared memory ( DSM )，斯坦福的 RamCloud，以及最近比較火的基於 lineage 技術的 tachyon (Alluxio) 項目（Spark生態系統子項目）等等。

NewSQL.我們在介紹結構化存儲時說到，單機 RDBMS系統在可擴展性上面臨著巨大的挑戰，然而 NoSQL 不能很好的支持關係模型。那是不是有一種系統能兼備 RDBMS 的特性（例如：完整的SQL 支持，ACID 事務支持），又能像 NoSQL 系統那樣具有強大的可擴展能力呢？ 2012 年 Google 在 OSDI上發表的 Spanner，以及 2013 年在 SIGMOD 發表的 F1, 讓業界第一次看到了關係模型和 NoSQL在超大規模數據中心上融合的可能性。不過由於這些系統都太過於黑科技了，沒有大公司支持應該是做不出來的。比如 Spanner里用了原子鐘這樣的黑科技來解決時鐘同步問題，打破光速傳輸的限制。在這裡只能對 google 表示膜拜。

我們在之前提到，分散式存儲系統有一系列的理論、演算法、技術作為支撐：例如Paxos,CAP,ConsistentHash,Timing(時鐘),2PC,3PC等等。那麼如何掌握好這些技術呢？以我個人的經驗，掌握這些內容一定要理解其對應的上下文。什麼意思呢？就是一定要去思考為什麼在當下環境需要某項技術，如果沒有這個技術用其它技術替代是否可行，而不是一味的陷入大量的細節之中。例如：如何掌握好Paxos? Paxos本質上來說是一個三階段提交，更 high level講是一個分散式鎖。理解paxos必須一步一步從最簡單的場景出發，比如從最簡單的 master-backup出發，發現不行，衍生出多數派讀寫，發現還是不行，再到 paxos. 之後再了解其變種，比如 fast paxos,multi-paxos. 同理為什麼需要 Consistent Hash, 我們可以先思考如果用簡單range partition劃分數據有什麼問題。再比如學習 2pc, 3pc 這樣的技術時，可以想想他們和paxos 有什麼關係，能否替代 paxos。

三丶分散式存儲系統分類

分散式存儲系統需要存儲的數據多種多樣，大致上可分為：非結構化數據，如文本文件、圖片、視頻和音頻等格式；結構化數據，一般存在關係資料庫中，可以用二維關係表結構來表示，模式與內容是分開的；半結構化數據，如HTML文檔，模式結構與內容是放在一起的。

不同的分散式存儲系統適合存儲不同的數據。

1丶分散式文件系統

互聯網應用需要存儲大量的圖片、照片和視頻等非結構化數據對象，這類數據以對象的形式組織，對象之間沒有關聯，這樣的數據一般稱為Blob(Binarylarge object)數據。

分散式文件系統適合存儲Blob對象，典型的如谷歌的GFS以及它的開源實現HDFS。在系統實現層面，分散式文件系統內部按照數據塊（chunk）來組織數據，每個數據塊的大小相同，每個數據塊可以包含我個Blob對象或者定長塊，一個大文件也可以拆分成多個數據塊。

2丶分散式鍵值系統

分散式鍵值系統存儲關係簡單的半結構化數據，它只提供主鍵的CRUD功能，如Dynamo、Redis和Memcache。從數據結構來看，分散式鍵值系統與傳統的哈希表比較類似，不同的是，分散式系統支持將數據分佈到集群中的多個存儲結點。分散式鍵值系統是分散式表格系統的一種簡化實現，一般用作緩存。一致性哈希是分散式鍵值系統中常用的數據分佈技術。

3丶分散式表格系統

分散式表格系統用於存儲關係較為複雜的半結構化數據，與分散式鍵值系統相比，分散式表格系統不僅僅支持簡單的CRUD操作，而且支持掃描某個主鍵範圍。分散式表格系統以表格為單位組織數據，每個表格包括很多行，通過主鍵標識一行，支持根據主鍵的CRUD功能以及範圍查找功能。

分散式表格系統借鑒了很多關係資料庫的技術，例如支持某種程度上的事務。典型的系統如Bigtable、HBase和DynamoDB。與分散式資料庫相比，分散式表格系統主要針對單張表格的操作，不支持一些特別複雜的操作，比如多表關聯、多表連接、嵌套子查詢。而且在分散式表格系統中，同一個表格的多個數據行也不要求包含相同類型的列，適合半結構化數據。分散式表格系統是一種很好的權衡，這類系統可以做到超大規模，而且支持較多的功能，但實現往往比較複雜。

4丶分散式資料庫

分散式資料庫一般是從單機關係資料庫擴展而來，用於存儲結構化數據。分散式資料庫採用二維表格組織數據，提供SQL關係查詢語言，支持多表關聯，嵌套子查詢等複雜操作，並提供資料庫事務以及併發控制。典型的如MySQL資料庫集群、AmazonRDS及Microsoft SQL Azure。

總結

以 上就是我對Java開發web架構設計原理與分散式系統淺析問題及其優化總結，分享給大家，希望大家可以了解什麼是Java開發web架構設計原理與分散式系統淺析問題及其優化。覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持

1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的

2、可以去百度搜索騰訊課堂圖靈學院的視頻來學習一下java架構實戰案例，還挺不錯的。

最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。

3丶想了解學習以上課程內容可加群：469717771 驗證碼（06 必過）