網(wǎng)站建設(shè)關(guān)于應(yīng)用服務(wù)器集群解決方案。網(wǎng)站建設(shè)公司資深框架工程師認(rèn)為隨著訪問量繼續(xù)增加，單臺應(yīng)用服務(wù)器已經(jīng)無法滿足需求了。在假設(shè)數(shù)據(jù)庫服務(wù)器沒有壓力的情況下，網(wǎng)站建設(shè)公司提醒可以把應(yīng)用服務(wù)器從一臺變成了兩臺甚至多臺，把用戶的請求分散到不同的服務(wù)器中，從而提高負(fù)載能力。多臺應(yīng)用服務(wù)器之間沒有直接的交互，它們都是依賴數(shù)據(jù)庫各自對外提供服務(wù)。我們以增加了一臺應(yīng)用服務(wù)器為例。然而事情并不是如此簡單，系統(tǒng)演變到這里,將會出現(xiàn)下面四個問題:
(1)用戶的請求由誰來轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器，即負(fù)載均衡問題。
(2)轉(zhuǎn)發(fā)算法，即集群調(diào)度算法問題。
( 3 )應(yīng)用服務(wù)器如何返回用戶的請求，即集群模式問題。
(4)如果每次訪問到的服務(wù)器不一樣，數(shù)據(jù)的一致性如何維護(hù)，即session(階段)的問題。
網(wǎng)站建設(shè)關(guān)于數(shù)據(jù)庫讀寫分離化
上面我們總是假設(shè)數(shù)據(jù)庫負(fù)載正常，但隨著訪問量的提高,數(shù)據(jù)庫的負(fù)載也在慢慢增大。那么可能有人馬上就想到跟應(yīng)用服務(wù)器一樣，把數(shù)據(jù)庫一分為二再負(fù)載均衡即可。但對于數(shù)據(jù)庫來說，并沒有那么簡單。假如我們簡單地把數(shù)據(jù)庫一分為二，然后將對于數(shù)據(jù)庫的請求，分別負(fù)載到A機(jī)器和B機(jī)器，那么顯而易見會造成兩臺數(shù)據(jù)庫數(shù)據(jù)不統(tǒng)一的問題。對于這種情況，我們可以先考慮使用讀寫分離的方式。讀寫分離后的數(shù)據(jù)庫網(wǎng)站架構(gòu)如圖1-7所示
。這個結(jié)構(gòu)變化后也會帶來兩個問題:
( 1)主從數(shù)據(jù)庫之間數(shù)據(jù)同步問題。
(2)應(yīng)用對于數(shù)據(jù)源的選擇問題。
網(wǎng)站建設(shè)關(guān)于服務(wù)器集群用搜索引擎緩解讀庫的壓力
數(shù)據(jù)庫做讀庫的話，常常對模糊查找力不從心，即使做了讀寫分離，這個問題也未能解決。以我們所舉的交易網(wǎng)站為例,發(fā)布的商品存儲在數(shù)據(jù)庫中，用戶最常使用的功能就是查找商品,尤其是根據(jù)商品的標(biāo)題來查找對應(yīng)的商品。對于這種需求，一般我們都是通過SQL的 like功能來實現(xiàn)的，但是這種方式的代價非常大。此時，可以使用搜索引擎的倒排索引來完成，從而大大提高查詢速度。引入搜索引擎后也會帶來一些開銷，比如:需要實現(xiàn)索引的構(gòu)建、維護(hù)搜索引擎集群等。引入搜索引擎后的網(wǎng)站架構(gòu)如圖1-8所示
。
網(wǎng)站建設(shè)關(guān)于服務(wù)器集群知識之?dāng)?shù)據(jù)庫水平拆分與垂直拆分
網(wǎng)站演進(jìn)到現(xiàn)在，交易、商品、用戶的數(shù)據(jù)都還在同一個數(shù)據(jù)庫中。盡管人們采取了增加緩存、讀寫分離的方式，但隨著數(shù)據(jù)庫中內(nèi)容的持續(xù)增加，數(shù)據(jù)庫的瓶頸越來越突出。此時，我們有數(shù)據(jù)垂直拆分和水平拆分兩種選擇。
·數(shù)據(jù)垂直拆分
數(shù)據(jù)垂直拆分的意思是把數(shù)據(jù)庫中不同的業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫中，結(jié)合現(xiàn)在的例子,就是把交易、商品、用戶的數(shù)據(jù)分開。其優(yōu)點在于，解決了原來把所有業(yè)務(wù)放在一個數(shù)據(jù)庫中的壓力問題，可以根據(jù)業(yè)務(wù)的特點進(jìn)行更多的優(yōu)化;缺點是需要維護(hù)多個數(shù)據(jù)庫。數(shù)據(jù)垂直拆分后的網(wǎng)站架構(gòu)如圖1-9所示。
·數(shù)據(jù)水平拆分
數(shù)據(jù)水平拆分就是把同一個表中的數(shù)據(jù)拆分到兩個甚至多個數(shù)據(jù)庫中。產(chǎn)生數(shù)據(jù)水平拆分的原因是某個業(yè)務(wù)的數(shù)據(jù)量或者更新量到達(dá)了單個數(shù)據(jù)庫的瓶頸，這時就可以把這個表拆分到兩個或更多個數(shù)據(jù)庫中。數(shù)據(jù)水平拆分后，又出現(xiàn)了新問題:訪問用戶信息的應(yīng)用系統(tǒng)需要解決SQL路由的問題,因為現(xiàn)在用戶信息分在了兩個數(shù)據(jù)庫中，需要在進(jìn)行數(shù)據(jù)操作時了解要操作的數(shù)據(jù)在哪里。數(shù)據(jù)水平拆分后的網(wǎng)站架構(gòu)如圖1-10所示
。
網(wǎng)站建設(shè)關(guān)于服務(wù)器集群知識之應(yīng)用的拆分
隨著社會的發(fā)展，業(yè)務(wù)越來越多，應(yīng)用越來越大。我們需要考慮如何避免讓應(yīng)用越來越臃腫。這就需要把應(yīng)用拆開，使一個應(yīng)用變?yōu)閮蓚€甚至更多應(yīng)用。還是利用上面的例子，我們可以把用戶、商品、交易拆分開,變成“用戶-商品”和“用戶-交易”兩個子系統(tǒng)。拆分應(yīng)用后的網(wǎng)站架構(gòu)如圖1-11所示。
這樣拆分后，可能會有一些相同的代碼，比如商品和交易都需要使用用戶信息，這樣兩個系統(tǒng)中就都要保留操作用戶信息的代碼。如何保證這些代碼可以復(fù)用是一個需要解決的問題。
網(wǎng)站建設(shè)公司為了解決上面拆分應(yīng)用后所出現(xiàn)的問題，我們把公共的服務(wù)拆分出來，形成一種服務(wù)化的模式，簡稱SOA( service-oriented architecture)。面向服務(wù)的網(wǎng)站架構(gòu)如圖1-12所示。
其優(yōu)點在于，相同的代碼不會散落在不同的應(yīng)用中,代碼得到了更好的維護(hù)。以上的演變過程只是一個例子，并不適合所有的網(wǎng)站，實際中網(wǎng)站演進(jìn)過程與自身業(yè)務(wù)情況和遇到的問題有密切的關(guān)系，沒有固定的模式。只有認(rèn)真地分析和不斷地探究，才能發(fā)現(xiàn)適合自己網(wǎng)站的架構(gòu)。好了，
深圳網(wǎng)站建設(shè)公司本文關(guān)于“
網(wǎng)站建設(shè)關(guān)于應(yīng)用服務(wù)器集群解決方案”就分享到這里，謝謝關(guān)注，博納網(wǎng)絡(luò)編輯整理。
