第一篇：大型網(wǎng)站架構設計及技術總結

大型網(wǎng)站架構設計及技術總結

隨著中國大型IT企業(yè)信息化速度的加快，大部分應用的數(shù)據(jù)量和訪問量都急劇增加，大型企業(yè)網(wǎng)站正面臨性能和高數(shù)據(jù)訪問量的壓力，而且對存儲、安全以及信息檢索等等方面都提出了更高的要求??

本文中，我想通過幾個國外大型IT企業(yè)及網(wǎng)站的成功案例，從Web技術人員角度探討如何積極地應對國內大型網(wǎng)站即將面臨的擴展（主要是技術方面，而較少涉及管理及營銷等方面）矛盾。

一、國外大型IT網(wǎng)站的成功之道

(一)MySpace

今天，MySpace已經成為全球眾口皆碑的社區(qū)網(wǎng)站之王。盡管一流和營銷和管理經驗自然是每個IT企業(yè)取得成功的首要因素，但是本節(jié)中我們卻拋棄這一點，而主要著眼于探討在數(shù)次面臨系統(tǒng)擴張的緊急關頭MySpace是如何從技術方面采取應對策略的。

第一代架構—添置更多的Web服務器

MySpace最初的系統(tǒng)很小，只有兩臺Web服務器（分擔處理用戶請求的工作量）和一個數(shù)據(jù)庫服務器（所有數(shù)據(jù)都存儲在這一個地方）。那時使用的是Dell雙CPU、4G內存的系統(tǒng)。在早期階段，MySpace基本是通過添置更多Web服務器來對付用戶暴增問題的。但到在2004年早期，在MySpace用戶數(shù)增長到五十萬后，其數(shù)據(jù)庫服務器已經開始疲于奔命了。

第二代架構—增加數(shù)據(jù)庫服務器

與增加Web服務器不同，增加數(shù)據(jù)庫并沒那么簡單。如果一個站點由多個數(shù)據(jù)庫支持，設計者必須考慮的是，如何在保證數(shù)據(jù)一致性的前提下讓多個數(shù)據(jù)庫分擔壓力。

MySpace運行在三個SQL Server數(shù)據(jù)庫服務器上—一個為主，所有的新數(shù)據(jù)都向它提交，然后由它復制到其它兩個；另兩個數(shù)據(jù)庫服務器全力向用戶供給數(shù)據(jù)，用以在博客和個人資料欄顯示。這種方式在一段時間內效果很好——只要增加數(shù)據(jù)庫服務器，加大硬盤，就可以應對用戶數(shù)和訪問量的增加。

這一次的數(shù)據(jù)庫架構按照垂直分割模式設計，不同的數(shù)據(jù)庫服務于站點的不同功能，如登錄、用戶資料和博客。垂直分割策略利于多個數(shù)據(jù)庫分擔訪問壓力，當用戶要求增加新功能時，MySpace只需要投入新的數(shù)據(jù)庫加以支持。在賬戶到達二百萬后，MySpace還從存儲設備與數(shù)據(jù)庫服務器直接交互的方式切換到SAN（存儲區(qū)域網(wǎng)絡）—用高帶寬、專門設計的網(wǎng)絡將大量磁盤存儲設備連接在一起，而數(shù)據(jù)庫連接到SAN。這項措施極大提升了系統(tǒng)性能、正常運行時間和可靠性。然而，當用戶繼續(xù)增加到三百萬后，垂直分割策略也變得難以維持下去。

第三代架構—轉到分布式計算架構

幾經折騰，最終，MySpace將目光移到分布式計算架構——它在物理上分布的眾多服務器，整體必須邏輯上等同于單臺機器。拿數(shù)據(jù)庫來說，就不能再像過去那樣將應用拆分，再以不同數(shù)據(jù)庫分別支持，而必須將整個站點看作一個應用?，F(xiàn)在，數(shù)據(jù)庫模型里只有一個用戶表，支持博客、個人資料和其他核心功能的數(shù)

據(jù)都存儲在相同數(shù)據(jù)庫。

既然所有的核心數(shù)據(jù)邏輯上都組織到一個數(shù)據(jù)庫，那么MySpace必須找到新的辦法以分擔負荷——顯然，運行在普通硬件上的單個數(shù)據(jù)庫服務器是無能為力的。這次，不再按站點功能和應用分割數(shù)據(jù)庫，MySpace開始將它的用戶按每百萬一組分割，然后將各組的全部數(shù)據(jù)分別存入獨立的SQL Server實例。目前，MySpace的每臺數(shù)據(jù)庫服務器實際運行兩個SQL Server實例，也就是說每臺服務器服務大約二百萬用戶。據(jù)MySpace的技術人員說，以后還可以按照這種模式以更小粒度劃分架構，從而優(yōu)化負荷分擔。

第四代架構—求助于微軟方案

2005年早期，賬戶達到九百萬，MySpace開始用微軟的C#編寫ASP.NET程序。在收到一定成效后，MySpace開始大規(guī)模遷移到ASP.NET。

賬戶達到一千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性能問題，但站點目前的要求已經開始周期性超越SAN的I/O容量——即它從磁盤存儲系統(tǒng)讀寫數(shù)據(jù)的極限速度。

第五代架構—增加數(shù)據(jù)緩存層并轉到支持64位處理器的SQL Server 20052005年春天，MySpace賬戶達到一千七百萬，MySpace又啟用了新的策略以減輕存儲系統(tǒng)壓力，即增加數(shù)據(jù)緩存層——位于Web服務器和數(shù)據(jù)庫服務器之間，其唯一職能是在內存中建立被頻繁請求數(shù)據(jù)對象的副本，如此一來，不訪問數(shù)據(jù)庫也可以向Web應用供給數(shù)據(jù)。

2005年中期，服務賬戶數(shù)達到兩千六百萬時，MySpace因為我們對內存的渴求而切換到了還處于beta測試的支持64位處理器的SQL Server 2005。升級到SQL Server 2005和64位Windows Server 2003后，MySpace每臺服務器配備了32G內存，后于2006年再次將配置標準提升到64G。

事實上，MySpace的Web服務器和數(shù)據(jù)庫仍然經常發(fā)生超負荷，其用戶頻繁遭遇“意外錯誤”和“站點離線維護”等告示，他們不得不在論壇抱怨不停??

MySpace正是在這樣不斷重構站點軟件、數(shù)據(jù)庫和存儲系統(tǒng)中，才一步步走到今天。事實上，MySpace已經成功解決了很多系統(tǒng)擴展性問題，其中存在相當?shù)慕涷炛档梦覀兘梃b。MySpace系統(tǒng)架構到目前為止保持了相對穩(wěn)定，但其技術人員仍然在為SQL Server支持的同時連接數(shù)等方面繼續(xù)攻堅，盡可能把事情做到最好。

(二)Amazon

亞馬遜書店無疑是電子商務發(fā)展的里程碑。2000年到現(xiàn)在，世界網(wǎng)絡業(yè)腥風血雨。Amazon曾經成為網(wǎng)絡泡沫的頭號代表。如今，當這個“最大的泡沫”用幾經易改的數(shù)字把自己變成了堅實的IT巨人。

歷覽Amazon發(fā)展過程，其成功經驗在于，它創(chuàng)造性地進行了電子商務中每一環(huán)節(jié)的探索，包括系統(tǒng)平臺的建設，程序編寫、網(wǎng)站設立、配送系統(tǒng)等等方面。用Amazon當家人貝索斯的話說就是，“在現(xiàn)實世界的商店最有力的武器就是地

段，地段，地段，而對于我們來說最重要的三件事就是技術，技術，技術?！?/p>

(三)eBay

eBay是世界聞名的拍賣網(wǎng)站，eBay公司通信部主管凱文?帕斯格拉夫認為，“eBay成功的最重要原因在于公司管理和服務?！?/p>

其成功的奧秘可以列舉為以下幾點：

①敢為天下先—在網(wǎng)絡尚不普及的時代，eBay率先進入網(wǎng)絡拍賣領域；②依托虛擬商場所產生的特有的“零庫存”是eBay公司取得成功的另一個重要原因。該公司的核心業(yè)務沒有任何庫存風險，所有的商品都是由客戶提供，它只需要負責提供虛擬的拍賣平臺—網(wǎng)絡和軟件。所以，eBay公司的財務報表上不會出現(xiàn)“庫存費用”和“保管費用”等。

③自eBay公司成立開始，它就一直遵循兩條“黃金原則”：建設虛擬社區(qū)，給網(wǎng)民以家的感覺；保證網(wǎng)站穩(wěn)定安全地運行。

二、國內大型網(wǎng)站開發(fā)時的幾點建議

從本節(jié)開始，我們將結合國內外大型IT網(wǎng)站在技術擴展方面的沉痛教訓和成功經驗，探討在如今剛剛開始的Web 2.0時代如何應對國內網(wǎng)站即將面臨的數(shù)據(jù)訪問量增加（甚至是急劇膨脹）的問題，并提出一些供參考的策略和建議。

(四)搭建科學的系統(tǒng)架構

構建大型的商業(yè)網(wǎng)站絕對不可能像構建普通的小型網(wǎng)站一樣一蹴而就，需要從嚴格的軟件工程管理的角度進行認真規(guī)劃，有步驟有邏輯地進行開發(fā)。對于大型網(wǎng)站來說，所采用的技術涉及面極其廣泛，從硬件到軟件、編程語言、數(shù)據(jù)庫、Web服務器、防火墻等各個領域都有了很高的要求，已經不是原來簡單的html靜態(tài)網(wǎng)站所能比擬的。以著名的Yahoo!為例，他們的每一個大型網(wǎng)站工程都需要大量相應專業(yè)人員的參與。

(五)頁面靜態(tài)化

可不要小看純靜態(tài)化的HTML頁面！其實在很多情況下，HTML往往意味著“效率最高、消耗最小”，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實現(xiàn)。但是，對于大量內容并且頻繁更新的網(wǎng)站，我們無法全部手動實現(xiàn)，因此可以開發(fā)相應的自動化更新工具，例如我們常見的信息發(fā)布系統(tǒng)CMS。像我們經常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實現(xiàn)的。信息發(fā)布系統(tǒng)可以實現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面，還能具備頻道管理、權限管理、自動抓取等功能，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不可少的。

(六)存儲問題

存儲也是一個大問題，一種是小文件的存儲，比如圖片這類；另一種是大文件的存儲，比如搜索引擎的索引。

大家知道，對于Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進行分離，這是基本上大型網(wǎng)站都會采用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統(tǒng)壓力，并且可以保證系統(tǒng)不會因為圖片問題而崩潰，在應用服務器和圖片服務器上，可以進行不同的配置優(yōu)化以保證更

高的系統(tǒng)消耗和執(zhí)行效率。

(七)數(shù)據(jù)庫技術—集群和庫表散列

對于大型網(wǎng)站而言，使用大型的數(shù)據(jù)庫服務器是必須的事情。但是，在面對大量訪問的時候，數(shù)據(jù)庫的瓶頸仍然會顯現(xiàn)出來，這時一臺數(shù)據(jù)庫將很快無法滿足應用，于是我們需要借助于數(shù)據(jù)庫集群或者庫表散列技術。

在數(shù)據(jù)庫集群方面，很多數(shù)據(jù)庫廠商都有自己的解決方案，Oracle、Sybase、SQL Server等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案。因此，你使用了什么樣的數(shù)據(jù)庫，就參考相應的解決方案來實施即可。

上面提到的數(shù)據(jù)庫集群由于在架構、成本、擴張性方面都會受到所采用數(shù)據(jù)庫類型的限制，于是我們需要從應用程序的角度來考慮改善系統(tǒng)架構，其中，庫表散列是常用并且最有效的解決方案。我們在應用程序中安裝業(yè)務和應用或者功能模塊將數(shù)據(jù)庫進行分離，不同的模塊對應不同的數(shù)據(jù)庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數(shù)據(jù)庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴展性。在這一方面一個現(xiàn)成的例子就是搜狐。它的論壇就是采用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數(shù)據(jù)庫分離，然后對帖子、用戶按照板塊和ID進行散列數(shù)據(jù)庫和表，最終可以在配置文件中進行簡單的配置便能讓系統(tǒng)隨時增加一臺低成本的數(shù)據(jù)庫進來補充系統(tǒng)性能。

(八)緩存策略

這絕對不單指低級的緩存技術相關的編程，應從整個架構角度著眼，深入研究Web服務器、數(shù)據(jù)庫服務器的各層級的緩沖策略，最后才是低級的緩沖技術的編程。不同的Web服務器、數(shù)據(jù)庫服務器及Web編程語言都有自己不同的緩沖策略。例如數(shù)據(jù)庫存儲方面，SQL Serve 2005中的主動式緩存機制，Oracle數(shù)據(jù)的cache group技術，Hibernate的緩存包括Session的緩存和SessionFactory的緩存；Web服務器方面，Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力，IIS緩沖器技術；至于web開發(fā)語言，所用緩存技術更存在很大不同，例如ASP.NET 2.0中提出了兩種緩存應用程序數(shù)據(jù)和緩存服務頁輸出的策略，這兩種緩存技術相互獨立但不相互排斥，PHP有Pear的Cache模塊，等等。

(九)鏡像

鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術可以解決不同網(wǎng)絡接入商和地域帶來的用戶訪問速度差異。在鏡像的細節(jié)技術方面，這里不闡述太深，有很多專業(yè)的現(xiàn)成的解決架構和產品可選。也有廉價的通過軟件實現(xiàn)的思路，比如Linux上的rsync等工具。

(十)負載均衡

負載均衡將是大型網(wǎng)站解決高負荷訪問和大量并發(fā)請求采用的終極解決辦法。

負載均衡技術發(fā)展了多年，有很多專業(yè)的服務提供商和產品可以選擇，基于LAMP

解決方案的Lighttped+Squid是相當不錯的解決負載均衡和加速系統(tǒng)的有效方式。

(十一)硬件四層交換

第四層交換使用第三層和第四層信息包的報頭信息，根據(jù)應用區(qū)間識別業(yè)務流，將整個區(qū)間段的業(yè)務流分配到合適的應用服務器進行處理。第四層交換功能就象是虛IP，指向物理服務器。它傳輸?shù)臉I(yè)務服從的協(xié)議多種多樣，有HTTP、FTP、NFS、Telnet或其他協(xié)議。這些業(yè)務在物理服務器基礎上，需要復雜的載量平衡算法。在IP世界，業(yè)務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區(qū)間則由源端和終端IP地址、TCP和UDP端口共同決定。

在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。(十二)軟件四層交換

大家知道了硬件四層交換機的原理后，基于OSI模型來實現(xiàn)的軟件四層交換也就應運而生，這樣的解決方案實現(xiàn)的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有余的。

一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網(wǎng)站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構里面增減節(jié)點都非常容易。

(十三)軟件投資問題

據(jù)報導，目前國內除了一些上市企業(yè)和特別大知名大公司以外，很少有企業(yè)在成本中考慮正版軟件的購置費用。這種思維極有可能給中國互聯(lián)網(wǎng)帶來噩夢。如果一些公司真正面臨軟件資金方面的困難，完全可以考慮使用開源世界的LAMP解決方案（Linux＋Apache＋MySQL＋Perl、PHP或者Python Web編程語言）；否則，隨著我國加入WTO范圍的不斷擴大，盜版打擊必然越來越嚴。因此，“茍且偷生”必將自食其果。

另外，隨著網(wǎng)絡帶寬日漸提升，WEB 2.0技術必將影響到網(wǎng)絡世界的幾乎每一個角落。因此，如何積聚技術人員進行技術攻關并進一步加強安全防范也成為一個日益嚴峻的問題，宜盡早納入到公司的議事日程。

四、總結

中國電子商務真正理性發(fā)展的一個標志，是大量的傳統(tǒng)企業(yè)實實在在地開始用互聯(lián)網(wǎng)來處理商務、做生意，而現(xiàn)在這樣的浪潮已經開始。北京發(fā)行集團，聯(lián)合SINA、6688.com等單位共同推出的網(wǎng)上虛擬書店—新新書店就是這樣的一個標志。

隨著網(wǎng)絡帶寬日漸提升，隨著網(wǎng)絡理念和WEB 2.0技術的斷深入人心，各種B2B、B2C、C2C等電子商務模式很可能以立體交叉方式整合到各種大型商務網(wǎng)站中來。因此，作為公司的技術人員，作為臨危救駕的“白衣騎士”，如何應對海量存儲、海量訪問問題，海量信息檢索的問題，日益嚴峻的安全問題，等等，已經刻不容緩。

第二篇：PHP技術：大型網(wǎng)站架構不得不考慮的10個問題

PHP技術：大型網(wǎng)站架構不得不考慮的10個問題

這里的大型網(wǎng)站架構只包括高互動性高交互性的數(shù)據(jù)型大型網(wǎng)站，基于大家眾所周知的原因，我們就不談新聞類 和一些依靠HTML靜態(tài)化就可以實現(xiàn)的架構了，我們以高負載高數(shù)據(jù)交換高數(shù)據(jù)流動性的網(wǎng)站為例，比如海內，開心網(wǎng)等類似的web2.0系列架構。我們這里 不討論是PHP還是JSP或者.NET環(huán)境，我們從架構的方面去看問題，實現(xiàn)語言方面并不是問題，語言的優(yōu)勢在于實現(xiàn)而不是好壞，不論你選擇任何語言，架 構都是必須要面對的。

這里討論一下大型網(wǎng)站需要注意和考慮的問題

1、海量數(shù)據(jù)的處理

眾所周知，對于一些相對小的站點來說，數(shù)據(jù)量并不是很大，select和update就可以解決我們面對的問題，本身負載量不是很大，最多再加 幾個索引就可以搞定。對于大型網(wǎng)站，每天的數(shù)據(jù)量可能就上百萬，如果一個設計不好的多對多關系，在前期是沒有任何問題的，但是隨著用戶的增長，數(shù)據(jù)量會是 幾何級的增長的。在這個時候我們對于一個表的select和update的時候(還不說多表聯(lián)合查詢)的成本的非常高的。

2、數(shù)據(jù)并發(fā)的處理

在一些時候，2.0的CTO都有個尚方寶劍，就是緩存。對于緩存，在高并發(fā)高處理的時候也是個大問題。在整個應用程序下，緩存是全局共享的，然 而在我們進行修改的時候就，如果兩個或者多個請求同時對緩存有更新的要求的情況下，應用程序會直接的死掉。這個時候，就需要一個好的數(shù)據(jù)并發(fā)處理策略以及 緩存策略。

另外，就是數(shù)據(jù)庫的死鎖問題，也許平時我們感覺不到，死鎖在高并發(fā)的情況下的出現(xiàn)的概率是非常高的，磁盤緩存就是一個大問題。

3、文件存貯的問題

對于一些支持文件上傳的2.0的站點，在慶幸硬盤容量越來越大的時候我們更多的應該考慮的是文件應該如何被存儲并且被有效的索引。常見的方案是 對文件按照日期和類型進行存貯。但是當文件量是海量的數(shù)據(jù)的情況下，如果一塊硬盤存貯了500個G的瑣碎文件，那么維護的時候和使用的時候磁盤的Io就是 一個巨大的問題，哪怕你的帶寬足夠，但是你的磁盤也未必響應過來。如果這個時候還涉及上傳，磁盤很容易就over了。

也許用raid和專用存貯服務器能解決眼下的問題，但是還有個問題就是各地的訪問問題，也許我們的服務器在北京，可能在云南或者新疆的訪問速度 如何解決?如果做分布式，那么我們的文件索引以及架構該如何規(guī)劃。

所以我們不得不承認，文件存貯是個很不容易的問題

4、數(shù)據(jù)關系的處理

我們可以很容易的規(guī)劃出一個符合第三范式的數(shù)據(jù)庫，里面布滿了多對多關系，還能用GUID來替換INDENTIFY COLUMN 但是，多對多關系充斥的2.0時代，第三范式是第一個應該被拋棄的。必須有效的把多表聯(lián)合查詢降到最低。

5、數(shù)據(jù)索引的問題

眾所周知，索引是提高數(shù)據(jù)庫效率查詢的最方面最廉價最容易實現(xiàn)的方案。但是，在高UPDATE的情況下，update和delete付出的成本 會高的無法想想，筆者遇到過一個情況，在更新一個聚焦索引的時候需要10分鐘來完成，那么對于站點來說，這些基本上是不可忍受的。

索引和更新是一對天生的冤家，問題A，D，E這些是我們在做架構的時候不得不考慮的問題，并且也可能是花費時間最多的問題。

6、分布式處理

對于2.0網(wǎng)站由于其高互動性，CDN實現(xiàn)的效果基本上為0，內容是實時更新的，我們常規(guī)的處理。為了保證各地的訪問速度，我們就需要面對一個 絕大的問題，就是如何有效的實現(xiàn)數(shù)據(jù)同步和更新，實現(xiàn)各地服務器的實時通訊有是一個不得不需要考慮的問題。

7、Ajax的利弊分析

成也AJAX，敗也AJAX，AJAX成為了主流趨勢，突然發(fā)現(xiàn)基于XMLHTTP的post和get是如此的容易。客戶端get或者post 到服務器數(shù)據(jù)，服務器接到數(shù)據(jù)請求之后返回來，這是一個很正常的AJAX請求。但是在AJAX處理的時候，如果我們使用一個抓包工具的話，對數(shù)據(jù)返回和處 理是一目了然。對于一些計算量大的AJAX請求的話，我們可以構造一個發(fā)包機，很容易就可以把一個webserver干掉。

8、數(shù)據(jù)安全性的分析

對于HTTP協(xié)議來說，數(shù)據(jù)包都是明文傳輸?shù)?，也許我們可以說我們可以用加密啊，但是對于G問題來說的話，加密的過程就可能是明文了(比如我們 知道的QQ，可以很容易的判斷他的加密，并有效的寫一個跟他一樣的加密和解密方法出來的)。當你站點流量不是很大的時候沒有人會在乎你，但是當你流量上來 之后，那么所謂的外掛，所謂的群發(fā)就會接踵而來(從qq一開始的群發(fā)可見端倪)。也許我們可以很的意的說，我們可以采用更高級別的判斷甚至HTTPS來實 現(xiàn)，注意，當你做這些處理的時候付出的將是海量的database，io以及CPU的成本。對于一些群發(fā)，基本上是不可能的。筆者已經可以實現(xiàn)對于百度空 間和qq空間的群發(fā)了。大家愿意試試，實際上并不是很難。

9、數(shù)據(jù)同步和集群的處理的問題

當我們的一臺databaseserver不堪重負的時候，這個時候我們就需要做基于數(shù)據(jù)庫的負載和集群了。而這個時候可能是最讓人困擾的的問 題了，數(shù)據(jù)基于網(wǎng)絡傳輸根據(jù)數(shù)據(jù)庫的設計的不同，數(shù)據(jù)延遲是很可怕的問題，也是不可避免的問題，這樣的話，我們就需要通過另外的手段來保證在這延遲的幾秒 或者更長的幾分鐘時間內，實現(xiàn)有效的交互。比如數(shù)據(jù)散列，分割，內容處理等等問題。

10、數(shù)據(jù)共享的渠道以及OPENAPI趨勢

Openapi已經成為一個不可避免的趨勢，從google，facebook，myspace到海內校內，都在考慮這個問題，它可以更有效的 留住用戶并激發(fā)用戶的更多的興趣以及讓更多的人幫助你做最有效的開發(fā)。這個時候一個有效的數(shù)據(jù)共享平臺，數(shù)據(jù)開放平臺就成為必不可少的途徑了，而在開放的 接口的情況保證數(shù)據(jù)的安全性和性能，又是一個我們必須要認真思考的問題了。

第三篇：網(wǎng)站架構設計技術方案(火車票訂票系統(tǒng))

xxx市xxxxx網(wǎng)管理中心

火 車 票 網(wǎng) 絡 訂 票 系 統(tǒng) 方 案

二零一二年二月 總體設計說明...............................................................................................................................2

1.1 項目概述...........................................................................................................................2 1.2 建設目標...........................................................................................................................2 1.3 建設原則...........................................................................................................................2 2 系統(tǒng)需求分析...............................................................................................................................3

2.1 服務器集群.......................................................................................................................3 2.2 負載均衡...........................................................................................................................3 2.3 數(shù)據(jù)庫集群與庫表散列...................................................................................................3 2.4 劃分服務器....................................................................................................................4 2.5 不同網(wǎng)絡用戶的訪問問題...........................................................................................4 3 系統(tǒng)架構設計...............................................................................................................................4

3.1 網(wǎng)站物理架構................................................................................................................4 3.2 Web應用開發(fā)架構.........................................................................................................5 3.3 網(wǎng)絡拓撲結構................................................................................................................6 4 架構方案所涉及的技術...............................................................................................................7

4.1 負載均衡.........................................................................................................................7 4.2 頁面靜態(tài)化.......................................................................................................................8 4.3 MVC架構..........................................................................................................................9 4.4 CDN和鏡像網(wǎng)站技術..................................................................................................10 5 網(wǎng)站的硬件擴容和升級.............................................................................................................11 5.1 增加服務器.....................................................................................................................11 5.2 升級服務器..................................................................................................................11 5.3 增加存儲.......................................................................................................................11 5.4 網(wǎng)絡擴容.......................................................................................................................12

實習生：楊茂饒

火車票網(wǎng)絡訂票系統(tǒng)設計方案 總體設計說明

1.1 項目概述

本次火車票網(wǎng)絡訂票系統(tǒng)項目是因為當前鐵路局網(wǎng)上訂票系統(tǒng)設計不合理造成用戶訂票難等原因而要求重新設計的。我們先前的火車票網(wǎng)絡訂票系統(tǒng)最主要的問題是在遭受高負載的情況下系統(tǒng)不能正常的運行，所以此問題也是該方案所要重點解決的。當此項目建成后，我們的火車票網(wǎng)絡訂票系統(tǒng)將大大減輕實地售票系統(tǒng)、電話訂票系統(tǒng)的壓力，使用戶足不出戶就能享受快速、高效的訂票服務。

1.2 建設目標

該訂票系統(tǒng)的設計要能解決當前網(wǎng)絡訂票系統(tǒng)訂票難的問題，在高負載情況下要保證系統(tǒng)的正常工作。系統(tǒng)的建設要符合國家標準，必須要能滿足當前大量用戶的訂票需求，能承受或杜絕同一個用戶頻繁對頁面的點擊所產生的流量。充分發(fā)揮訂票系統(tǒng)的作用和效益。該系統(tǒng)采用先進成熟的技術進行建設并能根據(jù)需要為以后系統(tǒng)的升級做好準備。

1.3 建設原則

1.3.1 實用性

本次火車票訂票系統(tǒng)要根據(jù)當前用戶訂票需求情況和系統(tǒng)未來的規(guī)劃進行設計。結合實際使系統(tǒng)的性價比達到最高。1.3.2 可靠性

系統(tǒng)的設計要使之能長期穩(wěn)定的運行，當遇到問題的時候還要能夠快速有效的恢復。1.3.3 安全性

確保系統(tǒng)的線路設計和設備是否能安全正常工作，保證用戶信息不向外泄漏。

1.3.4 兼容性與擴展性

本次網(wǎng)絡訂票系統(tǒng)的設計上采用先進成熟的技術設備，以保障系統(tǒng)的高效運行，也是為系統(tǒng)的擴充和升級做好準備。1.3.5 專業(yè)性

系統(tǒng)的設計遵照國家標準，符合國家要求。1.3.6 易管理性

系統(tǒng)的設計要便于管理，方便日常維護中的操作。系統(tǒng)需求分析

由于火車票網(wǎng)絡訂票系統(tǒng)建成后是為我們中國13億人提供訂票服務的，將不可避免的遭受由大量網(wǎng)頁點擊造成的網(wǎng)絡高流量、高負載的情況。所以要求此系統(tǒng)要能克服這種嚴重的狀況，保證整個系統(tǒng)正常、安全、可靠的運行。最終方便用戶訂票。

為了滿足以上要求，該方案需要采取服務器集群、負載均衡、數(shù)據(jù)庫劃分、圖片服務器分離等，不僅如此，還要考慮不同網(wǎng)絡用戶的訪問問題。

2.1 服務器集群

服務器集群就是指把很多的服務器統(tǒng)一集中起來進行同一種服務，在客戶端看起來就像是只有一個服務器在提供服務。集群可以利用多個計算機進行并行計算從而獲得更高的計算速度，也可以使用多個計算機做備份，并且能使其中一臺計算機壞了后整個系統(tǒng)依然能正常運行。此系統(tǒng)采用服務器集群技術，集群內的服務器能并發(fā)的處理來自網(wǎng)絡的訪問請求，當訪問量過大時，各服務器共同承擔訪問處理的任務，這將大幅的提高系統(tǒng)的工作效率。除此之外，還可以根據(jù)需求添加集群中服務器的數(shù)量以增大集群的處理能力。

2.2 負載均衡

負載均衡就是把從網(wǎng)絡中傳輸進系統(tǒng)的流量根據(jù)系統(tǒng)的實際工作情況進行分流和劃分，然后再傳輸?shù)礁鞣掌鬟M行處理。在此方案中將采用負載均衡器和Squid/Nginx反向代理服務器實現(xiàn)此功能，負載均衡器需要被放置在臨近服務器集群的位置。由于采用的是服務器集群技術，但當網(wǎng)站系統(tǒng)訪問量很大時，Web服務器集群里的各個服務器壓力都會很大，所以我們使用負載均衡器來管理這些訪問請求，把這些訪問請求傳輸給集群中有空閑資源的服務器進行處理。這樣就能充分的利用服務器集群的優(yōu)勢，不至于因為集群內一臺服務器資源耗盡或出現(xiàn)故障而中斷服務。

2.3 數(shù)據(jù)庫集群與庫表散列

數(shù)據(jù)庫服務器在整個系統(tǒng)的地位非常的重要，因為網(wǎng)站的瓶頸問題大都出現(xiàn)在數(shù)據(jù)庫身上。大型網(wǎng)站都有復雜的應用，這些應用必須使用數(shù)據(jù)庫，在面對大量訪問的時候，數(shù)據(jù)庫的瓶頸很快就能顯現(xiàn)出來，這時一臺數(shù)據(jù)庫將很快無法滿足應用，于是我們需要使用數(shù)據(jù)庫集群或者庫表散列。

1.數(shù)據(jù)庫集群

在數(shù)據(jù)庫集群方面，不同類型的數(shù)據(jù)庫都有自己不同的解決方案，使用了什么樣的數(shù)據(jù)庫，就參考相應的解決方案。

2.庫表散列

在應用程序中安裝業(yè)務和應用或者功能模塊將數(shù)據(jù)庫進行分離，不同的 3

模塊對應不同的數(shù)據(jù)庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數(shù)據(jù)庫散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴展性。

2.4 劃分服務器

按服務器種類來劃分，我們一般把服務器劃分為：圖片服務器、頁面服務器、數(shù)據(jù)庫服務器、應用服務器、日志服務器等。對于訪問量大的網(wǎng)站而言，分離單獨的服務器是非常必要的。分離服務器后各個服務器只需要完成各自的功能和處理任務，這樣把工作細化后系統(tǒng)的整體運行效率也會提升很多。

2.5 不同網(wǎng)絡用戶的訪問問題

由于處于不同網(wǎng)絡服務商的計算機想要相互通訊會比在同一網(wǎng)絡服務商的計算機慢。為了解決此問題，本系統(tǒng)將通過引入CDN和鏡像網(wǎng)站技術來解決不同網(wǎng)絡服務商的接入速度問題。系統(tǒng)架構設計

3.1 網(wǎng)站物理架構

用戶瀏覽頁面負載均衡器1...服務器1服務器2服務器3服務器2代理服務器集群（Nginx）服務器n服務器2...服務器1服務器2服務器1服務器2服務器1服務器2服務器1服務器n圖片服務器集群Web服務器集群AWeb服務器集群BSquid服務器集群

整個系統(tǒng)架構組成如圖所示，該架構有負載均衡器、Nginx代理服務器集群

或Squid代理服務器集群以及其他種類的服務器集群。這樣的架構設計能夠使該系統(tǒng)在高負載的情況下依然能正常工作，同時系統(tǒng)的安全性因為有代理服務器集群的存在也會得到相當大的提高。3.1.1架構中的代理服務器

代理服務器是介于客戶端和Web服務器之間的另一種服務器的存在，有了它之后，瀏覽器不能直接到Web服務器去取回網(wǎng)頁，而是向代理服務器發(fā)出請求，信號會先傳送到代理服務器，由代理服務器來取回瀏覽器所需要的信息并傳回瀏覽器。

很多代理服務器都有很大的存儲空間，它能不斷的將新取得的數(shù)據(jù)存儲到它本機的存儲器上，如果瀏覽器所請求的數(shù)據(jù)在它本機存儲器上有而且是最新的，那么它就不再從Web服務器上讀取數(shù)據(jù)，而是直接將存儲器上的數(shù)據(jù)直接傳送給用戶的瀏覽器，起到系統(tǒng)緩存的作用。這樣就能顯著的提高瀏覽器的速度和效率。

除了緩存功能之外，代理服務器還能連接內網(wǎng)與Internet充當防火墻。這是因為所有內部的主機通過代理服務器訪問外界時，只映射為一個IP地址，所以外界不能直接訪問到內部網(wǎng)絡；同時還可以設置IP地址過濾，限制內外網(wǎng)絡之間的相互訪問。所以本系統(tǒng)中采用代理服務器集群技術是對整個系統(tǒng)的安全是大有裨益的。

3.1.2 架構中的Web服務器

Web服務器是指駐留于因特網(wǎng)上某類計算機的的程序。當客戶端的Web瀏覽器連接到服務器上并請求文件時，服務器將處理該請求并將文件發(fā)送到瀏覽器上，文件附帶的信息（文件類型）會告訴瀏覽器如何查看該文件。服務器使用Http超文本傳輸協(xié)議進行信息交流。Web服務器不僅能夠存儲信息，還能在用戶通過Web瀏覽器提供的信息基礎上運行程序。3.1.3 圖片服務器分離

對于Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進行分離。這樣的架構可以降低提供頁面訪問請求的服務器系統(tǒng)壓力，并且可以保證系統(tǒng)不會因為圖片問題而崩潰。

3.2 Web應用開發(fā)架構

Web應用開發(fā)采用MVC架構。把各種應用程序劃分為視圖、模型和控制三部分。大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的語言來創(chuàng)建的。它們將像數(shù)據(jù)庫查詢語句這樣的數(shù)據(jù)層代碼和像HTML這樣的表示層代碼混在一起。要想使用多種方式來訪問我們的應用程序，就必須要把數(shù)據(jù)從表示層中分離開來，如此就要運用到MVC架構。

如圖：

現(xiàn)在科技的發(fā)展和用戶需求不斷的提升要求我們提供越來越多的方式來訪問應用程序。MVC模式允許用戶使用各種不同樣式的視圖來訪問同一個服務器端的代碼。它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由于模型返回的數(shù)據(jù)沒有進行格式化，所以同樣的構件能被不同的界面使用。例如，很多數(shù)據(jù)可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現(xiàn)方式，而控制層和模型層無需做任何改變。

3.3 網(wǎng)絡拓撲結構

主防火墻備防火墻主交換機VRRP備交換機負載均衡器1負載均衡器2...服務器2服務器1服務器n服務器1服務器n服務器2服務器2服務器2...服務器2服務器1服務器n服務器1服務器n服務器1服務器n服務器1服務器2代理服務器集群（Nginx）網(wǎng)站服務器集群圖片服務器集群應用服務器集群光纖交換機生產DB服務器集群查詢DB服務器組管理終端光纖交換機磁盤陣列柜磁盤陣列柜

3.3.1 采用雙防火墻雙交換機，保障平臺服務

本系統(tǒng)采用雙防火墻接通互聯(lián)網(wǎng)，在任何一個防火墻或者互聯(lián)網(wǎng)發(fā)生故障后都可以自動的將流量切換到另一端，保證網(wǎng)站的正運行，設備或網(wǎng)絡的故障恢復后，自動恢復先前的運行狀況。不但如此，系統(tǒng)所采用的雙千兆交換機分別接在2臺防火墻上，當其中某臺設備或者網(wǎng)絡鏈路發(fā)生故障后，好的設備自動接管已壞設備的工作，不影響網(wǎng)站的整體運行，根據(jù)真實服務器的數(shù)量，交換機還可以隨時增加。

3.3.2 采用硬件設備負載均衡器，實現(xiàn)網(wǎng)絡流量的負載均衡

使用硬件設備負載均衡器，將網(wǎng)絡流量均衡的分擔到WEB服務器集群的各節(jié)點服務器，保障平臺服務器資源均衡的使用。3.3.3 采用數(shù)據(jù)庫集群和庫表散列

本系統(tǒng)采用了數(shù)據(jù)庫集群和庫表散列技術，將大幅提高數(shù)據(jù)庫的存取和查詢的處理能力，不僅如此，在本方案中還為集群配置了磁盤陣列，可以在極大程度上增加數(shù)據(jù)庫的存儲空間。架構方案所涉及的技術

4.1 負載均衡

4.1.1 基于DNS的負載均衡

DNS負載均衡技術是最早的解決負載均衡的技術。主要是這樣實現(xiàn)的，由于在DNS服務器中可以為不同的網(wǎng)絡地址配置同一個域名，在DNS服務器進行解析時，它隨即的得到其中一個地址。所以對于同一個域名它所解析出的地址是會不同的，用戶也就訪問不了同地址的Web服務器，從而在一定程度上能起到均衡負載的作用。但基于DNS的負載均衡不是真正意義上的負載均衡，由于DNS服務器在進行地址解析時不會考慮到當前Web服務器的負載情況，如果其中一臺Web服務器出現(xiàn)了故障，DNS服務器仍然回把地址解析到此臺出現(xiàn)故障的服務器上，導致不能響應客戶端。所以在這種情況下必然會導致很大一部分用戶不能享受服務器所提供的服務。

4.1.2 基于硬件四層交換的負載均衡

本網(wǎng)站架構就使用了基于硬件四層交換的硬件設備，在硬件四層交換產品中有很多的產品可以選擇，大多數(shù)的這些產品都是比較昂貴的，但都能提供與之相符合的功能，都是物有所值的。4.1.3 基于軟件四層交換的負載均衡

軟件四層交換的均衡負載可以使用Linux操作系統(tǒng)中的LVS來解決。4.1.4 通過反向代理服務器來實現(xiàn)負載均衡

反向代理服務器又稱為Web加速服務器，它位于Web服務器的前端，充當WEB 7

服務器的內容緩存器,反向代理服務器是專門針對Web服務器設置的，在后臺運行的Web服務器對互聯(lián)網(wǎng)用戶是透明的、不可見的，用戶只能看到反向代理服務器的網(wǎng)絡地址，但卻不清楚后臺的Web服務器是如何組織架構的。當互聯(lián)網(wǎng)用戶請求Web服務時，DNS服務器將所請求的域名解析為反向代理服務器的IP地址，這樣 URL請求將會被發(fā)送到反向代理服務器，由反向代理服務器負責處理用戶的請求與應答并與后臺Web服務器進行交互。如此就利用反向代理服務器減輕了后臺Web服務器的負載，提高了訪問速度，同時也避免了因用戶直接與Web服務器通信帶來的安全隱患。如圖所示：

目前有許多反向代理軟件，比較有名的有Nginx和 Squid。

4.2 頁面靜態(tài)化

4.2.1 什么是靜態(tài)頁面

靜態(tài)頁面是網(wǎng)頁的代碼都在頁面中，不需要執(zhí)行asp,php,jsp,.net等程序生成客戶端網(wǎng)頁代碼的網(wǎng)頁。靜態(tài)頁面不能自主管理發(fā)布更新頁面。常見的靜態(tài)頁面有以.html擴展名結尾的、.htm擴展名結尾的頁面。還有一點是必須注意的，靜態(tài)頁面并非是網(wǎng)頁上沒有動畫就是靜態(tài)頁面。4.2.2 什么是動態(tài)頁面

動態(tài)頁面是通過執(zhí)行asp,php,jsp,.net等程序生成客戶端網(wǎng)頁代碼的網(wǎng)頁。動態(tài)頁面通?？梢酝ㄟ^網(wǎng)站后臺管理系統(tǒng)對網(wǎng)站內容進行更新管理。發(fā)布新聞，發(fā)布公司產品，交流互動，博客，網(wǎng)上調查等，這都是動態(tài)網(wǎng)站的一些功能，也是我們經常使用的。動態(tài)頁面常見的擴展命有asp,php,jsp,cgi,.aspx等。當中需要我們注意的是動態(tài)頁面的動態(tài)是指網(wǎng)站與客戶端用戶互動的意思，而并非網(wǎng)頁上有動畫就是動態(tài)頁面。4.2.3 頁面靜態(tài)化

靜態(tài)的HTML頁面嚴格地由標準的HTML標示語言構成，并不需要服務器端即時運算生成。這意味著對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務器端只是簡單地將該文檔傳輸?shù)娇蛻舳恕姆掌鬟\行的那個時間片來看，這個傳輸過程僅僅占用了很小的CPU資源。

頁面靜態(tài)化就是采用效率最高、消耗最小的純靜態(tài)化的html頁面來替換動態(tài)頁面。我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實現(xiàn)，這個最簡單的方法其實也是最有效的方法。

4.3 MVC架構

MVC是一個設計模式，它強制性的把應用程序的輸入、處理和輸出分開。使用MVC將應用程序分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。4.3.1 視圖

視圖是用戶看到并與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，要求要以不同的界面呈現(xiàn)。如何處理應用程序的界面變得越來越有挑戰(zhàn)性。MVC一個大的好處是它能為你的應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發(fā)生，作為視圖來講，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。4.3.2 模型

模型表示企業(yè)數(shù)據(jù)和業(yè)務規(guī)則。在MVC的三個部件中，模型擁有最多的處理任務。例如對數(shù)據(jù)庫的處理。被模型返回的數(shù)據(jù)是中立的，就是說模型與數(shù)據(jù)格式無關，這樣一個模型能為多個視圖提供數(shù)據(jù)。由于應用于模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。4.3.3 控制器

控制器接受用戶的輸入并調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發(fā)送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求并決定調用哪個模型構件去處理請求，然后再確定用哪個視圖來顯示返回的數(shù)據(jù)。4.3.4 MVC應用優(yōu)勢

1.適用性

MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼。滿足了用戶不同方式的訪問需求。

2.快速部署

使用MVC模式使開發(fā)時間得到相當大的縮減，它使程序員集中精力于業(yè)務邏輯，界面程序員集中精力于表現(xiàn)形式上。

3.可維護性

分離視圖和業(yè)務邏輯也使得WEB應用更易于維護和修改。在維護過程中可以細化和減少工作量。

4.4 CDN和鏡像網(wǎng)站技術

由于網(wǎng)站的用戶可能在不同的網(wǎng)絡運營商的網(wǎng)絡中，不同網(wǎng)絡中信息的交互會比在同一網(wǎng)絡中慢。為了解決這個問題，本方案就采用了CDN技術和鏡像網(wǎng)站技術。

用戶動態(tài)內容（社區(qū)、投票、調查、搜索、點評、視頻）靜態(tài)內容（靜態(tài)網(wǎng)頁、圖片）DNS解析電信用戶網(wǎng)通用戶CDN其他用戶服務器1服務器n服務器1服務器n服務器1服務器n電信機房多線機房網(wǎng)通機房

4.4.1 鏡像網(wǎng)站

鏡像網(wǎng)站是指將一個完全相同的站點放到幾個服務器上，分別都可以有自己的網(wǎng)址，這些服務器上的網(wǎng)站就稱為鏡像網(wǎng)站。鏡像網(wǎng)站和主站并沒有什么太大的差別，或者可以說是主站的拷貝。鏡像網(wǎng)站的主要優(yōu)點是，用戶如果不能對主站進行正常的訪問（如服務器故障，網(wǎng)絡故障或者是網(wǎng)速太慢），仍然能通過訪

問鏡像服務器獲得服務。

所以在本次方案中，我們可以在不同的網(wǎng)絡運營商部署web服務器，通過軟件工具自動同步到不同網(wǎng)絡接入商的web服務器上，以作為主站的鏡像。然后通過配置智能DNS解析來引導不同網(wǎng)絡的訪問用戶到對應的網(wǎng)絡運營商的web服務器。

4.4.2 CDN技術

CDN的全稱是Content Delivery Network，即內容分發(fā)網(wǎng)絡。其基本思想是盡可能的避開互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的環(huán)節(jié)，使內容的傳輸速度更快、更穩(wěn)定。通過在網(wǎng)絡各處放置節(jié)點服務器所構成的在現(xiàn)有互聯(lián)網(wǎng)基礎之上的一層智能虛擬網(wǎng)絡，CDN系統(tǒng)能夠實時的根據(jù)網(wǎng)絡流量和各節(jié)點的連接、負載狀況以及到各用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務器節(jié)點上。其根本目的是使用戶可以就近的獲取所需內容，避開Internet網(wǎng)絡擁擠的狀況，提高用戶訪問網(wǎng)站的響應速度。從技術上全面解決由于網(wǎng)絡帶寬小、用戶訪問量大、網(wǎng)點分布不均等原因所造成的用戶訪問網(wǎng)站響應速度慢的問題。網(wǎng)站的硬件擴容和升級

根據(jù)當今時代的發(fā)展，中國將會有越來越多的人群加入網(wǎng)民的行列，當然也就會有更多的人愿意通過互聯(lián)網(wǎng)來購票。所以隨著用戶的不斷增多，為了滿足用戶的需求，網(wǎng)站對今后的發(fā)展和升級也是要必須考慮的。

5.1 增加服務器

當集群不能滿足用戶的訪問要求時，可以考慮在集群中增加服務器，增大整個集群的訪問處理能力。

當Web對的并發(fā)處理有瓶頸時，增加新的web服務器，把新增的web服務器填加到Web服務器集群中，以增加Web的并發(fā)處理能力。

當數(shù)據(jù)庫有處理壓力時，可以增加數(shù)據(jù)庫服務器，增加數(shù)據(jù)庫服務器加入數(shù)據(jù)庫的集群中。

5.2 升級服務器

當集群中服務器的各項處理能力不能達到要求時，這時就可以考慮對服務器進行升級。對服務器的升級其實和增加服務器的作用相差無幾。但是升級服務器會比增加服務器更加繁瑣而且更加昂貴。所以我們一般都采用增加服務器的方法來解決問題。

5.3 增加存儲

隨著網(wǎng)站的用戶訪問量的擴大和網(wǎng)站的升級，當然所要存儲的信息和數(shù)據(jù)也就會越來越多,以前的服務器磁盤不再能滿足要求。所以此時應當考慮增加磁盤 11

容器或者設立一個新的存儲服務器。

5.4 網(wǎng)絡擴容

由不斷增多的大量的用戶訪問造成了巨大的網(wǎng)絡流量，很可能造成網(wǎng)絡的阻塞。原來的網(wǎng)絡帶寬設計就會無法承受。所以在系統(tǒng)擴容中還要考慮重新申請更大的網(wǎng)絡帶寬。不僅如此，當帶寬增大后，為了適應更大的網(wǎng)絡流量，內網(wǎng)交換機的升級也是必須的。

第四篇：java技術架構

Java技術體系圖

Java程序員

高級特性

反射、泛型、注釋符、自動裝箱和拆箱、枚舉類、可變

參數(shù)、可變返回類型、增強循環(huán)、靜態(tài)導入

核心編程

IO、多線程、實體類、集合類、正則表達式、XML和屬性文件

圖形編程

AWT（Java2D/JavaSound/JMF）、Swing、SWT、JFace

網(wǎng)路編程

Applet、Socket/TCP/UDP、NIO、RMI、CORBA

Java語法基礎

類、抽象類、接口、最終類、靜態(tài)類、匿名類、內部類、異常類、編碼規(guī)范

Java開發(fā)環(huán)境

JDK、JVM、Eclipse、Linux

Java核心編程技術

Java，設計而又非常精巧的語言。學習Java，須從Java開發(fā)環(huán)境開始，到Java語法，再到Java的核心API。

1.Java開發(fā)入門：Java開發(fā)環(huán)境的安裝與使用，包括JDK命令、EclipseIDE、Linux下Java程序的開發(fā)和部署等。

2.Java語法基礎：基于JDK和Eclipse環(huán)境，進行Java核心功能開發(fā)，掌握Java面向對象的語法構成，包括類、抽象類、接口、最終類、靜態(tài)類、匿名類、內部類、異常的編寫。

3.Java核心API：基于JDK提供的類庫，掌握三大核心功能：

A。Java核心編程:包括Java編程的兩大核心功能——Java輸入/輸出流和多線程，以及常用的輔助類庫——實體類、集合類、正則表達式、XML和屬性文件。

B。Java圖形編程：包括Sun的GUI庫AWT（Java2D、JavaSound、JMF）和Swing，IBM和GUI庫SWT和Jface;

C.Java網(wǎng)路編程：Applet組件編程，Socket編程，NIO非阻塞Socket編程、RMI和CORBA分布式開發(fā)。

4.Java高級特性：掌握JDK1.4、JDK5.0、JDK6.0中的Java高級特性，包括反射、泛型、注釋，以及java高級特性——自動裝箱和拆箱、枚舉類、可變參數(shù)、可變返回類型、增強循環(huán)、靜態(tài)導入等。

JavaEE初級軟件工程師

JSF框架開發(fā)技術

配置文件（頁面導航、后臺Bean）、JSF組件庫（JSF EL語言、HTML標簽、事件處理、）、JSF核心庫（格式轉換、輸入驗證、國際化）

Javaweb核心開發(fā)技術

開發(fā)環(huán)境（Eclipse、Linux）

三大組件（JSP、JavaBean、Servlet）

擴展技術（EL、JSTL、Taglib）

網(wǎng)頁開發(fā)技術

HTML、XML、CSS、JavaScript、AJAX

數(shù)據(jù)庫設計技術

SQL、MySql、Oracle、SQLServer、JDBC

Web服務器（Tomcat/Jetty/Resin/JBossWeb）

JavaWeb核心技術：

JavaWeb項目開發(fā)的全過程可以分解為：

網(wǎng)頁開發(fā)+數(shù)據(jù)庫設計——>JavaWeb項目開發(fā)，其中，javaWeb由6項基本技術組成：JSP+JavaBean+Servlet+EL+JSTL+Taglib，而JSF正是將這6種技術進行有機結合的技術框架：

JavaEE中級軟件工程師

四種經典架構SSH1、SSI1、SSH2、SSI2

Struts1表現(xiàn)層框架

入門配置、核心組件、標簽庫、國際化、數(shù)據(jù)檢驗、數(shù)據(jù)庫開發(fā)、Sitemesh集成、集成Hibernate/iBATIS

Struts2表現(xiàn)層框架

入門配置、核心組件、標簽庫、國際化、數(shù)據(jù)校驗、Sitemesh集成轉換器、攔截器、集成Hibernate/iBATIS

Spring業(yè)務層框架

入門配置、IoC容器、MVC、標簽庫、國際化、數(shù)據(jù)校驗、數(shù)據(jù)庫開發(fā)

Hibernate持久層框架

MySQL、Oracle、SQLServer iBATIS持久層框架

MySQL、Oracle、SQLServer

Web服務器（Tomcat/Jetty/Resin/JBossWeb）

Java高級軟件工程師

javaWeb開源技術與框架

工作流、規(guī)則引擎

搜索引擎、緩存引擎、任務調度、身份認證

報表服務、系統(tǒng)測試、集群、負載平衡、故障轉移

JavaWeb分布式開發(fā)技術

JTA（Java事物管理）

JAAS（Java驗證和授權服務）

JNDI（Java命名和目錄服務）

JavaMail（Java郵件服務）

JMS（java信息服務）

WebService(web服務)

JCA（java連接體系）

JMS（java管理體系）

應用服務器（JBossAS/WebLogic/WebSphere）

JavaEE系統(tǒng)架構師

面向云架構（COA）

COA、SaaS、網(wǎng)格計算、集群計算、分布式計算、云計算

面向資源架構（ROA）

ROA、RESI

面向web服務架構（SOA）

WebService、SOA、SCA、ESB、OSGI、EAI

Java設計模式

創(chuàng)建式模式：抽象工廠/建造者/工廠方法/原型/單例

構造型模式：適配器/橋接/組合/裝飾/外觀/享元/代理

行為型模式：責任鏈/命令/解釋器/迭代子/中介者/備忘錄/觀察者/狀態(tài)/策略/模板方法/訪問者

Java與UML建模

對象圖、用例圖、組件圖、部署圖、序列圖、交互圖、活動圖、正向工程與逆向工程

CTO首席技術官

發(fā)展戰(zhàn)略

技術總監(jiān)

團隊提升

團隊建設

項目管理

產品管理

第五篇：基于java技術的軟件開發(fā)架構總結

基于java技術的軟件開發(fā)架構總結

在具體的實現(xiàn)中，表現(xiàn)層可為Struts/JSF等，業(yè)務層、訪問層可為JavaBean或EJB等，資源層一般為數(shù)據(jù)庫。

宏觀上的層次就是這樣，在具體現(xiàn)實中，有如下幾種實現(xiàn)形式：

1，輕量級實現(xiàn)

表現(xiàn)層使用基于MVC的框架，比如Struts或JSF 業(yè)務層使用JavaBean（就是常說的Service）訪問層使用JavaBean（就是常說的DAO）優(yōu)點：

輕量級實現(xiàn)，簡單明了? 缺點：

難以無法實現(xiàn)分布式應用?

以下功能必須通過編程實現(xiàn)?

事務控制? 資源管理（包括組件的創(chuàng)建）?

線程安全問題?

安全性?

2，重量級J2EE實現(xiàn)

表現(xiàn)層依然是基于MVC的框架

訪問層采用實體Bean實現(xiàn)，如果可能最好采用CMP，實現(xiàn)起來更簡潔。此處的實體Bean可以考慮采用本地接口

業(yè)務層一分為二，服務控制器可以由會話Bean充當，用來封裝業(yè)務流程（相當于輕量級實現(xiàn)中的Service），也可以考慮采用本地接口；門面也可以由會話Bean充當（一般來說無狀態(tài)會話Bean足矣），作為業(yè)務層的入口，應該采用遠程接口。優(yōu)點：

以下功能可由EJB容器自動實現(xiàn)，或通過配置實現(xiàn)?

事務控制?

遠程訪問?

線程安全?

資源管理?

安全性?

可以進行分布式應用?

因為采用了EJB，故部分特征可以由裝配人員來配置（比如事務，安全性等），不需要在軟件中硬編碼? EJB組件有更好的重用性?

可利用容器提供的其他企業(yè)級的功能（比如集群，容錯，災難恢復等）?

可以加入MDB（實現(xiàn)異步通訊）等技術? 缺點：

開發(fā)難度較高?

如果不恰當?shù)氖褂脤嶓wBean，會造成效率低下。如果采用CMP，則很多數(shù)據(jù)訪問的操作不能直接實現(xiàn)。?

缺少良好的開發(fā)環(huán)境?

軟件可能依賴于具體的EJB容器? EJB容器可能很貴，開發(fā)軟件也可能很貴?

3，輕量級和重量級J2EE的切換

如果項目有需求，并有充分的時間，還可以通過在表現(xiàn)層和業(yè)務層的交界處加入“業(yè)務代表”（JavaBean + 服務定位器實現(xiàn)）來對表現(xiàn)層隱藏對業(yè)務層訪問的細節(jié)(JavaBean和EJB的訪問方式顯然不同)，只需替換“業(yè)務代表”就可以切換輕量級和重量級兩種實現(xiàn)。舉例說明，一般電話上都有一個P/T開關（脈沖/音頻開關），隨著開關狀態(tài)的不同，撥號時電話機會判斷是使用脈沖撥號還是音頻撥號。

這種架構唯一的缺點就是必須寫兩套實現(xiàn)代碼??

4，輕量級J2EE實現(xiàn)

訪問層通過JavaBean調用ORM框架實現(xiàn)（Hibernate，iBatis等），代碼簡潔，功能完備（相對于EJB 2.x而言），如果用的是Hibernate，可以忽略底層數(shù)據(jù)庫的差異，如果用的是iBatis，則方便對SQL進行優(yōu)化。

業(yè)務層和訪問層依靠AOP框架（如Spring）可以在切面中實現(xiàn)事務，安全性等功能，同時不影響業(yè)務代碼。如果采用Spring，其中已經內置了事物切面，并可以輕易的與主流ORM框架進行整合，實現(xiàn)聲明式的事物管理。當然，更可以使用IoC模式降低組件間的耦合性。優(yōu)點：

可以通過AOP框架實現(xiàn)事物、安全性等功能，同時不影響業(yè)務代碼?

ORM框架比CMP更靈活，比BMP更簡潔（相對于EJB? 2.x而言），運行效率也比較高

如果使用Spring，可以用更簡單的方式實現(xiàn)J2EE中比較復雜的功能?

無需額外的容器?

ORM和AOP框架可以找到免費的開源實現(xiàn)，降低項目成本（不過也有人認為采用開源項目可能綜合成本更高）? 缺點：

非官方框架，缺少文檔、技術支持和業(yè)界經驗?

采用技術太多，學習曲線較高，難以招到合適的程序員（咱們學員可以考慮在這方面下點功夫，呵呵）?

某些企業(yè)級的功能輕量級框架還不能實現(xiàn)（或獨立實現(xiàn)）??????????????????????????????????????????

測試、調試均比較復雜?

另類之處：

使用BMP + Hibernate（具體做法為BMP中的持久化方法，比如ejbLoad, ejbStore等都委托給Hibernate實現(xiàn)）優(yōu)點：

借助于Hibernate強大的ORM功能彌補CMP的不足（特別是EJB-QL）缺點：

事物不好控制

不倫不類，容易發(fā)生未知的錯誤（比如Hibernate自身的緩存可能會于容易提供的緩存沖突）另類之處：

將業(yè)務層（也可能包含訪問層）包裝成Web Services，支持遠程調用 優(yōu)點：

借助于Web Services可以實現(xiàn)松散耦合分布式應用，說的大一點，就是傳說中的SOA，呵呵 缺點：

Web Services自身效率不高，無狀態(tài)，安全性差

當然，即使不分層，也能做出軟件來，但我們應該思考怎么做才能最好？如果說分層不好，那么不分層的優(yōu)勢又在哪里呢？？如果說分層有性能的損耗，那么性能損耗在哪里呢？？如果不分層，軟件工程思想中的“分而治之”的原則啟不受到了質疑？

有人說，分層是為了減少代碼量，如果分層是為了減少代碼量，那怎么能減少，代碼的重用也許會減少一些，但是程序更多的是業(yè)務，我們關心的也只是業(yè)務，試問分層的意義就是為了減少代碼量？

總之我的觀點就是：軟件分層是必須做的。至于框架，不應該問用不用，而應該問用什么？要選用實踐檢驗過的框架，畢竟實踐是檢驗真理的唯一標準。

二年的J2EE開發(fā)之后，我們應該掌握了一些主流的架構模式，總結一下：

宏觀上講，我們采用了分層的架構，將軟件分為如下的層次：