分散式系統
分散式系統從當初的CORBA 到EJB，Web和SOA，從叢集到現在的NoSQL 雲端計算和大資料Hadoop等分散式系統，橫向水平擴充套件Scala out/in是分散式系統設計的一個特點，可靠性 容錯性是兩個質量指標。
什麼是分散式系統？
- 一大批伺服器組成一個集合，對於使用者來說仍然是一個整體連貫系統。
- A. Tanenbaum定義：分散式網路的計算機中的元件之間協調動作是通過訊息進行通訊。
- G. Coulouris定義：當你知道有一臺電腦崩潰，但是你的軟體執行從來不會停止。
- Leslie Lamport定義：分散式系統是這樣系統：旨在支援應用程式和服務的開發，可以利用物理架構 由多個自治的處理元素，不共享主記憶體，但通過網路傳送非同步訊息合作。
- 與分層應用區別：分層的應用程式（例如，3層）是 劃分應用程式邏輯，是一種邏輯分層，而不是物理，而分散式系統DS是物理分層，和實際部署有關。
與傳統集中式系統相比：
集中式系統是一種Scale out/in，縱向擴充套件，要麼向上升級伺服器到中大型機，要麼升級多核，增加CPU核數，集中式縱向擴充套件適合計算聚合度比較高的資料，而分散式適合計算鬆散資料，非結構化或半結構化資料。無論採取哪種擴充套件伸縮方案，需要根據業務資料特點而定。
任何分散式系統總是需要完成兩個任務：計算和儲存。計算和儲存分離是分散式系統的重要特徵。而通常在集中式或單機系統中，這兩者是可能結合在一起，比如通過一個SQL語句實現查詢後排序，查詢是從儲存中獲得資料，排序是屬於計算，因此這個SQL語句實際是將計算和儲存耦合在一起。在應對大資料或大併發的情況下，這種方便的捆綁帶來效能問題，而分散式計算和分散式儲存雖然帶來複雜性，但是也為系統的處理能力開啟了上升擴充的空間。
分散式系統特點：
- 併發性：共享資源，採取ACID或Base原則，見：CAP定理。
- 分散式系統設計遵循CAP定理， CAP是：Consistency(一致性), Availability(可用性), 和 Partition tolerance(分割槽容錯性) 可靠性 簡稱，CAP定理認為，CAP三種之中，只能同時滿足其中兩種。
- 可擴充套件性Scalable是重要特點，通過擴充套件能夠獲得高效能 高吞吐量 低延遲Latency。
- 可靠性/可用性:故障發現和處理以及恢復 容錯處理。在一個正常運作系統中存在一個時間比例的條件。 如果一個使用者不能訪問系統比例增大，它被認為是不可用。可用性公式：
- Availability = uptime / (uptime + downtime)
- 容錯failover是指一個系統在錯誤發生的情況下，仍然一切執行正常。表示這個系統是寬容錯誤的。
- 訊息處理: 具體產品有：RabbitMQ ZeroMQ Netty等等。
- 異構性： 不同作業系統 硬體 程式語言 開發者，中介軟體是一種解決方案。
- .安全性：授權認證 SSO單點登入 Oauth等等。
定位命令：
- 標識資源 URLs
- 命名服務Naming services
- 定位尋找Lookup
- 主要見SOA中的服務查詢。如Zookeeper實現服務查詢。
透明性：
- 訪問透明度： 使用相同的操作本地和遠端資源
- 位置透明：訪問資源無需知道其物理或網路位置
- 併發透明度：多個流程可以同時執行訪問使用共享資源，當不能干擾堵塞 它們的處理流程
- 複製透明性： 資源的多個例項可以被用來複制以提高可靠性和效能，但無需由使用者編制專門的應用程式來實現。
- 故障透明度：出現軟體硬體故障時，使使用者和應用方案能繼續完成他們的任務不受影響。
- 移動透明度：允許在 系統存在移動的資源和客戶。
- 效能透明度：允許系統重新配置以 提高效能負荷變化
- 縮放透明度：在應用程式結構沒有變化的情況下能夠在規模上擴充套件或伸縮系統，以提高吞吐量處理能力。
分散式系統的挑戰
分散式系統是難於理解、設計、構建 和管理的，他們將比單個機器成倍還要多的變數引入到設計中，使應用程式的根源問題更難發現。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理論？
分散式系統的設計技巧：分割槽和複製
對於一個資料集有兩種設計方式：
- 分割槽：它可以被分割在多個節點，以允許更多的並行處理。有更好的效能，但是容錯能力低。
- 複製：它也可以被複制或快取在不同的節點上，以減少在客戶端和伺服器之間的距離，更強的容錯能力，但是複製消耗效能。關鍵是複製資料之間的一致性。弱一致性提供更低的延遲和更高的可用性。
分散式系統的設計技巧：時鐘和順序
分散式系統針對計算和儲存的策略是不同的，對於資料的儲存主要是分割槽和複製，而對於計算主要是保證事件的順序，因為分散式計算任務是由事件驅動的，比如Storm等等。那麼事件的順序代表了業務邏輯的順序，事件有時是樹形巢狀事件，可靠性就是必須保證一個樹形集合所有事件都得到網站執行是一個事務原子的