分佈式架構之美~

1、前言

​　　咱們都知道，當今不管在BAT這樣的大公司，仍是各類各樣的小公司，甚至是傳統行業剛轉互聯網的企業都開始使用分佈式架構，那麼什麼叫分佈式架構呢？分佈式架構有什麼好處呢？分佈式架構通過了怎樣的發展呢？是哪家企業開啓了分佈式架構的時代呢？讀完本文，你就會獲得這些答案，下面讓咱們一塊兒來開啓分佈式概述的奇妙之旅吧！

2、分佈式架構的發展歷史

​　　1946年2.14日，那是一個浪漫的情人節 , 世界上第一臺電子數字計算機在美國賓夕法尼亞大學誕生了，她的名字叫ENIAC。這臺計算機佔地170平米、重達 30 噸，每秒能夠進行 5000 次加法運算。

​　　第一臺電子計算機誕生之後，就意味着一個突飛猛進的 IT 時代到來了。單臺計算機的性能不斷獲得提高，從最先的 8 位 CPU 到如今的 64 位 CPU;從早期的 MB 級內存到如今的 GB 級別內存;從慢速的機械存儲到如今的固態 SSD 硬盤存儲。

​　　ENIAC 以後，電子計算機就進入了 IBM 主導的大型機時代。1964 年 4 月 7 日，在吉恩.阿姆達爾(IBM 大型機之父, 被認爲是有史以來最偉大的計算機設計師之一)的帶領下，耗費 50 億美圓，歷時三年，第一臺 IBM 大型機 SYSTEM/360 誕生了。這使得 IBM 在 20 世紀 50~60 年代統治着整個大型計算機工業，奠基了 IBM 計算機帝國的基礎。IBM 大型機曾支撐美國航天登月計劃，IBM 主機一直服務於金融等核心行業的關鍵領域。因爲超強的計算能力和高可靠性，即便在 X86 和雲計算高速發展的背景下,IBM 的大型機依然緊緊佔據着必定的高端市場份額。

​ 20 世紀 80 年代，在大型機霸權的時代下，計算機的架構同時向兩個方向發展：

• 以 CISC (微處理器執行的計算機語言指令集) CPU 爲架構的面向我的、價格便宜的PC。
• 以 RISC (精簡指令集計算機) CPU 爲架構的面向企業、價格昂貴的小型 UNIX 服務器。

3、分佈式架構發展的里程碑

​　　大型主機憑藉着大型機超強的計算和 I/O 處理能力、安全性、 穩定性等，在很長一段時間內，大型機引領着計算機行業及商業計算領域的發展。而集中式的計算機系統架構也漸漸成爲了主流。可是隨着社會的發展，這種架構愈來愈難以適應企業的需求，好比說：

• 大型主機複雜性高，培養一個可以熟練運維大型主機的人成本很高。
• 大型主機很貴，通常只有土豪機構(政府、電信、金融)才能用得起。
• 會有單點問題，一旦大型主機出現故障，那整個系統就將處於不可用的狀態。而對於大型機的使用機構來講，這種不可用致使的損失是很是具大的。
• 因爲科技的進步、技術的發展，PC 機性能獲得了不斷提高，因此不少企業放棄大型機改用小型機及普通 PC 來搭建系統架構。

阿里巴巴發起的"去 IOE"運動開啓新時代

​　　IOE 指的是 IBM 小型機、Oracle 數據庫、EMC 的高端存儲。阿里巴巴2009 年「去 IOE」戰略技術總監透露，截止到 2013 年 5 月 17 日阿里巴巴最後一臺 IBM 小型機在支付寶下線。

爲何要去 IOE?

​　　隨着業務的快速發展，阿里巴巴業務量和數據量呈爆發性增加，傳統集中式 Oracle 數據庫架構在系統的擴展性方面遭遇到了瓶頸。 傳統的商業數據庫軟件(Oracle,DB2)多以集中式架構爲主， 那麼這些傳統數據庫軟件的最大特色就是將全部的數據都集中在 一個數據庫中，只能依靠大型高端設備來提供高處理能力和擴展性。 集中式數據庫的擴展性主要採用向上擴展(Scale up)的方式， 經過增長 CPU、內存、磁盤等方式提升系統處理能力。這種集中式數據庫的架構，使得數據庫成爲了整個系統的瓶頸，已經愈來愈不能適應海量數據對計算能力的要求。

4、分佈式系統的意義

之因此要發展分佈式系統架構，是由於單機系統存在着以下諸多缺點等待被解決：

1. 升級單機處理能力的性價比愈來愈低

   咱們知道單機的處理能力主要依靠 CPU、內存、磁盤。經過升級硬件來這種垂直擴展的方式來提高性能，成本會愈來愈高。性價比會愈來愈低。

2. 單機處理能力存在瓶頸

   而且單機處理能力存在瓶頸，CPU、內存、磁盤都會有本身的性能瓶頸， 就算你是土豪不惜成本去提高硬件，可是硬件的發展速度和性能也仍是有限制的。

3. 穩定性和可用性這兩個指標很難達到

4. 最後就是單機系統存在可用性和穩定性的問題，這兩個指標又是咱們亟待要去解決的問題。

5、分佈式架構的常見概念

1.集羣

​　　小張開了一家小飯店，剛開始的時候店裏只有一個廚師，切菜洗菜備料炒菜全乾。後來因爲飯香甜可口，人流量愈來愈多了，一個廚師忙不過來了，小張又請了兩個廚師，那麼這時候三個廚師炒同樣的菜，作相同的切菜洗菜備料炒菜等工做，那這三個廚師的關係是集羣。也就意味着來一個顧客，只有其中的一個廚師會爲這個顧客服務。

2.分佈式

​　　又通過一段時間，店裏的生意更加火爆了，小張爲了讓廚師們能專心炒菜，把菜作到極致，又請了個配菜師負責切菜、備菜、備料，那麼廚師和配菜師的關係是分佈式，後來一個配菜師也忙不過來了，小張就又請了兩個配菜師，三個配菜師關係也是集羣。

3.節點

​　　節點是指一個能夠獨立按照分佈式協議完成一組邏輯的程序個體。在具體的項目中，一個節點表示的是一個操做系統上的進程。 那這裏的每個配菜師和廚師都是一個節點。

4.副本機制

​　　副本(replica/copy)是指在分佈式系統中爲數據或服務提供的冗餘。 數據副本指在不一樣的節點上持久化同一份數據，當某一個節點出現數據丟失時，能夠從副本上恢復數據。數據副本是分佈式系統中解決數據丟失問題的惟一手段。 服務副本表示多個節點提供相同的服務，經過主從關係來實現服務高可用的方案。

5.中間件

​　　中間件位於操做系統提供的服務以外，但又不屬於應用，他是位於應用和系統層之間的、爲開發者方便的處理通訊、輸入輸出的一類軟件，可以讓用戶只關心本身應用的部分。

6、分佈式領域中馮諾依曼模型的變化

　　上圖是經典理論-馮.諾依曼體系，計算機硬件由運算器、 控制器、存儲器、輸入設備、輸出設備五大部分組成。無論架構怎麼變化，計算機仍沒有跳出該體系的範疇。

• 輸入設備的變化

  分佈式系統架構中，輸入設備能夠分兩類：第一類是互相鏈接的多個節點，在接收其餘節點傳來的信息做爲該節點的輸入;另外一種就是傳統意義上的人機交互的輸入設備了。

• 輸出設備的變化

  分佈式系統架構中，輸出也分兩類，一種是系統中的節點向其餘節點傳輸信息時，該節點能夠看做是輸出設備;另外一種就是傳統意義上的人際交互的輸出設備，好比用戶的終端。

• 控制器的變化

  在單機中，控制器指的是 CPU 中的控制器，在分佈式系統中，控制器主要的做用是協調或控制節點之間的動做和行爲; 好比硬件負載均衡器;LVS 軟負載;規則服務器等等。

• 運算器

  分佈式系統中，運算器是由多個節點來組成的。運用多個節點的計算能力來協同完成整個計算任務。

• 存儲器

  分佈式系統中，咱們須要把承擔存儲功能的多個節點組織在一塊兒， 組成一個總體的存儲器;好比數據庫、redis(key-value 存儲) 。

7、分佈式系統的難點

　　毫無疑問，分佈式系統對於集中式系統而言，在實現上會更加 複雜。分佈式系統將會是更難理解、設計、構建 和管理的，同 時意味着應用程序的根源問題更難發現。

• 三態

  在集中式架構中，調用一個接口返回的結果只有兩種， 成功或失敗。可是在分佈式架構中，會出現「超時」這個狀態。

• 分佈式事務

  ​ 這實際上是一個老生常談的問題，咱們都知道事務就是一系列操做的原子性保證，在單機的狀況下，咱們可以依靠本機的數據庫鏈接和組件很輕易的作到事務控制，但在分佈式架構下，業務原子性操做極可能是跨服務的，這樣就會致使分佈式事務。好比 A 、B 操做分別是在不一樣服務下的同一個事務內的操做，A 調用 B，若是A能夠清楚的知道 B 是否成功提交從而控制自身提交仍是回滾，但咱們知道在分佈式系統調用中會出現一個新狀 態就是超時，就是 A 並沒有法知道 B 是成功仍是失敗，這個時候 A 是提交本地事務仍是執行回滾呢？這實際上是一個很難的問題，若是要強行保證事務一致性，能夠採起分佈式鎖，但那樣會增長系統複雜度並且會增大系統的開銷，並且事務跨越的服務越多， 消耗的資源越大，性能越低，那麼最好的解決方案就是避免分佈式事務。 還有一種解決方案就是重試機制，可是重試若是不是查詢接口， 久必然涉及到數據庫的變動，若是第一次調用成功可是沒返回成功結果，那調用方第二次調用對調用方來講依然是重試，可是此時對於被調用方來講是重複調用，例如 A 向 B 轉帳，A-100，B + 100，這樣會致使 A 扣了 100，而 B 增長 200。這樣的結果並非咱們指望的，所以需在要寫入的接口作冪等設計(屢次調用和單次調用是同樣的效果)。一般能夠設置一個惟一鍵，在寫入的時候查詢是否已經存在，避免重複寫入。可是冪等設計的一 個前提就是服務高可用，不然不管怎麼重試都不能調用返回一個明確的結果,那調用方會一直等待，雖然能夠限制重試的次數， 可是這已經進入異常狀態了，甚至到了極端狀況還須要人肉補償處理。其實根據 CAP 和 BASE 理論，不可能在高可用分佈式狀況下作到一致性，通常都是最終一致性保證。

• 負載均衡

  ​ 爲了達到服務高可用，每一個服務至少是部署兩臺機器，由於互聯網公司通常使用可靠性不是很高的普通機器， 長期運行宕機機率很高，因此兩臺機器可以大大下降服務不可用的可能性，而大型項目每每會採用十幾臺甚至上百臺來部署一 個服務，這不只是保證服務的高可用，更是爲了提高服務的 QPS， 可是這樣又帶來一個問題，一個請求過來到底路由到哪臺機器呢？ 路由算法不少，有 DNS 路由，若是 session 在本機，還會根據用戶 id 或則 cookie 等信息路由到固定的機器，固然如今應用服務器爲了擴展的方便都會設計爲無狀態的，session 會保存到專有的 session 服務器，因此通常不會涉及到拿不到 session 問 題。那路由規則是隨機獲取麼？這是一個方法，可是據我所知， 實際狀況確定比這個複雜得多，在必定範圍內隨機，可是在大範圍也會分爲不少個域，好比若是爲了保證異地多活的多機房， 誇機房調用的開銷太大，確定會優先選擇同機房的服務，這個 要參考具體的機器分佈來考慮。

• 一致性

  數據被分散或者複製到不一樣的機器上，如何保證各臺主機之間的數據一致性將成爲一個難點。

• 故障的獨立性

  ​ 分佈式系統由多個節點組成，整個分佈式系統徹底出問題的機率是存在的，可是在實踐中出現更多的是某個節點出問題，其餘節點都沒問題。這種狀況下咱們實現分佈式系統時須要考慮得更加全面些。

8、總結

​　　經過本文分佈式系統的概述，咱們就對分佈式有了一個很直觀的瞭解，裏面涉及到的技術仍是蠻多的，後面的文章中，咱們一點點的來啃這些硬骨頭。爲咱們的成長加油點贊吧~ 下篇博文咱們來聊分佈式架構的演進過程怎麼樣？評論區等你。