單機、分佈式、集羣的區別與聯繫

單機、分佈式、集羣的區別與聯繫

1、單機結構

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

2、集羣結構

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

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

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

3、分佈式結構

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

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

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

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

　　這樣的好處有不少：

　　一、系統之間的耦合度大大下降，能夠獨立開發、獨立部署、獨立測試，系統與系統之間的邊界很是明確，排錯也變得至關容易，開發效率大大提高。

　　二、系統之間的耦合度下降，從而系統更易於擴展。咱們能夠針對性地擴展某些服務。假設這個商城要搞一次大促，下單量可能會大大提高，所以咱們能夠針對性地提高訂單系統、產品系統的節點數量，而對於後臺管理系統、數據分析系統而言，節點數量維持原有水平便可。

　　三、服務的複用性更高。好比，當咱們將用戶系統做爲單獨的服務後，該公司全部的產品均可以使用該系統做爲用戶系統，無需重複開發。

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

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

5、總結

　　集羣是個物理形態，分佈式是個工做方式。只要是一堆機器，就能夠叫集羣，他們是否是一塊兒協做着幹活，這個誰也不知道；一個程序或系統，只要運行在不一樣的機器上，就能夠叫分佈式，嗯，C/S架構也能夠叫分佈式。

集羣通常是物理集中、統一管理的，而分佈式系統則不強調這一點。因此，集羣可能運行着一個或多個分佈式系統，也可能根本沒有運行分佈式系統；分佈式系統可能運行在一個集羣上，也可能運行在不屬於一個集羣的多臺（2臺也算多臺）機器上。

※部分文章來源於網絡，若有侵權請聯繫刪除；更多文章和資料|點擊後方文字直達 ↓↓↓
100GPython自學資料包
阿里雲K8s實戰手冊
[阿里雲CDN排坑指南] CDN
ECS運維指南
DevOps實踐手冊
Hadoop大數據實戰手冊
Knative雲原生應用開發指南
OSS 運維實戰手冊
雲原生架構白皮書
Zabbix企業級分佈式監控系統源碼文檔
10G大廠面試題戳領