簡單理解：
分布式：乙個業務分拆多個子業務，部署在不同的伺服器上
集群：同乙個業務，部署在多個伺服器上
一句話，就是：「分頭做事」與「一堆人」的區別
詳細理解：
我想大家最最最熟悉的就是單機結構，乙個系統業務量很小的時候所有的**都放在乙個專案中就好了，然後這個專案部署在一台伺服器上就好了。整個專案所有的服務都由這台伺服器提供。這就是單機結構。
那麼，單機結構有啥缺點呢？我想缺點是顯而易見的，單機的處理能力畢竟是有限的，當你的業務增長到一定程度的時候，單機的硬體資源將無法滿足你的業務需求。此時便出現了集群模式，往下接著看。
集群模式在程式猿界有各種裝逼解釋，有的讓你根本無法理解，其實就是乙個很簡單的玩意兒，且聽我一一道來。
單機處理到達瓶頸的時候，你就把單機複製幾份，這樣就構成了乙個「集群」。集群中每台伺服器就叫做這個集群的乙個「節點」，所有節點構成了乙個集群。每個節點都提供相同的服務，那麼這樣系統的處理能力就相當於提公升了好幾倍（有幾個節點就相當於提公升了這麼多倍）。
但問題是使用者的請求究竟由哪個節點來處理呢？最好能夠讓此時此刻負載較小的節點來處理，這樣使得每個節點的壓力都比較平均。要實現這個功能，就需要在所有節點之前增加乙個「排程者」的角色，使用者的所有請求都先交給它，然後它根據當前所有節點的負載情況，決定將這個請求交給哪個節點處理。這個「排程者」有個牛逼了名字——負載均衡伺服器。
集群結構的好處就是系統擴充套件非常容易。如果隨著你們系統業務的發展，當前的系統又支撐不住了，那麼給這個集群再增加節點就行了。但是，當你的業務發展到一定程度的時候，你會發現乙個問題——無論怎麼增加節點，貌似整個集群效能的提公升效果並不明顯了。這時候，你就需要使用微服務結構了。
注：集群模式需要做好session共享，確保在不同伺服器切換的過程中不會因為沒有獲取到session而中止退出服務。
一般配置nginx*的負載容器實現：靜態資源快取、session共享可以附帶實現，nginx支援5000個併發量。
先來對前面的知識點做個總結。
從單機結構到集群結構，你的**基本無需要作任何修改，你要做的僅僅是多部署幾台伺服器，每台伺服器上執行相同的**就行了。但是，當你要從集群結構演進到微服務結構的時候，之前的那套**就需要發生較大的改動了。所以對於新系統我們建議，系統設計之初就採用微服務架構，這樣後期運維的成本更低。但如果一套老系統需要公升級成微服務結構的話，那就得對**大動干戈了。所以，對於老系統而言，究竟是繼續保持集群模式，還是公升級成微服務架構，這需要你們的架構師深思熟慮、權衡投入產出比。
ok，下面開始介紹所謂的分布式結構。
分布式結構就是將乙個完整的系統，按照業務功能，拆分成乙個個獨立的子系統，在分布式結構中，每個子系統就被稱為「服務」。這些子系統能夠獨立執行在web容器中，它們之間通過rpc方式通訊。
這樣的好處有很多：
系統之間的耦合度大大降低，可以獨立開發、獨立部署、獨立測試，系統與系統之間的邊界非常明確，排錯也變得相當容易，開發效率大大提公升。
系統之間的耦合度降低，從而系統更易於擴充套件。我們可以針對性地擴充套件某些服務。假設這個**要搞一次大促，下單量可能會大大提公升，因此我們可以針對性地提公升訂單系統、產品系統的節點數量，而對於後台管理系統、資料分析系統而言，節點數量維持原有水平即可。
服務的復用性更高。比如，當我們將使用者系統作為單獨的服務後，該公司所有的產品都可以使用該系統作為使用者系統，無需重複開發。
注：分布式需要做好事務管理。
集群和分布式的理解區別
一 大白話解說，半分鐘就懂，用生活中的例子來說明 小飯店原來只有乙個廚師，切菜洗菜備料炒菜全乾。後來客人多了，廚房乙個廚師忙不過來，又請了個廚師，兩個廚師都能炒一樣的菜，兩個廚師的關係是集群。為了讓廚師專心炒菜，把菜做到極致，再請了個配菜師負責切菜，備菜，備料 廚師和配菜師的關係是分布式。乙個配菜師...
分布式和集群的理解
原文 分布式分布式 乙個業務拆分成多個子業務，部署在多個伺服器上。若乙個子業務節點垮了，那整個業務就不能訪問了。舉例 乙個人跑完一千公尺，變成四個人各跑250公尺 四個人都跑完250公尺用的時間會少於乙個人跑1000公尺用的時間，單個節點無法滿足業務需求的時候，採用分布式可減少負載提公升效能和併發,...
分布式和集群的區別
第一部分 分布式 1 最簡單的分布式就是大家最常用的，在負載均衡伺服器後加一堆web伺服器，然後在上面搞乙個快取伺服器來儲存臨時狀態，後面共享乙個 資料庫，其實很多號稱分布式專家的人也就停留於此，大致結構如下圖所示 這種環境下真正進行分布式的只是web server而已，並且web server之間...