【IT168 應用】隨着線上業務的發展，網站面臨高併發訪問和海量數據流的情況屢見不鮮，系統中的各個核心設備所負擔的處理能力和計算強度也會相應增大，使得單一設備根本無法承擔。如果淘汰現有設備去做硬件升級，將造成資源的浪費，而且如果以後面臨業務量的激增，又不得不再次投入高額的硬件升級成本，甚至性能再卓越的設備也不能滿足將來業務量的需求。
在此種情況下，單純的網絡架構就顯得捉襟見肘了，而負載均衡機制則應運而生。服務器負載均衡(Server Load Balancing)，其原理是將工作任務相對均衡地分攤到多個節點(服務器集羣)上執行，從而提升整個業務系統的性能。諸如LVS、HA Proxy等開源軟件，可以在現有的網絡基礎架構之上建立負載均衡機制，以滿足業務增長的需要，對於網站的來說不啻爲一種廉價且有效的擴展性選擇。
此外，針對互聯網上有可能影響數據傳輸的各種環節，CDN(Content Delivery Network)內容交付網絡的應對方案也適時出現。CDN對網站內容的處理，主要在於利用緩存技術將靜態內容快速分發至邊緣節點，通過讓用戶就近取得所需內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度，同時也減輕了網站自身系統的性能壓力。
現在看來，貌似我們已經解決了網站發佈所面臨的所有瓶頸了，但是實際上問題遠沒有那麼簡單。一方面，對於數據交互比較頻繁的動態內容而言，CDN只能在其中心節點與源數據節點(網站自身系統)之間做有限的傳輸優化，加速效果遠不如靜態內容做緩存分發那般明顯。
另一方面，隨着線上業務、電子商務等領域的Web內容呈現日漸豐富，湧現出了愈發複雜的業務交付需求，這對網站的發佈方而言也意味着將面臨更多的挑戰。因此，當我們拋開網絡的傳輸質量、帶寬擁塞程度等外界因素來看的話，又不得不正視一個問題--影響網站訪問效果的最大瓶頸還是在於源數據節點自身的處理性能。
以電子商務網站這種典型的大型高併發訪問量的線上業務爲例，其性能瓶頸最容易出現在聯機事務處理(OLTP)的環節，例如訪問用戶進行條目查閱、訂單確認等場景。產生這種情況的原因在於，網站的運營方出於數據安全等因素的考慮，是不可能將後臺數據庫等資源完全向CDN服務商開放的。由此造成，所有涉及到此類動態資源的訪問就會頻繁地經由CDN網絡的邊緣節點上溯到源數據節點(即網站自身系統)來請求實時地響應處理。在保障數據安全性的前提下，要解決網站的性能瓶頸問題，必須提高源數據節點的業務處理效率，因此我們還得從網絡架構的設計着手。
前文提到過，單臺服務器的處理能力有限，當突發訪問量驟然增加的時候，其性能就會成爲整個系統的瓶頸，導致用戶訪問的響應緩慢甚至網站服務器癱瘓。爲了滿足高併發量訪問的需求，可以通過軟件手段實現服務器集羣的多機負載均衡效果。然而，這種軟件式的負載均衡有一個不可避免的缺點，那便是系統的穩定性和性能方面受限於軟件所安裝運行的服務器，一旦訪問量過大時，該臺服務器就恰恰成了整個系統的瓶頸所在。
就一個發佈線上業務的網站系統而言，前臺的Web服務器由於有外部的CDN服務作爲靜態內容的分流渠道，尚不至於產生明顯的系統瓶頸，而後臺處理動態內容的核心業務系統就難免會感到壓力巨大了。具體分析的話，當前的業務系統多采用客戶端--中間件--數據庫的三層結構設計，通常多是利用WebLogic中間件軟件自帶的服務器集羣功能來滿足高性能需求，其中一臺WebLogic Server作爲管理服務器負責任務調度，實現負載均衡效果。但是，當訪問用戶到達一定數目的時候，由於該服務器自身的硬件性能瓶頸，會造成整個系統的聯機事務處理效率低下;而且由於WebLogic自身設計的原因，當任務量達到一定閥值的時候，即便是升級服務器硬件性能也無法提升其進行負載均衡調度的能力。
針對上述情況，最好的辦法莫過於採用硬件負載均衡設備，以解決數據流量過大、任務負荷過重所產生的系統瓶頸問題。在這一方面，業內知名的硬件廠商有F5、深信服等等。值得一提的是，深信服的應用交付產品除具有傳統負載均衡功能外，其獨有的單邊加速技術，能夠在跨運營商網絡環境中，通過廣域網傳輸文件及應用的訪問時間減少30%以上，極大提高了用戶體驗。
雖然部署硬件設備意味着一筆額外的開支，但是它給網站的整體業務系統所帶來的性能提升，卻是傳統的軟件方案所望其項背的。除此之外，專業的硬件設備所能提供的負載調度算法和健康檢查機制也更加豐富、全面，有助於進一步提升關鍵業務發佈的穩定性和持久性，這對於高併發量的大型網站而言是極具價值的。
當然，對於不同規模、不同業務的網站而言，沒有一概而論的設計標準，文中提到的技術手段都有着相應的適用場景，這就需要網站的架構師們做具體的規劃了。