001-分佈式系統-概述、演進、技術組件

時間 2019-11-17

原文原文鏈接

1、什麼是分佈式系統

　　分佈式系統是由一組經過網絡進行通訊、爲了完成共同的任務而協調工做的計算機節點組成的系統。分佈式系統的出現是爲了用廉價的、普通的機器完成單個計算機沒法完成的計算、存儲任務。其目的是利用更多的機器，處理更多的數據。html

　　首先須要明確的是，只有當單個節點的處理能力沒法知足日益增加的計算、存儲任務的時候，且硬件的提高（加內存、加磁盤、使用更好的CPU）高昂到得不償失的時候，應用程序也不能進一步優化的時候，咱們才須要考慮分佈式系統。mysql

　　由於，分佈式系統要解決的問題自己就是和單機系統同樣的，而因爲分佈式系統多節點、經過網絡通訊的拓撲結構，會引入不少單機系統沒有的問題，爲了解決這些問題又會引入更多的機制、協議，帶來更多的問題。。。web

　　在不少文章中，主要講分佈式系統分爲分佈式計算（computation）與分佈式存儲（storage）。計算與存儲是相輔相成的，計算須要數據，要麼來自實時數據（流數據），要麼來自存儲的數據；而計算的結果也是須要存儲的。在操做系統中，對計算與存儲有很是詳盡的討論，分佈式系統只不過將這些理論推廣到多個節點罷了。redis

　　那麼分佈式系統怎麼將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對於計算，那麼就是對計算任務進行切換，每一個節點算一些，最終彙總就好了，這就是MapReduce的思想；對於存儲，更好理解一下，每一個節點存一部分數據就好了。當數據規模變大的時候，Partition是惟一的選擇，同時也會帶來一些好處：spring

　　（1）提高性能和併發，操做被分發到不一樣的分片，相互獨立sql

　　（2）提高系統的可用性，即便部分分片不能用，其餘分片不會受到影響docker

　　理想的狀況下，有分片就好了，但事實的狀況卻不大理想。緣由在於，分佈式系統中有大量的節點，且經過網絡通訊。單個節點的故障（進程crash、斷電、磁盤損壞）是個小几率事件，但整個系統的故障率會隨節點的增長而指數級增長，網絡通訊也可能出現斷網、高延遲的狀況。在這種必定會出現的「異常」狀況下，分佈式系統仍是須要繼續穩定的對外提供服務，即須要較強的容錯性。最簡單的辦法，就是冗餘或者複製集（Replication），即多個節點負責同一個任務，最爲常見的就是分佈式存儲中，多個節點複雜存儲同一份數據，以此加強可用性與可靠性。同時，Replication也會帶來性能的提高，好比數據的locality能夠減小用戶的等待時間。數據庫

　　下面這種來自Distributed systems for fun and profit 的圖形象生動說明了Partition與Replication是如何協做的。apache

　　Partition和Replication是解決分佈式系統問題的一記組合拳，不少具體的問題均可以用這個思路去解決。但這並非銀彈，每每是爲了解決一個問題，會引入更多的問題，好比爲了可用性與可靠性保證，引用了冗餘（複製集）。有了冗餘，各個副本間的一致性問題就變得很頭疼，一致性在系統的角度和用戶的角度又有不一樣的等級劃分。若是要保證強一致性，那麼會影響可用性與性能，在一些應用（好比電商、搜索）是難以接受的。若是是最終一致性，那麼就須要處理數據衝突的狀況。CAP、FLP這些理論告訴咱們，在分佈式系統中，沒有最佳的選擇，都是須要權衡，作出最合適的選擇。django

2、分佈式系統挑戰

分佈式系統須要大量機器協做，面臨諸多的挑戰：

　　第一，異構的機器與網絡：

　　　　分佈式系統中的機器，配置不同，其上運行的服務也可能由不一樣的語言、架構實現，所以處理能力也不同；節點間經過網絡鏈接，而不一樣網絡運營商提供的網絡的帶寬、延時、丟包率又不同。怎麼保證你們齊頭並進，共同完成目標，這四個不小的挑戰。

　　第二，廣泛的節點故障：

　　　　雖然單個節點的故障機率較低，但節點數目達到必定規模，出故障的機率就變高了。分佈式系統須要保證故障發生的時候，系統仍然是可用的，這就須要監控節點的狀態，在節點故障的狀況下將該節點負責的計算、存儲任務轉移到其餘節點

　　第三，不可靠的網絡：

　　　　節點間經過網絡通訊，而網絡是不可靠的。可能的網絡問題包括：網絡分割、延時、丟包、亂序。

　　　　相比單機過程調用，網絡通訊最讓人頭疼的是超時：節點A向節點B發出請求，在約定的時間內沒有收到節點B的響應，那麼B是否處理了請求，這個是不肯定的，這個不肯定會帶來諸多問題，最簡單的，是否要重試請求，節點B會不會屢次處理同一個請求。

　　總而言之，分佈式的挑戰來自不肯定性，不肯定計算機何時crash、斷電，不肯定磁盤何時損壞，不肯定每次網絡通訊要延遲多久，也不肯定通訊對端是否處理了發送的消息。而分佈式的規模放大了這個不肯定性，不肯定性是使人討厭的，因此有諸多的分佈式理論、協議來保證在這種不肯定性的狀況下，系統還能繼續正常工做。

　　並且，不少在實際系統中出現的問題，來源於設計時的盲目樂觀，以爲這個、那個應該不會出問題。Fallacies_of_distributed_computing頗有意思，介紹了分佈式系統新手可能的錯誤的假設：

The network is reliable.
Latency is zero.
Bandwidth is infinite.
The network is secure.
Topology doesn't change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.

　　劉傑在《分佈式系統原理介紹》中指出，處理這些異常的最佳原則是：在設計、推導、驗證分佈式系統的協議、流程時,最重要的工做之一就是思考在執行流程的每一個步驟時一旦發生各類異常的狀況下系統的處理方式及形成的影響。

3、分佈式系統特性與衡量標準

　　透明性：使用分佈式系統的用戶並不關心繫統是怎麼實現的，也不關心讀到的數據來自哪一個節點，對用戶而言，分佈式系統的最高境界是用戶根本感知不到這是一個分佈式系統，在《Distributed Systems Principles and Paradigms》一書中，做者是這麼說的：

A distributed system is a collection of independent computers that appears to its users as a single coherent system.　　

　　可擴展性：分佈式系統的根本目標就是爲了處理單個計算機沒法處理的任務，當任務增長的時候，分佈式系統的處理能力須要隨之增長。簡單來講，要比較方便的經過增長機器來應對數據量的增加，同時，當任務規模縮減的時候，能夠撤掉一些多餘的機器，達到動態伸縮的效果

　　可用性與可靠性：通常來講，分佈式系統是須要長時間甚至7*24小時提供服務的。可用性是指系統在各類狀況對外提供服務的能力，簡單來講，能夠經過不可用時間與正常服務時間的必知來衡量；而可靠性而是指計算結果正確、存儲的數據不丟失。

　　高性能：無論是單機仍是分佈式系統，你們都很是關注性能。不一樣的系統對性能的衡量指標是不一樣的，最多見的：高併發，單位時間內處理的任務越多越好；低延遲：每一個任務的平均時間越少越好。這個其實跟操做系統CPU的調度策略很像

　　一致性：分佈式系統爲了提升可用性可靠性，通常會引入冗餘（複製集）。那麼如何保證這些節點上的狀態一致，這就是分佈式系統不得不面對的一致性問題。一致性有不少等級，一致性越強，對用戶越友好，但會制約系統的可用性；一致性等級越低，用戶就須要兼容數據不一致的狀況，但系統的可用性、併發性很高不少。

4、分佈式系統下的組件、協議、理論

經過一次用戶請求

一、域名機器負載均衡
　　用戶使用Web、APP、SDK，經過HTTP、TCP鏈接到系統。在分佈式系統中，爲了高併發、高可用，通常都是多個節點提供相同的服務。那麼，第一個問題就是具體選擇哪一個節點來提供服務，這個就是負載均衡（load balance）。負載均衡的思想很簡單，但使用很是普遍，在分佈式系統、大型網站的方方面面都有使用，或者說，只要涉及到多個節點提供同質的服務，就須要負載均衡。
域名系統一般用途是將域名解析成IP地址（沒法解析到IP對應的端口）。開發申請域名的時候，確認是否須要分配VIP：
若須要：域名會解析到VIP上，而後經過負載均衡服務將請求分發到業務服務器上。
若不須要：域名將直接解析到服務器上，當服務器宕機，須要域名所屬人員經過dns自助服務將服務器從域名解析上刪除。
二、負載層緩存以及應用層緩存
　　經過負載均衡找到一個節點，接下來就是真正處理用戶的請求，請求有可能簡單，也有可能很複雜。簡單的請求，好比讀取數據，那麼極可能是有緩存的，即分佈式緩存，若是緩存沒有命中，那麼須要去數據庫拉取數據。對於複雜的請求，可能會調用到系統中其餘的服務。
三、系統內RPC、異步請求、併發處理
　　承上，假設服務A須要調用服務B的服務，首先兩個節點須要通訊，網絡通訊都是創建在TCP/IP協議的基礎上，可是，每一個應用都手寫socket是一件冗雜、低效的事情，所以須要應用層的封裝，所以有了HTTP、FTP等各類應用層協議。當系統越發複雜，提供大量的http接口也是一件困難的事情。所以，有了更進一步的抽象，那就是RPC（remote produce call），是的遠程調用就跟本地過程調用同樣方便，屏蔽了網絡通訊等諸多細節，增長新的接口也更加方便。
四、分佈式事務
　　一個請求可能包含諸多操做，即在服務A上作一些操做，而後在服務B上作另外一些操做。好比簡化版的網絡購物，在訂單服務上發貨，在帳戶服務上扣款。這兩個操做須要保證原子性，要麼都成功，要麼都不操做。這就涉及到分佈式事務的問題，分佈式事務是從應用層面保證一致性：某種守恆關係。
五、服務註冊與發現
　　上面說道一個請求包含多個操做，其實就是涉及到多個服務，分佈式系統中有大量的服務，每一個服務又是多個節點組成。那麼一個服務怎麼找到另外一個服務（的某個節點呢）？通訊是須要地址的，怎麼獲取這個地址，最簡單的辦法就是配置文件寫死，或者寫入到數據庫，但這些方法在節點數據巨大、節點動態增刪的時候都不大方便，這個時候就須要服務註冊與發現：提供服務的節點向一個協調中心註冊本身的地址，使用服務的節點去協調中心拉取地址。
　　從上能夠看見，協調中心提供了中心化的服務：以一組節點提供相似單點的服務，使用很是普遍，好比命令服務、分佈式鎖。協調中心最出名的就是chubby，zookeeper。
六、日誌、MQ消息
　　回到用戶請求這個點，請求操做會產生一些數據、日誌，一般爲信息，其餘一些系統可能會對這些消息感興趣，好比個性化推薦、監控等，這裏就抽象出了兩個概念，消息的生產者與消費者。那麼生產者怎麼講消息發送給消費者呢，RPC並非一個很好的選擇，由於RPC確定得指定消息發給誰，但實際的狀況是生產者並不清楚、也不關心誰會消費這個消息，這個時候消息隊列就出馬了。簡單來講，生產者只用往消息隊列裏面發就好了，隊列會將消息按主題（topic）分發給關注這個主題的消費者。消息隊列起到了異步處理、應用解耦的做用。
七、離線數據、實時數據
　　上面提到，用戶操做會產生一些數據，這些數據忠實記錄了用戶的操做習慣、喜愛，是各行各業最寶貴的財富。好比各類推薦、廣告投放、自動識別。這就催生了分佈式計算平臺，好比Hadoop，Storm等，用來處理這些海量的數據。
八、分佈式存儲
　　最後，用戶的操做完成以後，用戶的數據須要持久化，但數據量很大，大到按個節點沒法存儲，那麼這個時候就須要分佈式存儲：將數據進行劃分放在不一樣的節點上，同時，爲了防止數據的丟失，每一份數據會保存多分。傳統的關係型數據庫是單點存儲，爲了在應用層透明的狀況下分庫分表，會引用額外的代理層。而對於NoSql，通常自然支持分佈式。

5、分佈式架構的演進

一、初始階段架構

　　初始階段的小型系統應用程序、數據庫、文件等全部的資源都在一臺服務器上通俗稱爲LAMP

　　特徵：應用程序、數據庫、文件等全部的資源都在一臺服務器上。

二、應用服務和數據服務分離

　　隨着系統訪問量的再度增長，webserver機器的壓力在高峯期會上升到比較高，這個時候開始考慮增長一臺webserver

　　特徵：應用程序、數據庫、文件分別部署在獨立的資源上。

三、使用緩存改善性能

　　特徵：數據庫中訪問較集中的一小部分數據存儲在緩存服務器中，減小數據庫的訪問次數，下降數據庫的訪問壓力

　　描述：系統訪問特色遵循二八定律，即80%的業務訪問集中在20%的數據上。

　　緩存分爲本地緩存和遠程分佈式緩存，本地緩存訪問速度更快但緩存數據量有限，同時存在與應用程序爭用內存的狀況。

四、

使用應用服務器集羣

　　在作完分庫分表這些工做後，數據庫上的壓力已經降到比較低了，又開始過着天天看着訪問量暴增的幸福生活了，忽然有一天，發現系統的訪問又開始有變慢的趨勢了，這個時候首先查看數據庫，壓力一切正常，以後查看webserver，發現apache阻塞了不少的請求，而應用服務器對每一個請求也是比較快的，看來是請求數過高致使須要排隊等待，響應速度變慢

　　特徵：多臺服務器經過負載均衡同時向外部提供服務，解決單臺服務器處理能力和存儲空間上限的問題。
　　描述：使用集羣是系統解決高併發、海量數據問題的經常使用手段。經過向集羣中追加資源，提高系統的併發處理能力，使得服務器的負載壓力再也不成爲整個系統的瓶頸。

五、數據庫讀寫分離

　　特徵：多臺服務器經過負載均衡同時向外部提供服務，解決單臺服務器處理能力和存儲空間上限的問題。
　　描述：使用集羣是系統解決高併發、海量數據問題的經常使用手段。經過向集羣中追加資源，使得服務器的負載壓力不在成爲整個系統的瓶頸。

六、反向代理和CDN加速

　　特徵：採用CDN和反向代理加快系統的訪問速度。
　　描述：爲了應付複雜的網絡環境和不一樣地區用戶的訪問，經過CDN和反向代理加快用戶訪問的速度，同時減輕後端服務器的負載壓力。CDN與反向代理的基本原理都是緩存。

七、分佈式文件系統和分佈式數據庫

　　分庫後查詢仍然會有些慢，因而按照分庫的思想開始作分表的工做
　　特徵：數據庫採用分佈式數據庫，文件系統採用分佈式文件系統。
　　描述：任何強大的單一服務器都知足不了大型系統持續增加的業務需求，數據庫讀寫分離隨着業務的發展最終也將沒法知足需求，須要使用分佈式數據庫及分佈式文件系統來支撐。
　　分佈式數據庫是系統數據庫拆分的最後方法，只有在單表數據規模很是龐大的時候才使用，更經常使用的數據庫拆分手段是業務分庫，將不一樣的業務數據庫部署在不一樣的物理服務器上。

八、使用NoSQL和搜索引擎

　　特徵：系統引入NoSQL數據庫及搜索引擎。
　　描述：隨着業務愈來愈複雜，對數據存儲和檢索的需求也愈來愈複雜，系統須要採用一些非關係型數據庫如NoSQL和分數據庫查詢技術如搜索引擎。應用服務器經過統一數據訪問模塊訪問各類數據，減輕應用程序管理諸多數據源的麻煩。

九、業務拆分

　　特徵：系統上按照業務進行拆分改造，應用服務器按照業務區分進行分別部署。
　　描述：爲了應對日益複雜的業務場景，一般使用分而治之的手段將整個系統業務分紅不一樣的產品線，應用之間經過超連接創建關係，也能夠經過消息隊列進行數據分發，固然更多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統。
　　　　縱向拆分：將一個大應用拆分爲多個小應用，若是新業務較爲獨立，那麼就直接將其設計部署爲一個獨立的Web應用系統
　　　　　　縱向拆分相對較爲簡單，經過梳理業務，將較少相關的業務剝離便可。
　　　　橫向拆分：將複用的業務拆分出來，獨立部署爲分佈式服務，新增業務只須要調用這些分佈式服務
　　　　　　橫向拆分須要識別可複用的業務，設計服務接口，規範服務依賴關係。

十、分佈式服務

　　特徵：公共的應用模塊被提取出來，部署在分佈式服務器上供應用服務器調用。

　　描述：隨着業務越拆越小，應用系統總體複雜程度呈指數級上升，因爲全部應用要和全部數據庫系統鏈接，最終致使數據庫鏈接資源不足，拒絕服務。

簡化的分佈式系統架構圖

6、組件