通過數(shù)據(jù)庫負(fù)載均衡提高SaaS應(yīng)用性能

申請免費(fèi)試用、咨詢電話：400-8352-114

SaaS應(yīng)用企業(yè)最擔(dān)心的不過是兩件事，一是將企業(yè)的數(shù)據(jù)保存在外部的數(shù)據(jù)庫服務(wù)器中是否安全;二是這么多用戶同時(shí)訪問SaaS應(yīng)用服務(wù)，其性能是否可以保障。筆者這就以自己的親身感受為例，談?wù)凷aaS應(yīng)用提供商是如何通過數(shù)據(jù)庫負(fù)載均衡來提高SaaS應(yīng)用程序的性能。

第一階段：單個(gè)數(shù)據(jù)庫服務(wù)階段。

筆者企業(yè)一開始就上了OA系統(tǒng)。這個(gè)OA系統(tǒng)是基于B/S架構(gòu)的。企業(yè)剛開始設(shè)計(jì)、使用這個(gè)OA系統(tǒng)的時(shí)候，并不沒有想到做為商品來賣，是供企業(yè)自己內(nèi)部使用的。所有一開始，就只才用了單個(gè)數(shù)據(jù)庫服務(wù)器。后來隨著SaaS概念的提出，企業(yè)就想到也可以將這個(gè)OA系統(tǒng)拿出來賣。后來隨著用戶數(shù)量的增多，OA系統(tǒng)的性能明顯下降。為了提高OA系統(tǒng)的性能，技術(shù)部分提出了雙WEB服務(wù)器的方案。也就是說，通過兩臺WEB服務(wù)器來分流用戶的請求。不過在后臺數(shù)據(jù)庫仍然只有一臺。當(dāng)用戶數(shù)量比較少的時(shí)候，往往數(shù)據(jù)庫不會(huì)成為用戶訪問數(shù)據(jù)的瓶頸。應(yīng)用程序性能的瓶頸主要卡在WEB服務(wù)器上。為此在用戶數(shù)量增加不多的情況下，通過添加新的WEB服務(wù)器可以明顯提高應(yīng)用程序的性能。

第二階段：將數(shù)據(jù)更新與查詢分布在不同的服務(wù)器中。

后來由于客戶的要求，企業(yè)在原先的OA系統(tǒng)中又集成了公司論壇、項(xiàng)目管理等應(yīng)用系統(tǒng)，用戶的數(shù)量也隨之增加。在這多方面的影響下，SaaS應(yīng)用軟件的性能又開始逐漸下降，企業(yè)不得接到客戶的投訴。經(jīng)過技術(shù)專家的分析與論證，此時(shí)通過增加WEB服務(wù)企來改善應(yīng)用程序的性能效果已經(jīng)不明顯。為了提高應(yīng)用程序的性能，提高客戶滿意度，經(jīng)過跟企業(yè)技術(shù)部門協(xié)商后，決定通過增加數(shù)據(jù)庫服務(wù)器來改善應(yīng)用程序的性能。考慮到論壇、OA系統(tǒng)的應(yīng)用特點(diǎn)，其中 80%上的用戶都只是對信息的查詢，而很少涉及到對數(shù)據(jù)的更新。企業(yè)決定將數(shù)據(jù)更新與查詢分布在不同的服務(wù)器，來均衡數(shù)據(jù)庫發(fā)負(fù)載。也就說，如果只是查詢數(shù)據(jù)的話，只是從兩臺輔助服務(wù)器中進(jìn)行查詢。如果需要對其中的數(shù)據(jù)進(jìn)行更新，那么WEB應(yīng)用程序就會(huì)將用戶的請求連接到主服務(wù)器中執(zhí)行更新操作。更新完畢后，主服務(wù)器中的數(shù)據(jù)會(huì)同輔助服務(wù)器中的數(shù)據(jù)進(jìn)行同步。這么設(shè)計(jì)可以大幅度的提高SaaS應(yīng)用程序的性能。

一是將用戶更新請求與查詢請求進(jìn)行分流。這個(gè)原理就好像是告訴公路上將車道分為超車道、普通車道、貨車道等等。通過對信息流的合理分流，可以提高SaaS應(yīng)用程序后臺數(shù)據(jù)庫的性能。同時(shí)有兩臺服務(wù)器同時(shí)響應(yīng)用戶的查詢請求。WEB應(yīng)用程序會(huì)自動(dòng)根據(jù)這兩臺數(shù)據(jù)庫服務(wù)器的負(fù)荷來引導(dǎo)用戶連接到相對來說比較空閑的數(shù)據(jù)庫服務(wù)器中。也就是說，這對于用戶來說是透明的，他們并不知道后臺數(shù)據(jù)庫的部署已經(jīng)有了天翻地覆的效果。

二是為后續(xù)的擴(kuò)展提供了很好的平臺。只要數(shù)據(jù)的更新不是導(dǎo)致應(yīng)用程序性能下降的主要原因，即應(yīng)用程序的性能瓶頸主要在于數(shù)據(jù)的查詢作業(yè)，那么在以后就可以簡單的通過增加輔助服務(wù)器來分散用戶查詢操作對數(shù)據(jù)庫服務(wù)器帶來的壓力。由于用戶數(shù)量的增加，筆者企業(yè)現(xiàn)在數(shù)據(jù)庫輔助服務(wù)器已經(jīng)增加到了5臺。由于用戶數(shù)量增加，其更新操作數(shù)量反而增加不多，根據(jù)觀測現(xiàn)在主數(shù)據(jù)庫服務(wù)器的性能還是可以的。為此企業(yè)暫時(shí)沒有增加主數(shù)據(jù)庫服務(wù)器的打算。

三是在數(shù)據(jù)的同步上比較容易實(shí)現(xiàn)。在通過使用多個(gè)數(shù)據(jù)庫來負(fù)責(zé)均衡，其面臨的主要問題就是數(shù)據(jù)同步的問題。當(dāng)用戶連接到某臺數(shù)據(jù)庫服務(wù)器，更新了相關(guān)內(nèi)容之后，如何及時(shí)的同步到其他的數(shù)據(jù)庫服務(wù)器中去。這是技術(shù)人員必須要考慮的問題。而采用這個(gè)主數(shù)據(jù)庫加查詢輔助數(shù)據(jù)庫的方案，讓數(shù)據(jù)同步的問題變得比較簡單。也就是說，在這個(gè)方案中，技術(shù)人員只需要考慮主服務(wù)器到各個(gè)輔助服務(wù)器之間數(shù)據(jù)的更新，而不用考慮各個(gè)服務(wù)器內(nèi)之間的數(shù)據(jù)更新。因?yàn)榇藭r(shí)只有一臺數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)是可以被用戶更新的。其他服務(wù)器對于用戶來說是只讀的。故此時(shí)技術(shù)人員要實(shí)現(xiàn)數(shù)據(jù)同步的話，就會(huì)變得相對簡單許多。

第三階段：利用垂直分割提高數(shù)據(jù)庫的性能。

雖然企業(yè)現(xiàn)在的數(shù)據(jù)庫架構(gòu)，暫時(shí)還可以滿足用戶性能上的需求。但是企業(yè)已經(jīng)意識到，現(xiàn)在這種架構(gòu)不會(huì)存在很久。因?yàn)楝F(xiàn)在用戶的數(shù)量與信息流量都在急劇增加。主數(shù)據(jù)庫服務(wù)器的負(fù)荷快要達(dá)到預(yù)計(jì)的警戒點(diǎn)了?，F(xiàn)在企業(yè)技術(shù)人員已經(jīng)在設(shè)計(jì)、部署新一輪的數(shù)據(jù)庫升級方案了。按照技術(shù)人員的思路，這次想通過垂直分割地防范來改善主數(shù)據(jù)庫服務(wù)的性能。也就是說，按照目前的應(yīng)用情況，將SaaS應(yīng)用的所有業(yè)務(wù)都放在一臺主數(shù)據(jù)庫上去進(jìn)行數(shù)據(jù)更新，對于主數(shù)據(jù)庫服務(wù)器的壓力比較大。由于數(shù)據(jù)更新量實(shí)在太大，通過硬件升級、查詢與更新數(shù)據(jù)分流等手段效果已經(jīng)不是很明顯。技術(shù)人員想用過垂直分割的手段，將不同的業(yè)務(wù)流量分割到不同的數(shù)據(jù)庫服務(wù)器中去。即將BBS業(yè)務(wù)、OA業(yè)務(wù)、項(xiàng)目管理業(yè)務(wù)分別部署到三臺主服務(wù)器上，而輔助服務(wù)器暫時(shí)保留原有的數(shù)量。如此通過WEB應(yīng)用程序的引導(dǎo)，用戶需要訪問某個(gè)應(yīng)用的話（需要對這個(gè)應(yīng)用的數(shù)據(jù)進(jìn)行更新操作），WEB應(yīng)用程序就會(huì)自動(dòng)將其引導(dǎo)到合適的主服務(wù)器中去。而輔助服務(wù)器的話，仍然擔(dān)任著數(shù)據(jù)查詢的角色。此時(shí)由于各個(gè)主服務(wù)器之間負(fù)責(zé)各自獨(dú)立的業(yè)務(wù)，所以彼此之間也不需要很嚴(yán)格的數(shù)據(jù)同步。即只需要實(shí)現(xiàn)主服務(wù)器與輔助服務(wù)器之間的數(shù)據(jù)同步即可。

第四階段：備用解決方案。

如果后續(xù)隨著用戶數(shù)量的增加與業(yè)務(wù)種類的增加，上面這個(gè)解決方案還不能夠滿足用戶訪問需求的話，技術(shù)人員還涉及了一個(gè)備用的解決方案。這個(gè)備用解決方案是在上面這個(gè)解決方案的基礎(chǔ)上，通過添加同一個(gè)業(yè)務(wù)的主服務(wù)器數(shù)量來提高SaaS應(yīng)用服務(wù)的性能。或者說，更進(jìn)一步的解決方案，就是實(shí)現(xiàn)數(shù)據(jù)庫的分布式方案。畢竟當(dāng)用戶多了、SaaS業(yè)務(wù)多了，需要實(shí)現(xiàn)在各個(gè)業(yè)務(wù)之間進(jìn)行統(tǒng)一的身份認(rèn)證。即憑借一個(gè)用戶名與密碼就可以訪問各個(gè)SaaS應(yīng)用服務(wù)。現(xiàn)在很多大型的WEB應(yīng)用，如sina等網(wǎng)站，在后臺都實(shí)現(xiàn)了分布式的數(shù)據(jù)庫服務(wù)架構(gòu)，通過提高數(shù)據(jù)查詢與更新的效率來提高SaaS應(yīng)用程序的性能。

如果用戶與業(yè)務(wù)數(shù)量再增加，這個(gè)分布式數(shù)據(jù)庫方案還不能夠解決問題的話，那么就需要在數(shù)據(jù)存儲(chǔ)、云計(jì)算等方面努力了。不過一般來說，只要用戶數(shù)量在500萬以下的SaaS的應(yīng)用，一般以上幾個(gè)解決方案就可以了。最后筆者要強(qiáng)調(diào)的是，雖然從成本、風(fēng)險(xiǎn)等角度考慮，根據(jù)用戶的數(shù)量與業(yè)務(wù)的種類一步步的進(jìn)行數(shù)據(jù)庫解決方案的升級是可行的。因?yàn)楝F(xiàn)在向SQL Server或者Oracle等數(shù)據(jù)庫都集成了相關(guān)的解決方案。升級是比較簡單的，風(fēng)險(xiǎn)也不是很大。但是在系統(tǒng)規(guī)劃的時(shí)候，還是需要考慮未來業(yè)務(wù)與用戶數(shù)量的增長。在成本允許的情況下，盡量采取性能比較高的解決方案。也就是說，如上的各個(gè)階段企業(yè)不用一步步來。只要資金充裕，并對未來的應(yīng)用前景比較有信心的話，可以一步到位。畢竟在升級的過程中，無論規(guī)劃的多好，都會(huì)出現(xiàn)短暫的停機(jī)現(xiàn)象。