單機、分散式、集群的區別與聯繫

一、單機結構

  一個系統業務量很小的時候所有的程式碼都放在一個項目中,然後這個項目部署在一台伺服器上就好了,整個項目所有的服務都由這台伺服器提供。這就是單機結構。單機結構的缺點是顯而易見的,單機的處理能力畢竟是有限的,當你的業務增長到一定程度的時候,單機的硬體資源將無法滿足你的業務需求。此時便出現了集群模式。

二、集群結構

  單機處理到達瓶頸的時候,你就把單機複製幾份,這樣就構成了一個「集群」。集群中每台伺服器就叫做這個集群的一個「節點」,所有節點構成了一個集群。每個節點都提供相同的服務,那麼這樣系統的處理能力就相當於提升了好幾倍(有幾個節點就相當於提升了這麼多倍)。

  但問題是用戶的請求究竟由哪個節點來處理呢?最好能夠讓此時此刻負載較小的節點來處理,這樣使得每個節點的壓力都比較平均。要實現這個功能,就需要在所有節點之前增加一個「調度者」的角色,用戶的所有請求都先交給它,然後它根據當前所有節點的負載情況,決定將這個請求交給哪個節點處理。這個「調度者」有個牛逼了名字——負載均衡伺服器

  集群結構的好處就是系統擴展非常容易。如果隨著你們系統業務的發展,當前的系統又支撐不住了,那麼給這個集群再增加節點就行了。但是,當你的業務發展到一定程度的時候,你會發現一個問題——無論怎麼增加節點,貌似整個集群性能的提升效果並不明顯了。這時候,你就需要使用微服務結構了。

三、分散式結構

  從單機結構到集群結構,你的程式碼基本無需要作任何修改,你要做的僅僅是多部署幾台伺服器,每台伺服器上運行相同的程式碼就行了。但是,當你要從集群結構演進到微服務結構的時候,之前的那套程式碼就需要發生較大的改動了。所以對於新系統我們建議,系統設計之初就採用微服務架構,這樣後期運維的成本更低。但如果一套老系統需要升級成微服務結構的話,那就得對程式碼大動干戈了。所以,對於老系統而言,究竟是繼續保持集群模式,還是升級成微服務架構,這需要你們的架構師深思熟慮、權衡投入產出比。

  下面開始介紹所謂的分散式結構。

  分散式結構就是將一個完整的系統,按照業務功能,拆分成一個個獨立的子系統,在分散式結構中,每個子系統就被稱為「服務」。這些子系統能夠獨立運行在web容器中,它們之間通過RPC方式通訊。

  舉個例子,假設需要開發一個在線商城。按照微服務的思想,我們需要按照功能模組拆分成多個獨立的服務,如:用戶服務、產品服務、訂單服務、後台管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目,可以獨立運行。如果服務之間有依賴關係,那麼通過RPC方式調用。

  這樣的好處有很多:

  1、系統之間的耦合度大大降低,可以獨立開發、獨立部署、獨立測試,系統與系統之間的邊界非常明確,排錯也變得相當容易,開發效率大大提升。

  2、系統之間的耦合度降低,從而系統更易於擴展。我們可以針對性地擴展某些服務。假設這個商城要搞一次大促,下單量可能會大大提升,因此我們可以針對性地提升訂單系統、產品系統的節點數量,而對於後台管理系統、數據分析系統而言,節點數量維持原有水平即可。

  3、服務的復用性更高。比如,當我們將用戶系統作為單獨的服務後,該公司所有的產品都可以使用該系統作為用戶系統,無需重複開發。

四、三者之間的區別和聯繫

  以下漫畫圖很形象地說明三者之間的區別和聯繫:

五、總結

  集群是個物理形態,分散式是個工作方式。只要是一堆機器,就可以叫集群,他們是不是一起協作著幹活,這個誰也不知道;一個程式或系統,只要運行在不同的機器上,就可以叫分散式,嗯,C/S架構也可以叫分散式。

集群一般是物理集中、統一管理的,而分散式系統則不強調這一點。所以,集群可能運行著一個或多個分散式系統,也可能根本沒有運行分散式系統;分散式系統可能運行在一個集群上,也可能運行在不屬於一個集群的多台(2台也算多台)機器上。

轉載於://www.zhihu.com/question/20004877/answer/13632513

 
 
Tags: