門戶網站架構設計方案

前臺門戶網站架構設計方案北京寬連十方數字技術有限公司2010-7

目錄3網絡規(guī)劃及性能計算4.2測試結果43結果分析1網站的性能瓶頸分析網站的性能影響因素很多，下面主要從如下4個方面進行分析說明:1）網絡負載a）公網負載b）內網負載2）WEB應用服務器性能a）CPUb）存儲，I/O訪問c）內存d）并發(fā)TCP/IP連接數3）數據庫服務器性能a）數據庫參數配置b）服務器性能（CPU、內存、存儲）c）數據結構的合理性4）不同WEB應用的處理方式而對不同的性能瓶頸a）對于靜態(tài)的網站：靜態(tài)的HTML頁面嚴格地由標準的HTML標示語言構成，并不需要服務器端即時運算生成。這意味著，對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務器端只是簡單地將該文檔傳輸到客戶端。從服務器運行的那個時間片來看，這個傳輸過程僅僅占用了很小的CPU資源。對于靜態(tài)HTML的訪問瓶頸為：網絡帶寬、磁盤I/O以及cache（高速緩沖存儲器）。b）對于動態(tài)頁面因為服務器解析動態(tài)頁面必須在其傳輸到客戶端前就通過服務器來進行解釋，這樣就會給應用服務器添加額外的性能消耗，如果進一步要訪問數據庫，則會增加數據庫服務器的性能消耗，則動態(tài)頁面還有額外的瓶頸：應用服務器的性能，數據庫服務器的性能。2系統(tǒng)架構設計2.1總體思路為提高網站的高并發(fā)性能，提高開發(fā)效率及運營效率，主要按如下幾個思路進行規(guī)劃設計：2.1.1負載均衡1）四層交換負載均衡：采用負載均衡器來實現硬件級的四層交換負載均衡，或采用LVS來實現軟件的四層交換負載均衡。2）通過第三方軟件來實現負載均衡,同時實現頁面請求的緩存。通過Nginx實現反向代理服務器集群，同時搭建squid集群以作為靜態(tài)頁面和圖片的緩存。3）通過web服務器的配置來實現負載均衡即通過apache或是Nginx將客戶請求均衡的分給tomcat1,tomcat2....去處理。2.1.2WEB應用開發(fā)架構思路1）應用開發(fā)實現MVC架構三層架構進行web應用開發(fā)2）頁面盡可能靜態(tài)化以減少動態(tài)數據訪問，如果是資訊類的網站可以考慮采用第三方開源的CMS系統(tǒng)來生成靜態(tài)的內容頁面。3）采用Oscache實現頁面緩存，采用Memcached實現數據緩存4）采用獨立的圖片服務器集群來實現圖片資源的存儲及WEB請求2.1.3數據存儲的設計思路1）數據庫拆分，把生產數據庫和查詢數據庫分離，對生產數據庫采用RAC實現數據庫的集群。2）采用高效的網絡文件共享策略，采用圖片服務器來實現頁面的圖片存儲。2.1.4不同網絡用戶訪問考慮1）通過引ACDN來解決不同網絡服務商的接入速度問題，一般只能解決靜態(tài)頁面的訪問問題。2）在不同運營商機房部署服務器，通過鏡像技術來實現不同網絡服務商的接入速度問題。2.2總體架構2.2.1網站的系統(tǒng)分層架構2.2.2網站的物理架構2.2.3網站的開發(fā)架構2.2.4網絡拓撲結構備注：1）采用雙防火墻雙交換機做網絡冗余，保障平臺服務采用雙防火墻通知接通2線路互聯網接入，設備之間采用VRRP協(xié)議，在任何一個防火墻、互聯網發(fā)生故障后均可自動將流量切換到另一端，保證網站的正運行，設備或網絡恢復后，自動恢復。采用雙千兆交換機分別接在2臺防火墻上，當某臺設備或者網絡鏈路發(fā)生故障后，好設備自動接管已壞設備的工作，不影響網站的整體運行，根據業(yè)務及真實服務器的數量，交換機可以隨時增加。2）采用硬件設備負載均衡器，實現網絡流量的負載均衡使用硬件設備負載均衡器，將網絡流量均衡的分擔到WEB服務器集群各節(jié)點服務器，保障平臺服務器資源均衡的使用。3）采用代理服務器，實現軟件級的網絡負載均衡。4）數據庫服務器分離成生產數據庫集群和查詢數據庫集群，實現生產讀寫與后臺查詢統(tǒng)計進行分離，同時生產數據庫采用rac技術進行2.3架構涉及技術的詳解2.3.1負載均衡基于DNS的負載均衡--一個域名綁定多個IPDNS負載均衡技術是最早的負載均衡解決方案，它是通過DNS服務中的隨機名字解析來實現的，在DNS服務器中，可以為多個不同的地址配置同一個名字，而最終查詢這個名字的客戶機將在解析這個名字時得到其中的一個地址。因此，對于同一個名字，不同的客戶機會得到不同的地址，它們也就訪問不同地址上的Web服務器，從而達到負載均衡的目的。這種技術的優(yōu)點是，實現簡單、實施容易、成本低、適用于大多數TCP/IP應用；但是，其缺點也非常明顯，首先這種方案不是真正意義上的負載均衡，DNS服務器將Http請求平均地分配到后臺的Web服務器上，而不考慮每個Web服務器當前的負載情況；如果后臺的Web服務器的配置和處理能力不同，最慢的Web服務器將成為系統(tǒng)的瓶頸，處理能力強的服務器不能充分發(fā)揮作用；其次未考慮容錯，如果后臺的某臺Web服務器出現故障，DNS服務器仍然會把DNS請求分配到這臺故障服務器上，導致不能響應客戶端。最后一點是致命的，有可能造成相當一部分客戶不能享受Web服務，并且由于DNS緩存的原因，所造成的后果要持續(xù)相當長一段時間（一般DNS的刷新周期約為24小時）。所以在國外最新的建設中心Web站點方案中，已經很少采用這種方案了。通過硬件四層交換實現負載均衡在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了通過軟件四層交換實現負載均衡軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是LinuxVirtualServer，他提供了基于心跳線heartbeat的實時災難應對解決方案，提高系統(tǒng)的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對于分布式的系統(tǒng)來說必不可少。一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性。通過反向代理服務器實現負載均衡反向代理服務器又稱為WEB加速服務器，它位于WEB服務器的前端，充當WEB服務器的內容緩存器，反向代理服務器是針對WEB服務器設置的，后臺WEB服務器對互聯網用戶是透明的，用戶只能看到反向代理服務器的地址，不清楚后臺WEB服務器是如何組織架構的。當互聯網用戶請求WEB服務時，DNS將請求的域名解析為反向代理服務器的IP地址，這樣URL請求將被發(fā)送到反向代理服務器，由反向代理服務器負責處理用戶的請求與應答、與后臺WEB服務器交互。利用反向代理服務器減輕了后臺WEB服務器的負載，提高了訪問速度，同時避免了因用戶直接與WEB服務器通信帶來的安全隱患。目前有許多反向代理軟件，比較有名的有Nginx和Squid。Nginx是由IgorSysoev為俄羅斯訪問量第二的Rambler.ru站點開發(fā)的，是一個高性能的HTTP和反向代理服務器，也是一個IMAP/POP3/SMTP代理服務器。Squid是由美國政府大力資助的一項研究計劃，其目的為解決網絡帶寬不足的問題，支持HTTP，HTTPS，FTP等多種協(xié)議，是現在Unix系統(tǒng)上使用、最多功能也最完整的一套軟體。SquidSquid是一個開源的軟件，利用它的反向代理技術可以提高網站系統(tǒng)的訪問速度，下面將重點介紹Squid反向代理的實現原理和在提高網站性能方面的應用。Squid反向代理服務器位于本地WEB服務器和Internet之間，組織架構如下圖：客戶端請求訪問WEB服務時，DNS將訪問的域名解析為Squid反向代理服務器的IP地址，這樣客戶端的URL請求將被發(fā)送到反向代理服務器。如果Squid反向代理服務器中緩存了該請求的資源，則將該請求的資源直接返回給客戶端，否則反向代理服務器將向后臺的WEB服務器請求資源，然后將請求的應答返回給客戶端，同時也將該應答緩存在本地，供下一個請求者使用。Squid反向代理一般只緩存可緩沖的數據(比如html網頁和圖片等)，而一些CGI腳本程序或者ASP、JSP之類的動態(tài)程序默認不緩存。它根據從WEB服務器返回的HTTP頭標記來緩沖靜態(tài)頁面，有四個最重要HTTP頭標記：Last-Modified:告訴反向代理頁面什么時間被修改Expires:告訴反向代理頁面什么時間應該從緩沖區(qū)中刪除Cache-Control:告訴反向代理頁面是否應該被緩沖Pragma:用來包含實現特定的指令，最常用的是Pragma:no-cache注：DNS的輪詢機制將某一個域名解析為多個IP地址。NginxNginx(“enginex”)是俄羅斯人IgorSysoev(塞索耶夫)編寫的一款高性能的HTTP和反向代理服務器。Nginx已經在俄羅斯最大的門戶網站在國內，已經有新浪博客、新浪播客、搜狐通行證、網易新聞、網易博客、金山逍遙網、金山愛詞霸、校內網、YUPOO相冊、豆瓣、迅雷看看等多家網站、頻道使用Nginx服務器。Nginx特點如下:1）工作在OSI模型的第7層（應用層）2）高并發(fā)連接官方測試能夠支撐5萬并發(fā)連接，在實際生產環(huán)境中跑到2?3萬并發(fā)連接數。3）內存消耗少在3萬并發(fā)連接下，開啟的10個Nginx進程才消耗150M內存（15M*10=150M）。4）配置文件非常簡單風格跟程序一樣通俗易懂。5）成本低廉Nginx為開源軟件，可以免費使用。而購買F5BIG-IP、NetScaler等硬件負載均衡交換機則需要十多萬至幾十萬人民幣。6）支持Rewrite重寫規(guī)則能夠根據域名、URL的不同，將HTTP請求分到不同的后端服務器群組。7）內置的健康檢查功能如果NginxProxy后端的某臺Web服務器宕機了，不會影響前端訪問。8）節(jié)省帶寬支持GZIP壓縮，可以添加瀏覽器本地緩存的Header頭。9）穩(wěn)定性高用于反向代理，宕機的概率微乎其微。3）Nginx+squid頁面緩存來實現反向代理負載均衡通過Nginx反向代理和squid緩存實現動靜分離的架構圖如下所示：5.Apache+tomcat集群實現負載均衡。使用apache和多個tomcat配置一個可以應用的web網站，用Apache進行分流，把請求按照權重以及當時負荷分tomcat1,tomcat2...去處理，要達到以下要求：1）Apache做為HttpServer，通過mod_jk連接器連接多個tomcat應用實例，并進行負載均衡。2）同時還要配置session復制，也就是說其中任何一個tomcat的添加的session，是要同步復制到其它tomcat，集群內的tomcat都有相同的session，并為系統(tǒng)（包括Apache和tomcat）設定Session超時時間。2.3.2緩存系統(tǒng)架構方面的緩存1）Squid緩存架構方面使用Squid進行緩存。注：SQUID使用了皿算法，W就是頁面血必尸里時間?*）和Lo炒Modred時間的差。Dote一般是網血從后面取頁面的時間ias山肱odgd一般是頁面生成時間。2）Nginx的緩存功能緩存把URL及相關組合當作Key，用md5編碼哈希后保存；Nginx的Web緩存服務只能為指定URL或狀態(tài)碼設置過期時間，不支持類似Squid的PURGE指令，手動清除指定緩存頁面;采用MMAP實現，設置的緩存區(qū)大小不能超過物理內存+SWEB的值3)基于memd的緩存nginx對memcached有所支持，但是功能并不是特別之強，性能上還是非常之優(yōu)秀。location/mem/{if($uri~f/mem/([0-9A-Za-z_]*)$"){set$memcached_key"$1";}expires70;}Nginx目前沒有寫入memcached的任何機制，所以要往memcached里寫入數據得用后臺的動態(tài)語言完成，可以利用404定向到后端去寫入數據。N“gMc會非常老實地將鏈接形式保存到文件系統(tǒng)中，這樣對于一個鏈接，可以很方便地查閱它在緩存機器上的緩存狀態(tài)和內容，也可以很方便地和別的文件管理器如rsy砌等配合使用，它完完全全就是一個文件系統(tǒng)結構。應用程序方面的緩存OSCacheOSCache由OpenSymphony設計，它是一種開創(chuàng)性的JSP定制標記應用，提供了在現有JSP頁面之內實現快速內存緩沖的功能，OSCache是個一個廣泛采用的高性能的J2EE緩存框架，OSCache能用于任何Java應用程序的普通的緩存解決方案。OSCache有以下特點：緩存任何對象，你可以不受限制的緩存部分jsp頁面或HTTP請求，任何java對象都可以緩存。擁有全面的API--OSCacheAPI給你全面的程序來控制所有的OSCache特性。永久緩存--緩存能隨意的寫入硬盤，因此允許昂貴的創(chuàng)建(expensive-to-create)數據來保持緩存，甚至能讓應用重啟。支持集群--集群緩存數據能被單個的進行參數配置，不需要修改代碼。緩存記錄的過期--你可以有最大限度的控制緩存對象的過期，包括可插入式的刷新策略(如果默認性能不需要時)。OSCache是當前運用最廣的緩存方案，JBoss,Hibernate,Spring等都對其有支持。OSCache的特點：1）緩存任何對象:你可以不受限制的緩存部分jsp頁面或HTTP請求，任何java對象都可以緩存。2）擁有全面的API：OSCacheAPI允許你通過編程的方式來控制所有的OSCache特性。3）永久緩存：緩存能被配置寫入硬盤，因此允許在應用服務器的多次生命周期間緩存創(chuàng)建開銷昂貴的數據。4）支持集群：集群緩存數據能被單個的進行參數配置，不需要修改代碼。5）緩存過期：你可以有最大限度的控制緩存對象的過期，包括可插入式的刷新策略（如果默認性能不能滿足需要時）。2）Memcachedmemcached是高性能的分布式內存緩存服務器。一般的使用目的是，通過緩存數據庫查詢結果，減少數據庫訪問次數，以提高動態(tài)Web應用的速度、提高可擴展性。Memcached是以Key/Value的形式單個對象緩存。3）自主開發(fā)的內存數據緩存服務a）獨立進程方式的緩存服務對于一些常用的動態(tài)數據通過開發(fā)程序服務緩存在內存中，提供給其他子系統(tǒng)調用，如下面的數據就可以通過這樣方式進行緩存。1）用戶基本信息及狀態(tài)的信息緩沖2）列表緩存，就像論壇里帖子的列表3）記錄條數的緩存，比如一個論壇板塊里有多少個帖子，這樣才方便實現分頁。4）復雜一點的group，sum，count查詢，比如積分的分類排名b）集成在WEB應用中的內存緩存在web應用中對于熱點的功能，考慮使用完全裝載到內存，保證絕對的響應速度，對于需要頻繁訪問的熱點數據，采用集中緩存（多個可以采用負載均衡），減輕數據庫的壓力，比如：很多配置信息，操作員信息等等。2.3.3頁面靜態(tài)化靜態(tài)的HTML頁面嚴格地由標準的HTML標示語言構成，并不需要服務器端即時運算生成。這意味著，對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務器端只是簡單地將該文檔傳輸到客戶端。從服務器運行的那個時間片來看，這個傳輸過程僅僅占用了很小的CPU資源。頁面靜態(tài)化就是采用效率最高、消耗最小的純靜態(tài)化的html頁面來替換動態(tài)頁面。我們盡可能使我們的網站上的頁面采用靜態(tài)頁面來實現，這個最簡單的方法其實也是最有效的方法。同時采用第三方開源的CMS系統(tǒng)來實現網站內容的管理。對于大量內容并且頻繁更新的網站，我們無法全部手動去挨個實現頁面靜態(tài)化，所以我們需要引入常見的信息發(fā)布系統(tǒng)CMS），信息發(fā)布系統(tǒng)（CMS）可以實現最簡單的信息錄入自動生成靜態(tài)頁面，對于一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。同時，HTML靜態(tài)化也是某些緩存策略使用的手段，對于系統(tǒng)中頻繁使用數據庫查詢但是內容更新很小的應用，可以考慮使用HTML靜態(tài)化來實現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行后臺管理并且再數據庫中，這些信息其實大量被前臺程序調用，但是更新頻率很小，可以考慮將這部分內容進行后臺更新的時候進行靜態(tài)化，這樣避免了大量的數據庫訪問請求。在進行html靜態(tài)化的時候還可以使用一種折中的方法，就是前端繼續(xù)使用動態(tài)實現，在一定的策略下通過后臺模塊進行定時把動態(tài)網頁生成靜態(tài)頁面，并定時判斷調用，這個能實現很多靈活性的操作。為了提高靜態(tài)HTML的訪問效率，主要可以對以下幾個方面進行優(yōu)化：網絡帶寬、磁盤I/O以及cache（高速緩沖存儲器）。2.3.4數據庫配置及優(yōu)化數據庫集群對生產數據庫采用RAC實現數據庫的集群。數據庫及表的散列把生產數據庫和查詢數據庫進行分離，針對系統(tǒng)業(yè)務數據的特點，把大的表進行拆分，對于訪問較多的表采用分區(qū)表。使用讀/寫數據庫分離，隨著系統(tǒng)變得越來越龐大，特別是當它們擁有很差的SQL時，一臺數據庫服務器通常不足以處理負載。但是多個數據庫意味著重復，除非你對數據進行了分離。更一般地，這意味著建立主/從副本系統(tǒng)，其中程序會對主庫編寫所有的Update、Insert和Delete變更語句，而所有Select的數據都讀取自從數據庫（或者多個從數據庫）。盡管概念上很簡單，但是想要合理、精確地實現并不容易，這可能需要大量的代碼工作。因此，即便在開始時使用同一臺數據庫服務器，也要盡早計劃在PHP中使用分離的DB連接來進行讀寫操作。如果正確地完成該項工作，那么系統(tǒng)就可以擴展到2臺、3臺甚至12臺服務器，并具備高可用性和穩(wěn)定性。擁有良好的DB配置和備份很多公司都沒有良好的備份機制，也不知道如何恰當地完成這項工作。只有imp是不夠的，還需要進行熱備份，從而得到超快的速度和超高的可靠性。另外，在將所有備份文件從服務器上轉移出來之前要進行壓縮和加密。另外還要確保擁有設計合理的、有用的關于安全、性能和穩(wěn)定性問題的設定，包括防止數據敗壞，其中很多設定都是非常重要的。2.3.5文件存儲文件共享1）HDFS（GFS）HDFS是ApacheHadoop項目中的一個分布式文件系統(tǒng)實現，基于Google于2003年10月發(fā)表的GoogleFileSystem（GFS）論文。特性1）硬件要求低2）高容錯性3）易可擴展4）配置簡單5）超大文件HDFS采用master/slave架構。一個HDFS集群是由一個Namenode和一定數目的。atanodes組成。2）NFS與GFS比較首先從它們的功能上進行分析。NFS即網絡文件系統(tǒng)，是由SUN公司開發(fā)的。它是FreeBSD支持的文件系統(tǒng)中的一種，允許一個系統(tǒng)在網絡上與它人共享目錄和文件。通過使用NFS，用戶和程序訪問遠端系統(tǒng)上的文件就像訪問本地文件一樣。而GFS是Google為了滿足本公司迅速增長的數據處理要求而開發(fā)的文件系統(tǒng)。GFS是一個可擴展的分布式文件系統(tǒng)，用于大型的、分布式的、對大量數據進行訪問的應用。它是針對Google的計算機集群進行設計的，專門是為Google頁面搜索的存儲進行了優(yōu)化。所以從功能上看，它們兩者是完全不同的概念。其次從結構上比較，NFS至少包括兩個主要部分：一臺服務器，以及至少一臺客戶機。被共享的目錄和文件存放在服務器上，客戶機遠程地訪問保存在服務器上的數據。GFS則由一臺Master（通常有幾臺備份）和若干臺TrunkServer構成。GFS中文件備份成固定大小的Trunk分別存儲在不同的TrunkServer上，每個Trunk有多份（比如3）拷貝，也存儲在不同的TrunkServer上。Master負責維護GFS中的Metadata，即文件名及其Trunk信息?？蛻舳讼葟腗aster上得到文件的Metadata，根據要讀取的數據在文件中的位置與相應的TrunkServer通信，獲取文件數據。再從跨平臺性上，NFS的基本原則是“容許不同的客戶端及服務端通過一組RPCs分享相同的文件系統(tǒng)”，它是獨立于操作系統(tǒng)的，容許不同的操作系統(tǒng)共同地進行文件的共享。而GFS則沒有這一特點，文件只能被集群系統(tǒng)中的PC所訪問，而且這些PC的操作系統(tǒng)一般是Linux。最后從規(guī)模上比較，HDFS只應用在大批量的數據共享上。目前Google擁有超過200個的最后從規(guī)模上比較，GFS集群，其中有些集群的PC數量超過5000臺。集群的數據存儲規(guī)模可以達到5個PB,并且集群中的數據讀寫吞吐量可達到每秒40G。而NFS一般沒有這么巨大的規(guī)模。文件的多服務器自動同步使用Linux2.6內核的inotify監(jiān)控Linux文件系統(tǒng)事件。利用開源的lsync監(jiān)聽某一目錄，如果目錄內文件發(fā)生增、刪、改，利用Rsync協(xié)議自動同步到多臺服務器。圖片服務器分離特別是如果程序與圖片都放在同一個APAHCE的服務器下，每一個圖片的請求都有可能導致一個HTTPD進程的調用。使用獨立的圖片服務器不但可以避免以上這個情況，更可以對不同的使用性質的圖片設置不同的過期時間，以便同一個用戶在不同頁面訪問相同圖片時不會再次從服務器（基于是緩存服務器）取數據，不但快速，而且還省了帶寬。還有就是，對于緩存的時間上，亦可以做獨立的調節(jié)。2.3.6網絡問題解決方案你不可能要求所有的使用人員，都和你的服務器在一個運營商的網絡內，而不同網絡之間訪問速度會很慢，我們可以采用鏡像網站和引ACDN來解決這一問題。智能DNS解析我們可以在不同的網絡運營商部署web服務器，通過linux上的rsync工具自動同步到不同網絡接入商的web服務器上，以作為主站的鏡像。然后通過配置智能DNS解析來引導不同網絡的訪問用戶到對應的網絡運營商l的web服務器。CDN如果有足夠的投資，也可以采用CDN（內容分發(fā)網），把靜態(tài)內容（靜態(tài)頁面和圖片）進行CDN緩存，以減輕服務器壓力。CDN的全稱是Co*mDeliveryNetwork，即內容分發(fā)網絡。它采取了分布式網絡緩存結構（即國際上流行的瀝c?"e技術），其目的是通過在現有Sfeemet中增加一層新的網絡架構，將網站的內容發(fā)布到最接近用戶的網絡邊緣”，使用戶可以就近取得所需的內容，解決mtemet網絡擁擠的狀況，提高用戶訪問網站的響應速度。從技術上全面解決由于網絡帶寬小、用戶訪問量大、網點分布不均等原因所造成的用戶訪問網站響應速度慢的問題。（也就是一個服務器的內容平均分部到多個服務器上，服務器智能識別，讓用戶獲取離用戶最近的服務器，提高速度。目前，國內訪問量較高的大型網站如新浪網易等，均使用CDN網絡加速技術，雖然網站的訪問巨大，但無論在什么地方訪問都會感覺速度很快。一般的網站如果服務器在網通，電信用戶訪問很慢，如果服務器在電信，網通用戶訪問又很慢。2.3.7WEB應用開發(fā)架構設計思路基于MVC的三層應用開發(fā)架構應用開發(fā)實現MVC三層架構進行web應用開發(fā)，采用ibatis作為持久層框架，c3p0作為數據庫連接池。iBATIS是一個可以設計和實現更好的Java應用程序持久化層的框架°iBATIS把對象和存儲過程或者使用XML描述符的SQL語句進行了關聯。簡單是iBATIS最大的優(yōu)勢ibatis-使用ibatis的十個理由至少能操作10種以上的數據庫可配置的caching（包括從屬）支持DataSource、localtransactionmanagemen和globaltransaction簡單的XML配置文檔支持Map,Collection,List和簡單類型包裝（如Integer,String）支持JavaBeans類（get/set方法）支持復雜的對象映射（如populatinglists,complexobjectmodels）對象模型從不完美（不需要修改）數據模型從不完美（不需要修改）你已經知道SQL，為什么還要學習其他東西1）MVC架構示意2）Struts架構客戶端發(fā)送一個HTTP請求，通過Struts框架最后獲得一個HTTP響應，這一過程非常重要，它是理解Struts框架的重點。上圖描述了Struts框架的結構，而下圖通過一個活動圖更具體描述接受請求直至返回響應的整個過程：面向服務的應用架構面向服務的應用架構是指構建可分布式的、去中心化的服務器平臺，以提供許多不同的應用，數據庫被分成很多個小部分，圍繞每個部分都會創(chuàng)建一個服務接口（API），并且該接口是訪問數據庫的唯一途徑。最終數據庫演變成一個非常龐大的共享資源。這種架構是松散耦合的，并且圍繞著服務進行構建。面向服務的架構提供給他們隔離特性，一個服務可能有很多臺數據庫服務器，他們之間的數據是相通的，而對外他們的接口只有一個，外面是無法知道這個服務后面的數據組織是如何搭建的。這樣就有了越來越多的應用服務器。這些應用服務器從數據眾多的服務（每個服務背后都有數據庫或集群數據庫）中聚合信息，然后生成我們所看到的A的各個網站頁面。這樣各種服務如插件一樣組成了一個開放的平臺，這樣團隊的規(guī)模就會比較小，比較靈活。注Amazon就是采用了這種架構來構建的，它擁有上千臺服務器。2.4系統(tǒng)軟件參數優(yōu)化在一定的架構基礎上，要提高并發(fā)處理能力則需要調整服務器的操作系統(tǒng)內核參數、web服務器（tomcat的參數、apache的參數、Nginx的參數），以使其性能達到最優(yōu)化。2.4.1操作系統(tǒng)優(yōu)化調整系統(tǒng)的內核參數，增大連接數及TCP/IP的超時設置。Linux系統(tǒng)中：在/etc/sysctl.conf配置文件中增加如下內核參數：2.4.2tomcat服務器優(yōu)化增大并發(fā)連接數，調整內存參數的設置。1、JDK內存優(yōu)化：當應用程序需要的內存超出堆的最大值時虛擬機就會提示內存溢出，并且導致應用服務崩潰。因此一般建議堆的最大值設置為可用內存的最大值的80%。Tomcat默認可以使用的內存為128MB，在較大型的應用項目中，這點內存是不夠的，需要調大.Tomcat默認可以使用的內存為128MB,Windows下,在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下設置：JAVA_OPTS='-Xms【初始化內存大小】-Xmx【可以使用的最大內存】’需要把這個兩個參數值調大。例如：JAVA_OPTS='-Xms256m-Xmx512m'表示初始化內存為256MB，可以使用的最大內存為512MB。2、連接器優(yōu)化：在tomcat配置文件server.xml中的配置中，和連接數相關的參數有：maxThreads：Tomcat使用線程來處理接收的每個請求。這個值表示Tomcat可創(chuàng)建的最大的線程數。默認值150。acceptCount：指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理。默認值10。minSpareThreads：Tomcat初始化時創(chuàng)建的線程數。默認值25。maxSpareThreads：一旦創(chuàng)建的線程超過這個值，Tomcat就會關閉不再需要的socket線程。默認值75。enableLookups：是否反查域名，默認值為true。為了提高處理能力，應設置為falseconnnectionTimeout:網絡連接超時，默認值60000，單位：毫秒。設置為0表示永不超時，這樣設置有隱患的。通?？稍O置為30000毫秒。maxKeepAliveRequests：保持請求數量，默認值100。bufferSize：輸入流緩沖大小，默認值2048pression：壓縮傳輸，取值on/off/force，默認值off。其中和最大連接數相關的參數為maxThreads和acceptCount。如果要加大并發(fā)連接數，應同時加大這兩個參數。webserver允許的最大連接數還受制于*作系統(tǒng)的內核參數設置，通常Windows是2000個左右，Linux是1000個左右。apache服務器優(yōu)化加大并發(fā)數量和關閉不需要的模塊。因為apache非常消耗內存，盡量輕量化。Apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率同時配置apache和tomcat的組合使之能作到動靜分離，apache處理靜態(tài)頁面，tomcat處理動態(tài)頁面。在處理靜態(tài)頁面或者圖片、js等訪問方面，可以考慮使用代替Apache，它提供了更輕量級和更高效的處理能力Nginx服務器的優(yōu)化worker_processes：該參數的值最好跟cpu核數相等，能夠發(fā)揮最大性能，如果nginx所在服務器為2顆雙核cpu，則建議設定為4。3Web服務架構評測主要對基于tomcat和nginx+tomca^web服務器的處理性能進行測試，以作為不同性能要求下架構選型的依據3.1測試環(huán)境3.1.1網絡環(huán)境內網帶寬＞千M內網。＞內網ping包延遲：＜0.1ms網絡拓撲示意3.1.2服務器配置設備硬件配置操作系統(tǒng)NginxIBMX3650Redhatlinuxas4CPU:Intel(R)Xeon(R)E51502.66GHz2核*2內存：4G千兆網卡Tomcat1HpDL580G4CPU:Intel(R)Xeon(TM)3.40GHz4核*2內存：8G千兆網卡Redhatlinuxas5Tomcat2HpDL580G4CPU:Intel(R)Xeon(TM)3.40GHz4核*2內存：8G千兆網卡Redhatlinuxas5Test1HpDL580G5CPU:Intel(R)Xeon(R)E73101.60GHz4核*2內存：4G千兆網卡Redhatlinuxas5Test2IBMX3650CPU:Intel(R)Xeon(R)E51502.66GHz2核*2內存：4G千兆網卡Redhatlinuxas43.1.3軟件環(huán)境操作系統(tǒng)網絡參數優(yōu)化用做測試的各臺服務器，均在/etc/sysctl.conf配置文件中增加如下內核參數:Nginx設置主要配置如下：userwwwwww;worker_processes4;error_log/usr/local/nginx/logs/nginx_error.logdebug;pid/usr/local/nginx/logs/nginx.pid;worker_rlimit_nofile51200;events{useepoll;worker_connections51200;}http{includemime.types;default_typeapplication/octet-stream;#charsetgb2312;server_names_hash_bucket_size128;client_header_buffer_size32k;large_client_header_buffers432k;sendfileon;tcp_nopushon;keepalive_timeout1;tcp_nodelayon;#gzipon;#gzip_min_length1k;#gzip_buffers416k;#gzip_http_version1.0;#gzip_comp_level2;#gzip_typestext/plainapplication/x-javascripttext/cssapplication/xml;#gzip_varyon;upstreamtomcats{}server{listen81;server_namelocalhost;proxy_redirectoff;location/{}#后端的Web服務器可以通過X-Forwarded-For獲取用戶真實IPproxy_set_headerX-Forwarded-For$remote_addr;location/{if($request_uri~*".*\.(js|css|gif|jpg|jpeg|png|bmp|swf)$")TOC\o"1-5"\h\z{}if($request_uri~*"A/view/(.*)$"){}#}#定義日志格式log_formataccess'$remote_addr-$remote_user[$time_local]$request'"$status"$body_bytes_sent"$http_referer"''"$http_user_agent""$http_x_forwarded_for"';#打日志access_log/usr/local/nginx/logs/access.logaccess;#允許客戶端請求的最大的單個文件字節(jié)數client_max_body_size10m;#緩沖區(qū)代理緩沖用戶端請求的最大字節(jié)數可以理解為先保存到本地再傳給用戶client_body_buffer_size128k;#跟后端服務器連接的超時時間_發(fā)起握手等候響應超時時間proxy_connect_timeout600;TOC\o"1-5"\h\z#連接成功后_等候后端服務器響應時間_其實已經進入后端的排隊之中等候處理proxy_read_timeout600;#后端服務器數據回傳時間_就是在規(guī)定時間之內后端服務器必須傳完所有的數據proxy_send_timeout600;#代理請求緩存區(qū)_這個緩存區(qū)間會保存用戶的頭信息以供Nginx進行規(guī)則處理_一般只要能保存下頭信息即可proxy_buffer_size8k;#同上告訴Nginx保存單個用的幾個Buffer最大用多大空間proxy_buffers432k;#如果系統(tǒng)很忙的時候可以申請更大的proxy_buffers官方推薦*2proxy_busy_buffers_size64k;#proxy緩存臨時文件的大小proxy_temp_file_write_size64k;}}Tomcat設置主要配置如下：Tomcat5.5MaxThread500MinSpareThread25?MaxSpareThread75Xmx1740MJava環(huán)境>使用jdk1.6_03啟動兩個Tomcato使用jdk1.6啟動兩個客戶端的httpTes測試t進程。

3.2測試結果3.2.1單個TOMCAT的WEB服務器NO客戶數線程數請求次數間隔時間測試服務器占用內存服務器負載持續(xù)時間平均速度完成請求11500200萬0毫秒Test11.1G>15082秒12986條/秒106萬從第82秒開始，tomcat占用內負載急劇升高，top顯示已達1速度急劇下降，錯包率100%，22500200萬25毫秒Test11.7G<6288秒4765條/秒137萬從第280秒左右開始，tomcat請求速度急劇下降，出現錯包，拋出““異常。Test2293秒4123條/秒120萬32500200萬50毫秒Test11.7G<3422秒2863條/秒120萬服務端從第400秒左右開始，tTest2請求速度急劇下降，開始且仍在在增加中，之前的錯包修Test2413秒2922條/秒120萬42500200萬200毫秒Test11.7G<2742秒1727條/秒128萬服務端從第740秒左右開始，tTest2請求速度急劇下降，開女率只有0.008%，達到1.7g后，在增加中。web服務器負載小Test2744秒1608條/秒119萬52500200萬500毫秒Test11.7G<11595秒742條/秒118萬服務端從第1595秒左右開始，tTest2請求速度急劇下降，開始達到1.7g后，截止停止測試時Test21575秒737條/秒116萬62500300萬1000毫秒Test11.7G<16362秒471條/秒300萬在測試進度到80%左右時，tomcaTest2請求速度并未下降，直到包，丟包率只有0.003%，最長的Test26351秒472條/秒300萬

3.2.2Nginx+2個TOMCAT的WEB服務器NO客戶端數線程數請求次數間隔時間測試服務器Tomcat占用內存服務器負載持續(xù)時間平均速度完成請求數最大響應時長平均響時長12250150萬0毫秒Test11G<2347秒4322條/秒150萬93005毫秒0.21毫Test11G322秒4658條/秒150萬21244毫秒0.23毫22500200萬25毫秒Test11.4G<2542秒3690條/秒200萬45016毫秒0.27毫Test21.4G544秒3676條/秒200萬45014毫秒0.27毫32500300萬50毫秒Test11.7G<21140秒2445條/秒278萬Test21.7G1141秒2424條/秒276萬42500300萬200毫秒Test11.7G<11860秒1490條/秒277萬Test21.7G1863秒1482條/秒276萬52500500萬500毫秒Test11.7G<15475秒913條/秒500萬93000毫秒1.09毫Test21.7G5565秒898條/秒500萬92987毫秒1.11毫62500500萬1000毫秒Test1968M<110149秒492條/秒500萬9077毫秒2.02毫Test21G10149秒492條/秒500萬9044毫秒2.02毫

3.2.3Nginx+2個TOMCAT的WEB服務器+緩沖NO客戶端數線程數請求次數間隔時間測試服務器Tomcat占用內存服務器負載持續(xù)時間平均速度（條/秒）完成請求數最大響應時長平均響長12250150萬0毫秒Test10.2G<164秒23437150萬9993毫秒0.041Test20.2G59秒25423150萬3472毫秒0.04122500200萬25毫秒Test10.4G<1196秒10202200萬9616毫秒0.101Test20.4G194秒10361200萬9608毫秒0.10132500300萬50毫秒Test10.4G<1379秒7915300萬9015毫秒0.131Test20.2G384秒7812300萬10234毫秒0200毫秒Test10.4G<11220秒2459300萬3018毫秒0.401Test20.2G1241秒2417300萬3384毫秒0.41152500500萬500毫秒Test10.4G<15031秒993500萬3020毫秒1.001Test20.2G5055秒989500萬3394毫秒1.01162500500萬1000毫秒Test10.4G<110040秒498500萬3020毫秒2.001Test20.2G10038秒498500萬78毫秒2.001注：本次測試所用明頁面僅100個字節(jié)大小，測試過程中帶寬壓力可以忽略不計。測試過程中曾嘗試過使嫌大兆內網下，無論是單頑《^亦或是晦如+277?^血，請求速度最大均不超過000條/秒，網絡帶寬使用已經達至800此，實際應用中，網絡帶寬對整個瀝服務的影響會非常大3.3測試結果分析系統(tǒng)參數的影響分析worker_processes參數對Nginx性能的影響測試過程中分別設定worker_processes為8、4、2、1時發(fā)現，該參數對nginx性能影響不大，對服務器資源消耗也沒有太大影響，相關資料顯示，該參數的值最好跟cpu核數相等，能夠發(fā)揮最大性能，本次測試nginx所在服務器為2顆雙核cpu，因此最終測試設定為4。MaxThread參數對tomcat并發(fā)性的影響本次測試tomcat的MaxThread參數設定為500，進行13000條/秒并發(fā)測試時，tomcat啟動并發(fā)線程過多，將服務器cpu耗盡。分析MaxThread雖能夠提高tomcat并發(fā)能力，但前提是在一個合理的范圍內，要確保服務器負載不會因為并發(fā)線程過多而急劇升高，從而停止響應。-Xmx最大內存值對Tomcat能夠持續(xù)響應高并發(fā)的影響持續(xù)高并發(fā)請求狀態(tài)下，有6次測試是因為tomcat內存達到指定最大值導致響應變慢，直至內存溢出停止響應，因此，Tomcat最大內存對tomcat能夠持續(xù)響應高并發(fā)請求有很大的影響，調整該值，應該可以增加Tomcat響應高并發(fā)請求的總數，進而延長WEB服務能夠支撐峰值的時間。各架構下的性能分析Nginx+2Tomcat的最大并發(fā)性低于單Tomcat，Nginx+2Tomcat最快為8980條/秒，單Tomcat為12986條/秒，分析可能是受nginx所在服務器性能影響所致。單tomcat在配置1.7g最大內存時，在持續(xù)超過1479條/秒的并發(fā)請求下，在穩(wěn)定支撐約240萬次響應后，Tomcat內存達到1.7上限，之后Tomcat響應會急劇變慢，錯包急劇上升。Nginx+2tomcat架構下，2個tomcat分別配置1.7g最大內存時，在持續(xù)超過2900條/秒的并發(fā)請求下，能夠穩(wěn)定支撐約540萬次左右響應，之后兩個Tomcat內存都會達到1.7上限，響應會急劇變慢，但錯包情況并未出現。在Nginx+2tomcat，同時配置了緩存的情況下，可以達到1.5萬以上的并發(fā)處理能力3.4評測結果單個tomcat的處理能力在500條/秒左右單個tomcat能穩(wěn)定支持每秒500左右的并發(fā)請求。Nginx+Tomcat比單個Tomcat更穩(wěn)定，不易出現錯包，可以通過擴充tomcat集群(新增tomcat服務器)來提升系統(tǒng)的并發(fā)能力單個tomcat在超出并發(fā)能力的提求下，處理能力大大下降，并出現大量錯包，而采用Nginx+2Tomcat架構在各種測試下，均未出現錯包，但處理能力也會下降。單個tomcat能穩(wěn)定支持每秒500左右的并發(fā)請求，而Nginx+2Tomcat能支持每秒1000左右的并發(fā)請求。所以可以通過新加tomcat務器來提升系統(tǒng)的并發(fā)能力，但在tomcat的總體處理能力超過nginx的處理能力時無效。3）Nginx+2Tomcat配置了緩存后，靜態(tài)頁面的并發(fā)能力不再受tomcat的限制，單個nginx的并發(fā)處理能力能達到1.5萬以上。配置了緩存后，nginx+2tomcat的處理能力實測數據超過了1.5萬次/秒，而單個tomcat可以支撐500次/秒，則從理論上計算一組Nginx+30個Tomcat集群可以支撐1.5萬次/秒的并發(fā)處理。注：為tomcat均分配1.7G內存。4配置選型4.1網絡帶寬只考慮門戶訪問的帶寬占用，后臺管理頁面等其他業(yè)務訪問與門戶訪問相差2-3個數量級，這一部分網絡流量占用忽略。同時考慮網絡帶寬利用率（70%）根據業(yè)務設計能力，每秒網絡流量=WEB網站每秒鐘訪問流量=（每次訪問占用的帶寬X每秒訪問次數）/帶寬利用率=（200K*8*n）/0.7注：一般門戶的首頁大?。?M、平均200K/頁面，我們以平均值來計算。并發(fā)能力占用的網絡帶寬100次/秒228M200次/秒457M500次/秒1442M1000次/秒2286M4.2架構和硬件配置選型4.2.1硬件配置參考序號產品功能參考型號、配置TPMC1主機設備1.1數據庫服務器IBMSystemx3850M2,4個處理器，每處理器為6核，共計24核。內存大小16G。SAS硬盤，硬盤大小587GB。4U機架，集成雙千兆以太網接口，兩塊千兆的光纖網卡。6845081.2WEB服務器IBMSystemx3850M2,4個處理器，每處理器為6核，共計24核。內存大于8G。SAS硬盤，硬盤大小587GB。4U機架，集成雙千兆以太網接口，兩塊千兆的光纖網卡。6845081.3管理終端IBMSystemx3560，1個IntelXeonE5450處理器，內存大小2G，2U機架。326002網絡設備

2.1負載均衡器RADWARE應用負載均衡設備,型號:為ODS-504,有，4個可選的千兆位電端口，1G主內存，500M處理能力（最大可通過License升級為4G）2.2防火墻CISCOASA5520防火墻并發(fā)連接：280000網絡吞吐：450安全過濾：225MB網絡端口：4個千兆以太網接口+1個快速用戶數限：無用戶數限制用戶VPN支持：支持2.2交換機QuidwayS3952P-EI傳輸速率：10Mbps/100Mbps/1000Mbps網絡標準：IEEE802.1Q、IEEE802.1D端口數量：48接口介質：10/100Base-T、1000Base-X傳輸模式：全雙工/半雙工自適應背板帶寬：32Gbps3存儲設備3.1光纖存儲柜光纖存儲柜（EVA4100）3.2光纖交換機光纖交換機（4/32BSANSwitch）注：上表為硬件的參考配置，根據網站規(guī)模的不同，在初期可