本文轉載於公眾號  一名叫大蕉的程式設計師  

今天小蕉跟大夥一起聊聊分散式系統的架構的套路。在開始說套路之前，大家先思考一個問題，為什麼要進行分散式架構？

大多數的開發者大多數的系統可能從來沒接觸過分散式系統，也根本沒必要進行分散式系統架構，為什麼？因為在訪問量或者QPS沒有達到單臺機器的效能瓶頸的時候，根本沒必要進行分散式架構。那如果業務量上來了，一般會怎麼解決呢？

首先考慮的就是機器升級。機器配置的垂直擴充套件，首先要找到當前效能的瓶頸點，是CPU，是記憶體，是硬碟，還是頻寬。砸錢加CPU，砸錢換SSD硬碟，砸錢換1T記憶體，這通常是解決問題最直接也最高效的方法。頻寬不夠？加頻寬，1G不夠用100G。CPU 8核不夠？搞32核96核。這是絕大多數公司能思考到的第一個方案，也是最高效最快最安全的方法，立竿見影。

其次就是系統拆分，將所提供服務的主流程以及支線流程梳理出來，按照流程進行系統拆分。如同一棵樹，核心業務作為主幹流程，其他系統按照需要進行拆分，如同樹的開枝散葉。所採取的方式有這麼一些，按前後端進行拆分，按照領域拆分，按團隊拆分，當然通常來說這些拆分基本都要跟著組織架構走。

再不行就進行技術升級，更換更加高效或者場景適合的技術。比如從 Oracle 更換到HBase。從A資料庫連線池更換到B資料庫連線池。技術的變革對於業務量的支援也是非常巨大的，同一臺機器不同的技術，效能發揮的程度可以說有天壤之別。

最後的最後手段才會考慮分散式架構，實在是砸不出這麼多錢了，實在是沒辦法了。因為分散式架構肯定會帶來非常多非常多的一致性問題，原本只需要訪問一臺機器，現在需要訪問N臺，那麼這N臺機器的一致性怎麼保證，以前撐死搞個主從備份就算完了，定時同步一下資料就好，現在N臺裝置的資料怎麼管理，甚至這個叢集本身怎麼管理，都會成為一個致命的問題。

所以只有等業務量到達一定程度了，單臺機器扛不住了，才會開始堆錢升級機器，系統拆分，換技術，繼續堆錢升級機器，系統拆分...周而復始，發現成本太高或者技術已經到達上線了。最後沒辦法，就選擇分散式架構了。

但是分散式架構的優勢也是明顯的，用一群低廉的裝置，來提供一個高效能高吞吐量的穩定的系統，下面開始說說常見的分散式叢集的架構。

1、純負載均衡形式。

在叢集前面，前置一個流量分發的元件進行流量分發，整個叢集的機器提供無差別的服務，這在常見的 web 伺服器中是最最常見的。目前比較主流的方式就是整個叢集機器上雲，根據實時的呼叫量進行雲伺服器彈性伸縮。常見的負載均衡有硬體層面的 F5、軟體層面的 nginx 等。

2、領導選舉型

整個叢集的訊息都會轉發到叢集的領導這裡，是一種 master-slavers，區別只是這個 master 是被臨時選舉出來的，一旦 master 宕機，叢集會立刻選舉出一個新的領導，繼續對外提供服務。使用領導選舉型架構的典型的應用有 ElasticSearch，zookeeper。

3、區塊鏈型

整個叢集的每一個節點都可以進行記錄，但是記錄的內容要得到整個叢集 N 個機器的認可才是合法的。典型的應用有 Bit Coin，以及 Hyperledger。

4、master-slaver型

整個叢集以某臺 master 為中樞，進行叢集的排程。互動是這樣，一般會把所有的管理型別的資料放到 master 上，而把具體的資料放到 slaver 上，實際進行呼叫的時候，client 先呼叫 master 獲取資料所存放的 server 的 資訊，再自行跟 slave 進行互動。典型的系統有 Hadoop。叢集，HBase 叢集，Redis 叢集等。

5、規則型一致性Hash

這種架構型別一般出現在資料庫分庫分表的設計中。按照規則進行分庫分表，在查詢之前使用規則引擎進行庫和表的確認，再對具體的應用進行訪問。為什麼要用一致性 Hash ？其實用什麼都可以，只是對於這類應用來說一致性 Hash 比較常見而已。

好了，至此，已經把我所知道的大部分分散式叢集的套路說完了，總結一下。

1、升級機器配置是最直接的升級方式。不到萬不得已不會使用分散式

2、分散式的核心就是業務拆分以及流量分發。

                                                           
                                                                    掃一掃，支援下作者吧

                                             （轉載本站文章請註明作者和出處 方誌朋的部落格）