出處： 分布式與叢集的差別是什麼？
單機結構
我想大家最最最熟悉的就是單機結構，一個系統業務量很小的時候所有的代碼都放在一個項目中就好了，然後這個項目部署在一台伺服器上就好了。整個項目所有的服務都由這台伺服器提供。這就是單機結構。
那麼，單機結構有啥缺點呢？我想缺點是顯而易見的，單機的處理能力畢竟是有限的，當你的業務增長到一定程度的時候，單機的硬體資源将無法滿足你的業務需求。此時便出現了叢集模式，往下接着看。
叢集結構
叢集模式在程式猿界有各種裝逼解釋，有的讓你根本無法了解，其實就是一個很簡單的玩意兒，且聽我一一道來。
單機處理到達瓶頸的時候，你就把單機複制幾份，這樣就構成了一個“叢集”。叢集中每台伺服器就叫做這個叢集的一個“節點”，所有節點構成了一個叢集。每個節點都提供相同的服務，那麼這樣系統的處理能力就相當于提升了好幾倍（有幾個節點就相當于提升了這麼多倍）。
但問題是使用者的請求究竟由哪個節點來處理呢？最好能夠讓此時此刻負載較小的節點來處理，這樣使得每個節點的壓力都比較平均。要實作這個功能，就需要在所有節點之前增加一個“排程者”的角色，使用者的所有請求都先交給它，然後它根據目前所有節點的負載情況，決定将這個請求交給哪個節點處理。這個“排程者”有個牛逼了名字——負載均衡伺服器。
叢集結構的好處就是系統擴充非常容易。如果随着你們系統業務的發展，目前的系統又支撐不住了，那麼給這個叢集再增加節點就行了。但是，當你的業務發展到一定程度的時候，你會發現一個問題——無論怎麼增加節點，貌似整個叢集性能的提升效果并不明顯了。這時候，你就需要使用微服務結構了。
分布式結構
先來對前面的知識點做個總結。
從單機結構到叢集結構，你的代碼基本無需要作任何修改，你要做的僅僅是多部署幾台伺服器，每台伺服器上運作相同的代碼就行了。但是，當你要從叢集結構演進到微服務結構的時候，之前的那套代碼就需要發生較大的改動了。是以對于新系統我們建議，系統設計之初就采用微服務架構，這樣後期運維的成本更低。但如果一套老系統需要更新成微服務結構的話，那就得對代碼大動幹戈了。是以，對于老系統而言，究竟是繼續保持叢集模式，還是更新成微服務架構，這需要你們的架構師深思熟慮、權衡投入産出比。
OK，下面開始介紹所謂的分布式結構。
分布式結構就是将一個完整的系統，按照業務功能，拆分成一個個獨立的子系統，在分布式結構中，每個子系統就被稱為“服務”。這些子系統能夠獨立運作在web容器中，它們之間通過RPC方式通信。
舉個例子，假設需要開發一個線上商城。按照微服務的思想，我們需要按照功能子產品拆分成多個獨立的服務，如：使用者服務、産品服務、訂單服務、背景管理服務、資料分析服務等等。這一個個服務都是一個個獨立的項目，可以獨立運作。如果服務之間有依賴關系，那麼通過RPC方式調用。
這樣的好處有很多：
- 系統之間的耦合度大大降低，可以獨立開發、獨立部署、獨立測試，系統與系統之間的邊界非常明确，排錯也變得相當容易，開發效率大大提升。
- 系統之間的耦合度降低，進而系統更易于擴充。我們可以針對性地擴充某些服務。假設這個商城要搞一次大促，下單量可能會大大提升，是以我們可以針對性地提升訂單系統、産品系統的節點數量，而對于背景管理系統、資料分析系統而言，節點數量維持原有水準即可。
- 服務的複用性更高。比如，當我們将使用者系統作為單獨的服務後，該公司所有的産品都可以使用該系統作為使用者系統，無需重複開發。
------------------------------------------------------------------------------------
1.分布式
将一個大的系統劃分為多個業務子產品，業務子產品分别部署到不同的機器上，各個業務子產品之間通過接口進行資料互動。差別分布式的方式是根據不同機器不同業務。
上面：service A、B、C、D 分别是業務元件，通過API Geteway進行業務通路。
注：分布式需要做好事務管理。
2.叢集模式
叢集模式是不同伺服器部署同一套服務對外通路，實作服務的負載均衡。差別叢集的方式是根據部署多台伺服器業務是否相同。
注：叢集模式需要做好session共享，確定在不同伺服器切換的過程中不會因為沒有擷取到session而中止退出服務。
一般配置Nginx*的負載容器實作：靜态資源緩存、Session共享可以附帶實作，Nginx支援5000個并發量。
3.分布式是否屬于微服務？
答案是肯定的。微服務的意思也就是将子產品拆分成一個獨立的服務單元通過接口來實作資料的互動。