一、單機結構

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

二、集群結構

　　單機處理到達瓶頸的時候，你就把單機復制幾份，這樣就構成了一個“集群”。集群中每臺服務器就叫做這個集群的一個“節點”，所有節點構成了一個集群。每個節點都提供相同的服務，那么這樣系統的處理能力就相當于提升了好幾倍（有幾個節點就相當于提升了這么多倍）。

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

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

三、分布式結構

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

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

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

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

　　這樣的好處有很多：

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

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

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

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

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

五、總結

　　集群是個物理形態，分布式是個工作方式。只要是一堆機器，就可以叫集群，他們是不是一起協作著干活，這個誰也不知道；一個程序或系統，只要運行在不同的機器上，就可以叫分布式，嗯，C/S架構也可以叫分布式。
集群一般是物理集中、統一管理的，而分布式系統則不強調這一點。所以，集群可能運行著一個或多個分布式系統，也可能根本沒有運行分布式系統；分布式系統可能運行在一個集群上，也可能運行在不屬于一個集群的多臺（2臺也算多臺）機器上。

總結

以上是生活随笔為你收集整理的需要单机还是集群部署_单机、分布式、集群的区别与联系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。