白話分布式系統

一提起「分布式系統」，大家的第一感覺就是好高大上啊，深不可測，看各類大牛關於分布式系統的演講或者書籍，也大多是一臉懵逼。本文期望用淺顯易懂的大白話來就什麼是分布式系統、分布式系統有哪些優勢、分布式系統會面臨**挑戰、如何來設計分布式等方面的話題來展開討論。

關於這個定義，我們直觀的感受就是：

從程序角度看，兩個程式分別執行在兩個臺主機的程序上，它們相互協作最終完成同乙個服務（或者功能），那麼理論上這兩個程式所組成的系統，也可以稱作是「分布式系統」。

當然，這個兩個程式可以是不同的程式，也可以是相同的程式。如果是相同的程式，我們又可以稱之為「集群」。所謂集群，就是將相同的程式，通過不斷橫向擴充套件，以提高服務能力的方式。

「分布式系統」和「集群」的定義夠都簡單吧。

那麼，為啥我們要用分布式系統？

說起分布式系統，我們就不得不說下分布式系統的祖先——集中式系統。集中式系統跟分布式系統是完全相反的兩個概念。集中式系統就是把所有的程式、功能都集中到一台主機上，從而往外提供服務的方式。

集中式系統最容易理解了。比如，我們主機的pc電腦，或者手機，我們把各種軟體都安裝在一台機子上，當我需要什麼功能，我就從這台機子上去獲取。再比如，我們在學生時代做的課程設計或者開發時的小應用，我們把web伺服器、資料庫等都會安裝到一台電腦上。好處是，易於理解、方便維護，想要的東西我都放到了乙個地方，東西好找啊。當然弊端也是顯而易見的，如果這台機子崩了，或者硬碟壞了，那相當與整個系統就奔潰了，而且如果備份也是在這個硬碟上，那相當於招了滅頂之災。

所以巴菲特有個關於投資的名言，就是「不要把雞蛋放在乙個籃子裡」。對於系統而言也是如此。廠商的機子不可能永遠保證永遠不壞，我們也無法保證黑客不會來對我們的系統搞基，最為關鍵的是，我們自己無法保證自己的程式不會出bug。所以問題無法避免，錯誤也不可避免。我們只能雞蛋分散到不同的籃子裡，來減輕一鍋端的風險。這就是為什麼需要分布式系統的原因。

使用分布式系統的另外乙個理由是可擴充套件性。畢竟任何主機（哪怕是小型機、超級計算機）都會有效能的極限。而分布式系統可以通過不斷擴張主機的數量以實現橫向水平效能的擴充套件。大家也都了解到 google 的伺服器主機，大多是淘汰的二線機子拼湊的吧。

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

設計分布式系統時，經常需要考慮如下的挑戰：

設計分布式系統的本質就是「如何合理將乙個系統拆分成多個子系統部署到不同機器上」。所以首要考慮的問題是如何合理的將系統進行拆分。由於拆分後的各個子系統不可能孤立的存在，必然是通過網路進行連線互動，所以它們之間如何通訊變得尤為重要。當然在通訊過程要識別「敵我」，防止資訊在傳遞過程中被攔截和竄改，這就涉及到安全問題了。分布式系統要適應不斷增長的業務需求，那麼就需要考慮其擴充套件性。分布式系統還必須要保證可靠性和資料的一致性。

概況起來，在設計分布式系統時，應考慮以下幾個問題：

實際上，上面的每乙個問題都不是簡單的問題。還好，我們要感謝開源，讓這個時代的技術可以共享，讓實現複雜系統的成本越來越低。比如，我們在設計通訊時，我們可以採用面向訊息的中介軟體，比如apache activemq、rabbitmq、apache rocketmq、apache kafka等，也有類似與 google protocol buffer、thrift等 rpc框架。在設計分布式計算時，我們分布式計算可以採用 mapreduce、apache hadoop、apache spark 等。在大資料和分布式儲存方面，我們可以選擇 apache hbase、apache cassandra、memcached、redis、mongodb等。在分布式監控方面，常用的技術包括nagios、zabbix、consul、zookeeper等。

白話分布式系統

用大白話聊聊分布式系統

分布式系統

分布式系統

相關推薦