集羣 分佈式

做者：大閒人柴毛毛
連接：https://www.zhihu.com/question/20004877/answer/282033178
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

下面就正經解釋下三種結構的區別吧～

單機結構

我想你們最最最熟悉的就是單機結構，一個系統業務量很小的時候全部的代碼都放在一個項目中就行了，而後這個項目部署在一臺服務器上就行了。整個項目全部的服務都由這臺服務器提供。這就是單機結構。

那麼，單機結構有啥缺點呢？我想缺點是顯而易見的，單機的處理能力畢竟是有限的，當你的業務增加到必定程度的時候，單機的硬件資源將沒法知足你的業務需求。此時便出現了集羣模式，往下接着看。

集羣結構

集羣模式在程序猿界有各類裝逼解釋，有的讓你根本沒法理解，其實就是一個很簡單的玩意兒，且聽我一一道來。

單機處理到達瓶頸的時候，你就把單機複製幾份，這樣就構成了一個「集羣」。集羣中每臺服務器就叫作這個集羣的一個「節點」，全部節點構成了一個集羣。每一個節點都提供相同的服務，那麼這樣系統的處理能力就至關於提高了好幾倍（有幾個節點就至關於提高了這麼多倍）。

但問題是用戶的請求究竟由哪一個節點來處理呢？最好可以讓此時此刻負載較小的節點來處理，這樣使得每一個節點的壓力都比較平均。要實現這個功能，就須要在全部節點以前增長一個「調度者」的角色，用戶的全部請求都先交給它，而後它根據當前全部節點的負載狀況，決定將這個請求交給哪一個節點處理。這個「調度者」有個牛逼了名字——負載均衡服務器。

集羣結構的好處就是系統擴展很是容易。若是隨着大家系統業務的發展，當前的系統又支撐不住了，那麼給這個集羣再增長節點就好了。可是，當你的業務發展到必定程度的時候，你會發現一個問題——不管怎麼增長節點，貌似整個集羣性能的提高效果並不明顯了。這時候，你就須要使用微服務結構了。

分佈式結構

先來對前面的知識點作個總結。

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

OK，下面開始介紹所謂的分佈式結構。

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

舉個例子，假設須要開發一個在線商城。按照微服務的思想，咱們須要按照功能模塊拆分紅多個獨立的服務，如：用戶服務、產品服務、訂單服務、後臺管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目，能夠獨立運行。若是服務之間有依賴關係，那麼經過RPC方式調用。

這樣的好處有不少：

1. 系統之間的耦合度大大下降，能夠獨立開發、獨立部署、獨立測試，系統與系統之間的邊界很是明確，排錯也變得至關容易，開發效率大大提高。
2. 系統之間的耦合度下降，從而系統更易於擴展。咱們能夠針對性地擴展某些服務。假設這個商城要搞一次大促，下單量可能會大大提高，所以咱們能夠針對性地提高訂單系統、產品系統的節點數量，而對於後臺管理系統、數據分析系統而言，節點數量維持原有水平便可。
3. 服務的複用性更高。好比，當咱們將用戶系統做爲單獨的服務後，該公司全部的產品均可以使用該系統做爲用戶系統，無需重複開發。