掃盲

以前的項(xiàng)目是?? 一個(gè)服務(wù)器就夠了? 文件+數(shù)據(jù)庫(kù)?? 所謂的All in One

隨著用戶越來(lái)越多，訪問(wèn)量越來(lái)越大，硬盤(pán)、CPU、內(nèi)存越來(lái)越吃緊，一臺(tái)服務(wù)器滿足不了這還有文件服務(wù)器

數(shù)據(jù)服務(wù)與應(yīng)用服務(wù)分離，我們給應(yīng)用服務(wù)器配置更好的CPU、內(nèi)存

給數(shù)據(jù)服務(wù)器更好更快的硬盤(pán)

緩存提高訪問(wèn)速度

假設(shè)Applicate Server 為T(mén)omcat，Tomcat成為了一個(gè)瓶頸，我們可以購(gòu)買(mǎi)更強(qiáng)大的硬件，但總會(huì)有上限?? 后期這成本呈指數(shù)型增長(zhǎng)??

這個(gè)時(shí)候需要做服務(wù)器的集群，?

Load Balancer為負(fù)載均衡服務(wù)器

?

數(shù)據(jù)庫(kù)讀寫(xiě)分離（一切為提高訪問(wèn)速度）

W讀?? R寫(xiě)

?

小飯店原來(lái)只有一個(gè)廚師，切菜洗菜備料炒菜全干。后來(lái)客人多了，廚房一個(gè)廚師忙不過(guò)來(lái)，又請(qǐng)了個(gè)廚師，兩個(gè)廚師都能炒一樣的菜，這兩個(gè)廚師的關(guān)系是集群。為了讓廚師專心炒菜，把菜做到極致，又請(qǐng)了個(gè)配菜師負(fù)責(zé)切菜，備菜，備料，廚師和配菜師的關(guān)系是分布式，一個(gè)配菜師也忙不過(guò)來(lái)了，又請(qǐng)了個(gè)配菜師，兩個(gè)配菜師關(guān)系是集群

鏈接：https://www.zhihu.com/question/20004877/answer/112124929

分布式：一個(gè)業(yè)務(wù)分拆多個(gè)子業(yè)務(wù)，部署在不同的服務(wù)器上
集群：同一個(gè)業(yè)務(wù)，部署在多個(gè)服務(wù)器上

圖解

下面是充字?jǐn)?shù)的

?

單機(jī)結(jié)構(gòu)

一個(gè)系統(tǒng)業(yè)務(wù)量很小的時(shí)候所有的代碼都放在一個(gè)項(xiàng)目中就好了，然后這個(gè)項(xiàng)目部署在一臺(tái)服務(wù)器上就好了。整個(gè)項(xiàng)目所有的服務(wù)都由這臺(tái)服務(wù)器提供。這就是單機(jī)結(jié)構(gòu)。

那么，單機(jī)結(jié)構(gòu)有啥缺點(diǎn)呢？我想缺點(diǎn)是顯而易見(jiàn)的，單機(jī)的處理能力畢竟是有限的，當(dāng)你的業(yè)務(wù)增長(zhǎng)到一定程度的時(shí)候，單機(jī)的硬件資源將無(wú)法滿足你的業(yè)務(wù)需求。此時(shí)便出現(xiàn)了集群模式，往下接著看。

集群結(jié)構(gòu)

集群模式在程序猿界有各種裝逼解釋，有的讓你根本無(wú)法理解，其實(shí)就是一個(gè)很簡(jiǎn)單的玩意兒，且聽(tīng)我一一道來(lái)。

單機(jī)處理到達(dá)瓶頸的時(shí)候，你就把單機(jī)復(fù)制幾份，這樣就構(gòu)成了一個(gè)“集群”。集群中每臺(tái)服務(wù)器就叫做這個(gè)集群的一個(gè)“節(jié)點(diǎn)”，所有節(jié)點(diǎn)構(gòu)成了一個(gè)集群。每個(gè)節(jié)點(diǎn)都提供相同的服務(wù)，那么這樣系統(tǒng)的處理能力就相當(dāng)于提升了好幾倍（有幾個(gè)節(jié)點(diǎn)就相當(dāng)于提升了這么多倍）。

但問(wèn)題是用戶的請(qǐng)求究竟由哪個(gè)節(jié)點(diǎn)來(lái)處理呢？最好能夠讓此時(shí)此刻負(fù)載較小的節(jié)點(diǎn)來(lái)處理，這樣使得每個(gè)節(jié)點(diǎn)的壓力都比較平均。要實(shí)現(xiàn)這個(gè)功能，就需要在所有節(jié)點(diǎn)之前增加一個(gè)“調(diào)度者”的角色，用戶的所有請(qǐng)求都先交給它，然后它根據(jù)當(dāng)前所有節(jié)點(diǎn)的負(fù)載情況，決定將這個(gè)請(qǐng)求交給哪個(gè)節(jié)點(diǎn)處理。這個(gè)“調(diào)度者”有個(gè)牛逼了名字——負(fù)載均衡服務(wù)器。

集群結(jié)構(gòu)的好處就是系統(tǒng)擴(kuò)展非常容易。如果隨著你們系統(tǒng)業(yè)務(wù)的發(fā)展，當(dāng)前的系統(tǒng)又支撐不住了，那么給這個(gè)集群再增加節(jié)點(diǎn)就行了。但是，當(dāng)你的業(yè)務(wù)發(fā)展到一定程度的時(shí)候，你會(huì)發(fā)現(xiàn)一個(gè)問(wèn)題——無(wú)論怎么增加節(jié)點(diǎn)，貌似整個(gè)集群性能的提升效果并不明顯了。這時(shí)候，你就需要使用微服務(wù)結(jié)構(gòu)了。

分布式結(jié)構(gòu)

先來(lái)對(duì)前面的知識(shí)點(diǎn)做個(gè)總結(jié)。

從單機(jī)結(jié)構(gòu)到集群結(jié)構(gòu)，你的代碼基本無(wú)需要作任何修改，你要做的僅僅是多部署幾臺(tái)服務(wù)器，每臺(tái)服務(wù)器上運(yùn)行相同的代碼就行了。但是，當(dāng)你要從集群結(jié)構(gòu)演進(jìn)到微服務(wù)結(jié)構(gòu)的時(shí)候，之前的那套代碼就需要發(fā)生較大的改動(dòng)了。所以對(duì)于新系統(tǒng)我們建議，系統(tǒng)設(shè)計(jì)之初就采用微服務(wù)架構(gòu)，這樣后期運(yùn)維的成本更低。但如果一套老系統(tǒng)需要升級(jí)成微服務(wù)結(jié)構(gòu)的話，那就得對(duì)代碼大動(dòng)干戈了。所以，對(duì)于老系統(tǒng)而言，究竟是繼續(xù)保持集群模式，還是升級(jí)成微服務(wù)架構(gòu)，這需要你們的架構(gòu)師深思熟慮、權(quán)衡投入產(chǎn)出比。

OK，下面開(kāi)始介紹所謂的分布式結(jié)構(gòu)。

分布式結(jié)構(gòu)就是將一個(gè)完整的系統(tǒng)，按照業(yè)務(wù)功能，拆分成一個(gè)個(gè)獨(dú)立的子系統(tǒng)，在分布式結(jié)構(gòu)中，每個(gè)子系統(tǒng)就被稱為“服務(wù)”。這些子系統(tǒng)能夠獨(dú)立運(yùn)行在web容器中，它們之間通過(guò)RPC方式通信。

舉個(gè)例子，假設(shè)需要開(kāi)發(fā)一個(gè)在線商城。按照微服務(wù)的思想，我們需要按照功能模塊拆分成多個(gè)獨(dú)立的服務(wù)，如：用戶服務(wù)、產(chǎn)品服務(wù)、訂單服務(wù)、后臺(tái)管理服務(wù)、數(shù)據(jù)分析服務(wù)等等。這一個(gè)個(gè)服務(wù)都是一個(gè)個(gè)獨(dú)立的項(xiàng)目，可以獨(dú)立運(yùn)行。如果服務(wù)之間有依賴關(guān)系，那么通過(guò)RPC方式調(diào)用。

這樣的好處有很多：

系統(tǒng)之間的耦合度大大降低，可以獨(dú)立開(kāi)發(fā)、獨(dú)立部署、獨(dú)立測(cè)試，系統(tǒng)與系統(tǒng)之間的邊界非常明確，排錯(cuò)也變得相當(dāng)容易，開(kāi)發(fā)效率大大提升。

系統(tǒng)之間的耦合度降低，從而系統(tǒng)更易于擴(kuò)展。我們可以針對(duì)性地?cái)U(kuò)展某些服務(wù)。假設(shè)這個(gè)商城要搞一次大促，下單量可能會(huì)大大提升，因此我們可以針對(duì)性地提升訂單系統(tǒng)、產(chǎn)品系統(tǒng)的節(jié)點(diǎn)數(shù)量，而對(duì)于后臺(tái)管理系統(tǒng)、數(shù)據(jù)分析系統(tǒng)而言，節(jié)點(diǎn)數(shù)量維持原有水平即可。

服務(wù)的復(fù)用性更高。比如，當(dāng)我們將用戶系統(tǒng)作為單獨(dú)的服務(wù)后，該公司所有的產(chǎn)品都可以使用該系統(tǒng)作為用戶系統(tǒng)，無(wú)需重復(fù)開(kāi)發(fā)。

?

?

?

總結(jié)

以上是生活随笔為你收集整理的服务器集群是什么的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。