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

申請免費試用、咨詢電話：400-8352-114

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

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

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

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

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

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

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

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

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

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

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

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

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