這篇文章給大家分享的是有關(guān)單服務(wù)、集群、分布式有什么區(qū)別的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
創(chuàng)新互聯(lián)公司于2013年創(chuàng)立，先為科爾沁左翼等服務(wù)建站，科爾沁左翼等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為科爾沁左翼企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。現(xiàn)在的互聯(lián)網(wǎng)，幾乎常見的復(fù)雜系統(tǒng)都會使用分布式架構(gòu)，如果在不清楚概念之前，剛接觸分布式架構(gòu)這個名詞會感覺十分的高大上，其實在對比單服務(wù)，集群服務(wù)之后，你就會發(fā)現(xiàn)本質(zhì)上都是一樣的。
絮叨一句：所謂Java架構(gòu)師，基本就是看被單服務(wù)，集群，分布式不斷暴打的頻率，架構(gòu)師因為被虐頻率高，自然做出來的系統(tǒng)架構(gòu)坑少，新手不能做架構(gòu)的原因，所以你該懂的。
言歸正傳，分布式架構(gòu)對于Java開發(fā)來說基本算是分水嶺，能不能從開發(fā)層面跳出來，就看你工作個三五年之后，對分布式系統(tǒng)理解到什么程度。單服務(wù)應(yīng)用，基于單服務(wù)做集群化部署，這種操作運維可以自行搭建環(huán)境，所以基本對能力要求不算高。但是如何設(shè)計出彈性、配置化、分布化、高性能、高容錯、安全的分布式系統(tǒng)，的確是一件很有挑戰(zhàn)的事情。
首先需要理清楚單服務(wù)，集群，分布式這幾種不同架構(gòu)的區(qū)別。
單服務(wù)和集群
一張圖，你品，你細品：
業(yè)務(wù)體量小，所有服務(wù)和應(yīng)用部署在一臺服務(wù)上，節(jié)省成本，這是單服務(wù)結(jié)構(gòu)。當(dāng)業(yè)務(wù)量逐漸增大，把一臺服務(wù)進行水平擴展，做一個服務(wù)群，每臺服務(wù)稱為集群的一個節(jié)點，到這就是集群服務(wù)。集群服務(wù)要面對的一個問題就是：請求分配，自然需要一個調(diào)度組件來均衡服務(wù)器壓力，這也被稱為負載均衡。
補刀一句：做到集群模式的應(yīng)用，在程序員面試的時候已經(jīng)會被拿來做高格調(diào)的自吹自擂了，其實單服務(wù)和集群的本質(zhì)區(qū)別就是：在處理請求的時候多了一個分配服務(wù)的過程，現(xiàn)在你還覺得跟人吹集群很高端嗎？
分布式
一張圖，你品，你細品：
這個概念解釋起來就不容易了，單服務(wù)到集群，是部署上的改變，在代碼層面改動極小，集群模式會加入更多的服務(wù)監(jiān)控，為了快速的判斷哪個服務(wù)宕機。
首先要解釋一下上圖：常見的電商系統(tǒng)架構(gòu)(部分業(yè)務(wù))，訂單，倉儲，物流。
用戶在訂單服務(wù)下單，自然需要校驗庫存；
下單成功之后，需要追蹤訂單物流；
商家需要倉儲服務(wù)管理上架商品，發(fā)貨等；
如果訂單服務(wù)出現(xiàn)高并發(fā)，可以水平擴展，做訂單服務(wù)的集群化；
這是一個基礎(chǔ)的業(yè)務(wù)場景，特點：多應(yīng)用服務(wù)，多數(shù)據(jù)庫存儲，且服務(wù)之間有通信行為，在個別服務(wù)壓力大的情況下可以水平擴展集群化部署。
分布式結(jié)構(gòu)就是按照業(yè)務(wù)系統(tǒng)的功能，拆分成獨立的子服務(wù)，可以獨立運行，且服務(wù)之間通信和交互。帶來的好處也是非常的多，例如：降低業(yè)務(wù)間的耦合度，方便開發(fā)維護，水平擴展，復(fù)用性高等等。
補刀一句：不要出現(xiàn)思維上的錯覺，認為分布式系統(tǒng)的邊界大于集群，如果把一個分布式整體看做一個服務(wù)，針對這個分布式服務(wù)做集群化部署，邏輯上是說的通的，只是這樣違背分布式系統(tǒng)的初衷，比如后臺服務(wù)，沒有那么大的高并發(fā)，自然不用浪費資源。
分布式和集群模式磨刀霍霍的根本原因，都是為了解決兩個問題：提高系統(tǒng)吞吐量和高可用性，只是兩種模式站在的角度和業(yè)務(wù)場景不同，例如業(yè)務(wù)單調(diào)的高并發(fā)場景，業(yè)務(wù)復(fù)雜但不具備并發(fā)的場景，當(dāng)然也有這兩種業(yè)務(wù)場景同時具備的。
補刀一句：針對系統(tǒng)架構(gòu)和選型，各大公司也確實沒有統(tǒng)一的標(biāo)準(zhǔn)，但是都強調(diào)寫代碼的規(guī)范和邏輯，這樣做的根本原因就是方便后續(xù)的系統(tǒng)架構(gòu)更改。
上面聊完了基本概念，現(xiàn)在聊聊分布式系統(tǒng)中的技術(shù)體系。這個話題依舊有點飄逸。分布式是一種架構(gòu)思維和模式，并不一定非要使用特定的框架，現(xiàn)在很火的幾個框架，SpringCloud,Dubbo，AliCloud等等，這些的出現(xiàn)都是給架構(gòu)提供了更多的選擇。
補刀一句：架構(gòu)體系和框架，一定是可以分的開概念，框架更多是方便架構(gòu)快速落地和實現(xiàn)。
作為開發(fā)人員，分布式系統(tǒng)要處理的問題非常多，但是主流的模塊有下面幾個：
網(wǎng)關(guān)控制
網(wǎng)關(guān)主要涉及到請求校驗，聚合API，路由配置，鑒權(quán)管理，安全，灰度發(fā)布等等。常用的Zuul組件。
配置中心
動態(tài)資源配置加載，例如運行時流量管理，環(huán)境切換，靜態(tài)資源管理等。常用Nacos和config組件。
服務(wù)管理
分布式中最難管理的模塊，也最容易出錯，首先多服務(wù)運行情況下，需要保證服務(wù)間的交互正常，避免請求在鏈路的某個服務(wù)上積壓，出現(xiàn)異常還要及時熔斷，進行服務(wù)降級，高并發(fā)到峰值時，要配置限流策略，還有最難處理的分布式事務(wù)。這里也被稱為服務(wù)容錯設(shè)計，常用Eureka、Hystrix、Sentinel、Dubbo等組件。
補刀一句：分布式系統(tǒng)中真正的核心內(nèi)容，即使一個很牛的架構(gòu)師，搭建的分布式環(huán)境也是在業(yè)務(wù)發(fā)展中不斷優(yōu)化的，不會一成不變。
作為運維人員：部署分布式系統(tǒng)的確是一件極其繁雜的事情，這時就應(yīng)景誕生了容器化運維。
部署環(huán)境
有的服務(wù)需要部署公有云(就是常說的幾家大公司云服務(wù))，有的要部署私有云（自己公司搭建，只服務(wù)自己業(yè)務(wù)的云服務(wù)），混合云就是上述兩種環(huán)境都需要部署服務(wù)?？傊?，現(xiàn)在不這么說，會顯得自己很低調(diào)。
容器化技術(shù)
將服務(wù)打包部署在Docker容器中，如果需要臨時擴展，把Docker容器鏡像快速部署到多個服務(wù)器上即可，如果對這個概念比較懵，就好比自己電腦里面多個虛擬機，可以基于一個虛擬機鏡像文件，快速復(fù)制多個。Docker一大特色就是：搭建一次，到處運行。
補刀一句：此處必須要感嘆一句，Java一直火那么久是有原因的，后續(xù)的很多技術(shù)出現(xiàn)都在參考這個基本理念。
環(huán)境監(jiān)控
分布式系統(tǒng)的應(yīng)用非常復(fù)雜，所以要對監(jiān)控做的非常到位，這里不僅僅要對服務(wù)監(jiān)控，硬件環(huán)境同樣重要。快速擴展，定位宕機服務(wù)。
上面一直沒有提到這個超大模塊，意識必須清楚，任何系統(tǒng)最復(fù)雜的邏輯莫過于數(shù)據(jù)存儲，從開發(fā)層面看：一個架構(gòu)的核心價值就是在于數(shù)據(jù)的管理。
基于上面分布式的概念，數(shù)據(jù)庫的理解方式也是同樣。分布式數(shù)據(jù)庫可以解決單個數(shù)據(jù)庫存儲的IO或CPU瓶頸而誕生的。常用的模式如下：
關(guān)系型
應(yīng)用集成一個數(shù)據(jù)庫代理的中間件，把數(shù)據(jù)基于特定策略路由到不同的數(shù)據(jù)庫表中，取數(shù)據(jù)的時候在以同樣的邏輯查詢。很經(jīng)典的sharding-jdbc組件，分庫分表的模式。
分布式
上面關(guān)系數(shù)據(jù)庫的分庫分表處理，是比較顯式且刻意的，在分布式數(shù)據(jù)庫中，天然的支持，且具有良好的水平擴展能力。例如：Hbase、mongodb、Greenplum分布式數(shù)倉等等。
分布式系統(tǒng)架構(gòu)和分布式數(shù)據(jù)存儲相輔相成，不管架構(gòu)選型還是存儲選型，都沒有可建議的標(biāo)準(zhǔn)，這里只能用一句很有用的廢話來描述：基于自己的技術(shù)認知范圍，和業(yè)務(wù)場景綜合考量。
感謝各位的閱讀！關(guān)于“單服務(wù)、集群、分布式有什么區(qū)別”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
重慶分公司
重慶分公司
