Java程序員進階—分佈式系統架構

分佈式系統

　　分佈式系統從當初的CORBA 到EJB，Web和SOA，從集羣到如今的NoSQL 雲計算和大數據Hadoop等分佈式系統，橫向水平擴展Scala out/in是分佈式系統設計的一個特色，可靠性 容錯性是兩個質量指標。

什麼是分佈式系統？

　　一大批服務器組成一個集合，對於用戶來講仍然是一個總體連貫系統。

　　A. Tanenbaum定義：分佈式網絡的計算機中的組件之間協調動做是經過消息進行通信。

　　G. Coulouris定義：當你知道有一臺電腦崩潰，可是你的軟件運行歷來不會中止。

　　Leslie Lamport定義：分佈式系統是這樣系統：旨在支持應用程序和服務的開發，能夠利用物理架構 由多個自治的處理元素，不共享主內存，但經過網絡發送異步消息合做。

　　與分層應用區別：分層的應用程序（例如，3層）是 劃分應用程序邏輯，是一種邏輯分層，而不是物理，而分佈式系統DS是物理分層，和實際部署有關。

與傳統集中式系統相比：

　　集中式系統是一種Scale out/in，縱向擴展，要麼向上升級服務器到中大型機，要麼升級多核，增長CPU核數，集中式縱向擴展適合計算聚合度比較高的數據，而分佈式適合計算鬆散數據，非結構化或半結構化數據。不管採起哪一種擴展伸縮方案，須要根據業務數據特色而定。

　　任何分佈式系統老是須要完成兩個任務：計算和存儲。計算和存儲分離是分佈式系統的重要特徵。而一般在集中式或單機系統中，這二者是可能結合在一塊兒，好比經過一個SQL語句實現查詢後排序，查詢是從存儲中得到數據，排序是屬於計算，所以這個SQL語句實際是將計算和存儲耦合在一塊兒。在應對大數據或大併發的狀況下，這種方便的捆綁帶來性能問題，而分佈式計算和分佈式存儲雖然帶來複雜性，可是也爲系統的處理能力打開了上升拓展的空間。

分佈式系統特色：

1. 併發性：共享資源，採起ACID或Base原則，見：CAP定理。
   分佈式系統設計遵循CAP定理， CAP是：Consistency(一致性), Availability(可用性), 和 Partition tolerance(分區容錯性) 可靠性 簡稱，CAP定理認爲，CAP三種之中，只能同時知足其中兩種。
   
   
2. 可擴展性Scalable是重要特色，經過擴展可以得到高性能 高吞吐量 低延遲Latency。
   
   
3. 可靠性/可用性:故障發現和處理以及恢復 容錯處理。在一個正常運做系統中存在一個時間比例的條件。 若是一個用戶不能訪問系統比例增大，它被認爲是不可用。可用性公式：
   Availability = uptime / (uptime + downtime)
   容錯failover是指一個系統在錯誤發生的狀況下，仍然一切運行正常。表示這個系統是寬容錯誤的。
   
4. 消息處理: 具體產品有：RabbitMQ ZeroMQ Netty等等。
   
5. 異構性： 不一樣操做系統 硬件 程序語言 開發者，中間件是一種解決方案。
   
6. .安全性：受權認證 SSO單點登陸 Oauth等等。
   
7. 定位命令：
   標識資源 URLs
   命名服務Naming services
   定位尋找Lookup
   主要見SOA中的服務查找。如Zookeeper實現服務查找。
   
8. .透明性：
   訪問透明度： 使用相同的操做本地和遠程資源
   位置透明：訪問資源無需知道其物理或網絡位置
   併發透明度：多個流程能夠同時運行訪問使用共享資源，當不能干擾堵塞 它們的處理流程
   複製透明性： 資源的多個實例能夠被用來複制以提升可靠性和性能，但無需由用戶編制專門的應用程序來實現。
   故障透明度：出現軟件硬件故障時，使用戶和應用方案能繼續完成他們的任務不受影響。
   移動透明度：容許在 系統存在移動的資源和客戶。
   性能透明度：容許系統從新配置以 提升性能負荷變化
   縮放透明度：在應用程序結構沒有變化的狀況下可以在規模上擴展或伸縮系統，以提升吞吐量處理能力。　　

分佈式系統的挑戰

　　分佈式系統是難於理解、設計、構建 和管理的，他們將比單個機器成倍還要多的變量引入到設計中，使應用程序的根源問題更難發現。SLA(服務水平協議)是衡量停機和/或性能降低的標準，大多數現代應用程序有一個指望的彈性SLA水平，一般按"9"的數量增長(如,每個月99.9或99.99%可用性)。每一個額外的9變得愈來愈難實現。

　　讓事情更加複雜的是，咱們愈來愈常見地看到：分佈式系統的故障表現爲間歇性錯誤或性能降低(俗稱的限電)。這些失敗模式耗費更多時間來診斷。例如，Joyent經營一些分佈式系統做爲其雲計算基礎設施的一部分。在這樣一個系統中，包括高可用性、分佈式的鍵/值存儲，Joyent最近經歷了瞬態應用程序超時。對於大多數用戶系統運行正常，其反應延遲也是在SLA範圍內。然而，有百分之5 - 10的請求超出了一個預約義的程序超時。這樣的失敗問題並無重如今開發或測試環境中，他們常常會"消失"幾分鐘到幾小時。排除這個故障的根本是須要大量數據存儲的系統分析。

　　這些系統包括：數據存儲API(node . js)，RDBMS(關係數據庫管理系統)和由系統內部使用(PostgreSQL)以及操做系統和終端用戶應用程序依賴於的鍵/值系統。最終，致使過分的根本問題是在應用程序語義鎖定，但肯定以前須要至關大的數據收集和相關性工做，包括工程師耗費大量工做時間以及學習不一樣領域的專業知識。

　　分佈式系統由兩個物理因素的限制：

• 節點的數量（可以增長所需的存儲和計算能力）
• 節點之間的距離（信息的傳送距離，最好以光速）

　　這兩個約束致使下面值得挑戰的狀況發生：

• 獨立節點隨着數目的增長髮生故障的機率增長（減小可用的和管理成本增長）
• 獨立節點隨着數目增長可能會增長節點之間的通訊的消耗（隨着規模的增大性能下降）
• 地理距離的增長提升遙遠的節點之間的通訊延遲（減小某些操做的性能）

如何架構分佈式系統

　　適用於分佈式系統架構的最多見的一個術語是SOA(面向服務架構)。SOA能夠避免不愉快的CORBA(公共對象請求代理體系結構)，經過WS - *標準，一套鬆散耦合的Web服務完成獨立的小功能，而且彼此獨立，他們是一個有彈性的分佈式系統的基礎。對比上一代，服務是新流程，他們是正確的抽象層次系統中的離散功能。

　　構建面向服務架構的第一步是肯定每一個函數功能如何構成總體業務目標，將這些業務映射到離散的服務，且具備獨立的斷層邊界、擴展性和數據負載量。肯定爲每一個服務時，您必須考慮下列事項：

• 地理. 系統是全球仍是地區單獨運行？
• 數據隔離. 這個系統提供一個單個或多租戶模型？
• SLAs. 可用性 延遲 吞吐量 一致性和冗餘性都必須定義。
• 安全. IAAA (身份identity, 驗證authentication, 受權authorization, 和 審覈audit), 數據的保密性和隱私性都必須考慮
• 可用性跟蹤. 瞭解系統的使用是天天系統的平常運做，如容量規劃。也可能用於執行計費系統的使用和/或治理(配額/速度限制)。
• 部署和配置管理. 系統是如何部署更新?

分佈式系統的模型抽象

• 系統模型（異步/同步）
• 失效模型（崩潰故障，分區）
• 一致性模型（強，最終）

　　一般，咱們最熟悉的模式（例如，一個分佈式系統上實現共享內存抽象）是太昂貴了。一個分佈式系統越弱勢越能保證其中元素有更大的行動自由，從而煥發潛在的更大的性能- 但它也可能致使很難管理。這就須要咱們有極大智慧，不能以犧牲性能換來管理的方便性。所以，試圖將分佈式系統當作一個統一的單一系統的思惟會阻礙分佈式系統的擴展。

　　分佈式系統遵循CAP定律，在高一致性 高可用性和分區容錯性之間三選二：

　　

• CA (consistency高一致性 + availability高可用性). 使用2pc 兩階段事務提交來保證。其缺點沒法實現分區容錯性，一旦某個操做失敗，整個系統就出錯，沒法容忍(水至清則無魚)。
• CP (consistency高一致性 + partition tolerance分區容錯性). 使用Paxos來保證，可用性下降。
• AP (availability高可用性 + partition tolerance分區容錯性). 使用Gossip等實現最終一致性，如Dynamo.
• 如何正確理解CAP理論？
  

分佈式系統的設計技巧：分區和複製

　　對於一個數據集有兩種設計方式：

1. 分區：它能夠被分割在多個節點，以容許更多的並行處理。有更好的性能，可是容錯能力低。
2. 複製：它也能夠被複制或緩存在不一樣的節點上，以減小在客戶端和服務器之間的距離，更強的容錯能力，可是複製消耗性能。關鍵是複製數據之間的一致性。弱一致性提供更低的延遲和更高的可用性。

分佈式系統的設計技巧：時鐘和順序

　　分佈式系統針對計算和存儲的策略是不一樣的，對於數據的存儲主要是分區和複製，而對於計算主要是保證事件的順序，由於分佈式計算任務是由事件驅動的，好比Storm等等。那麼事件的順序表明了業務邏輯的順序，事件有時是樹形嵌套事件，可靠性就是必須保證一個樹形集合全部事件都獲得網站執行是一個事務原子的。