qileilove

性能測試之系統架構分析

　之前有對性能需求進行過分析，那篇主要從項目業務、背景等角度如何抽絲剝繭的將項目的需求抽離出來。在我們進行需求的時候也需要對被測項目的架構有一定的認識，如果不了解被測系統的架構，那么在后期的性能分析與調優階段將無從下手。

簡單系統架構介紹                                                                              

　　因為每個公司的業務不同，采用的技術，架構也都有很大不同。但不管怎么變動，但基本都在三層架構的基礎上擴展與改進。

下面看一個基本的系統架構：

表示層：

　　表示層運行在客戶終端上，運行java  applet 程序，提供協議控制和用戶界面，與系統用戶實現直接交互，通過TCP/HTTP協議與業務層系統通信，向應用層系統發送請求報文，并接收應用層系統返回的回應報文。

業務邏輯層：

　　業務邏輯層作為中間層實現核心業務邏輯服務。

　　應用服務器主要運行中間件系統，中間件系統系統作為一個容器來運行各種應用軟件系統。前臺發來的請求報文通過中間件傳遞給應用程序，應用程序在處理的過程中調用數據層的數據服務器，數據服務器將查詢的數據返回給應用程序，應用軟件處理完成后通過中間件系統返回給客戶端。

　　在大型的系統中，可以對應用系統進行拆分，比如拆分成交易服務，查詢服務；或者通過負載均衡技術，來分散客戶端發來的請求，使其能承受更大的用戶訪問量。

數據層：

　　數據層運行在數據庫主機上，負責整個系統中數據信息的存儲。運行數據庫服務程序，查詢通過JDBC與應用程序進行通信，主要用于存儲數據與提供數據查詢等服務。

　　數據庫集群技術就是對大型系統應用非常廣泛的一種解決方案。

大型系統架構介紹                                                                               

　　前面介紹了一般系統的架構，那么一個大型的系統在設計中使用了哪些手段或技術來提高系統的性能呢

操作系統

　　操作系統是硬件與軟件之間的橋梁，那么一個穩定的操作系統是系統堅實的基礎。在個人操作系統領域，windows 無疑是絕對的霸主，但隨著近幾年的發展，linux/unix以其不俗的性能表現，超強的穩定性與安全性使其在服務器領域變成重多企業的首選。因為系統服務器由少數技術人員使用，他們更看重系統的性能、穩定性和安全性等方面的表現。

Web服務器

　　Web服務器即中間件服務器，是應用程序的載體（容器），應用程序只有在中間件服務器上才能正常的運行被外界所訪問使用。對于window系統來說，IIS是微軟配套的web服務器，他們的搭配應該是夫妻是之間的默契；apache 作為開源力量代表，不管在windows還是linux下面都非常得寵。因為linux與apache 都為開源產品且性能優異，應用非常廣泛。

　　· 淘寶網（阿里巴巴）: Linux操作系統 + Web 服務器: Apache

　　· 新浪：FreeBSD + Web 服務器：Apache

　　· Yahoo：FreeBSD + Web 服務器：自己的

　　· Google: 部分Linux + Web 服務器：自己的

　　· 百度：Linux + Web 服務器: Apache

　　· 網易：Linux + Web 服務器: Apache

　　· eBay: Windows Server 2003/8 (大量) + Web 服務器：Microsoft IIS

　　· MySpace: Windows Server 2003/8 + Web 服務器：Microsoft IIS

常用的系統架構是:

· Linux + Apache + PHP + MySQL

· Linux + Apache + Java (WebSphere) + Oracle

· Windows Server 2003/2008 + IIS + C#/ASP.NET + 數據庫

· Window Server 2003/2008 + tomcat + MySql

提高系統性能的相關技術                                                              

網頁HTML 靜態化

　　其實大家都知道網頁靜態化,效率最高,消耗最小的就是純靜態化的 html 頁面,所以我們盡可能使我們的網站上的頁面采用靜態頁面來實現,這個最簡單的方法其實也是最有效的方法。

　　但是對于大量內容并且頻繁更新的網站,我們無法全部手動去挨個實現,于是出現了我們常見的信息發布系統 CMS,像我們常訪問的各個門戶站點的新聞頻道,甚至他們的其他頻道,都是通過信息發布系統來管理和實現的,信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面,還能具備頻道管理,權限管理,自動抓取等功能,

　　對于一個大型網站來說,擁有一套高效,可管理的CMS 是必不可少的，除了門戶和信息發布類型的網站,對于交互性要求很高的社區類型網站來說,盡可能的靜態化也是提高性能的必要手段,將社區內的帖子,文章進行實時的靜態化,有更新的時候再重新靜態化也是大量使用的策略,像Mop 的大雜燴就是使用了這樣的策略,網易社區等也是如此同時,html 靜態化也是某些緩存策略使用的手段,

　　對于系統中頻繁使用數據庫查詢但是內容更新很小的應用,可以考慮使用 html 靜態化來實現,比如論壇中論壇的公用設置信息,這些信息目前的主流論壇都 可以進行后臺管理并且存儲再數據庫中,這些信息其實大量被前臺程序調用,但是更新頻率很小,可以 考慮將這部分內容進行后臺更新的時候進行靜態化,這樣避免了大量的數據庫訪問請求；

圖片服務器分離

　　對Web 服務器來說,不管是 Apache,IIS 還是其他容器,圖片是最消耗資源的,于是我們 有必要將圖片與頁面進行分離,這是基本上大型網站都會采用的策略,他們都有獨立的圖片服務器,甚至很多臺圖片服務器，這樣的架構可以降低提供頁面訪問請求的服務器系統壓力,并且可以保證系統不 會因為圖片問題而崩潰,在應用服務器和圖片服務器上,可以進行不同的配置優化,比如 apache 在配置 ContentType 的時候可以盡量少支持,盡可能少的 LoadModule,保證更高的系統消耗和執行效率；

數據庫集群和庫表散列 

　　大型網站都有復雜的應用,這些應用必須使用數據庫,那么在面對大量訪問的時候,數據庫的瓶頸很快就能顯現出來,這時一臺數據庫將很快無法滿足應用,于是我們需要使用數據庫集群或者庫表散列。

　　在數據庫集群方面, 很多數據庫都有自己的解決方案, Oracle, Sybase 等都有很好的方案,常用的 MySQL 提供的 Master/Slave 也是類似的方案,您使用了什么樣的 DB,就參考相應的解決方案來實施即可。

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

緩存

　　緩存一詞搞技術的都接觸過,很多地方用到緩存，網站架構和網站開發中的緩存也是非常重要，這里先 講述最基本的兩種緩存，高級和分布式的緩存在后面講述， 架構方面的緩存,對 Apache 比較熟悉的人都能知道 Apache 提供了自己的緩存模塊,也可以使用外加的 Squid 模塊進行緩存,這兩種方式均可以有效的提高 Apache 的訪問響應能力， 網站程序開發方面的緩存,Linux 上提供的 Memory Cache 是常用的緩存接口,可以在 web 開發中使用, 比如用 Java 開發的時候就可以調用 MemoryCache 對一些數據進行緩存和通訊共享, 一些大型社區使用了 這樣的架構， 另外, 在使用 web 語言開發的時候, 各種語言基本都有自己的緩存模塊和方法, PHP 有 Pear 的 Cache 模塊,Java 就更多了,net 不是很熟悉,相信也肯定有；

鏡像

鏡像是大型網站常采用的提高性能和數據安全性的方式,鏡像的技術可以解決不同網絡接入商和地域帶來的用戶訪問速度差異, 比如 ChinaNet 和 EduNet 之間的差異就促使了很多網站在教育網內搭建鏡像站點,數據進行定時更新或者實時更新，在鏡像的細節技術方面,這里不闡述太深,有很多專業的現成的解決 架構和產品可選，也有廉價的通過軟件實現的思路,比如 Linux 上的 rsync 等工具；

負載均衡

負載均衡將是大型網站解決高負荷訪問和大量并發請求采用的終極解決辦法，負載均衡技術發展了多年,有很多專業的服務提供商和產品可以選擇,下面介紹幾種常見的負載均衡。

1. 基于DNS的負載均衡--一個域名綁定多個IP

　　DNS負載均衡技術是最早的負載均衡解決方案，它是通過DNS服務中的隨機名字解析來實現的，在DNS服務器中，可以為多個不同的地址配置同一個名字，而最終查詢這個名字的客戶機將在解析這個名字時得到其中的一個地址。因此，對于同一個名字，不同的客戶機會得到不同的地址，它們也就訪問不同地址上的Web 服務器，從而達到負載均衡的目的。

　　這種技術的優點是，實現簡單、實施容易、成本低、適用于大多數TCP/IP應用；但是，其缺點也非常明顯，首先這種方案不是真正意義上的負載均衡，DNS 服務器將Http請求平均地分配到后臺的Web服務器上，而不考慮每個Web服務器當前的負載情況；如果后臺的Web服務器的配置和處理能力不同，最慢的 Web服務器將成為系統的瓶頸，處理能力強的服務器不能充分發揮作用；其次未考慮容錯，如果后臺的某臺Web服務器出現故障，DNS服務器仍然會把DNS 請求分配到這臺故障服務器上，導致不能響應客戶端。最后一點是致命的，有可能造成相當一部分客戶不能享受Web服務，并且由于DNS緩存的原因，所造成的后果要持續相當長一段時間(一般DNS的刷新周期約為24小時)。所以在國外最新的建設中心Web站點方案中，已經很少采用這種方案了。

2. 通過硬件四層交換實現負載均衡

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

3. 通過軟件四層交換實現負載均衡

　　軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基于心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對于分布式的系統來說必不可少。

一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性。

4. 通過反向代理服務器實現負載均衡

　　反向代理服務器又稱為 WEB 加速服務器，它位于 WEB 服務器的前端，充當WEB服務器的內容緩存器,反向代理服務器是針對 WEB 服務器設置的，后臺 WEB 服務器對互聯網用戶是透明的，用戶只能看到反向代理服務器的地址，不清楚后臺 WEB 服務器是如何組織架構的。當互聯網用戶請求 WEB 服務時，DNS 將請求的域名解析為反向代理服務器的 IP 地址，這樣 URL 請求將被發送到反向代理服務器，由反向代理服務器負責處理用戶的請求與應答、與后臺 WEB 服務器交互。利用反向代理服務器減輕了后臺 WEB 服務器的負載，提高了訪問速度，同時避免了因用戶直接與 WEB 服務器通信帶來的安全隱患。

-------------------------------------

      這篇文章非常糾結，以目前技術水平來講這塊的東西實屬班門弄斧。部分內容從互聯網搜集。


各種系統架構圖及其簡介

1.Spring 架構圖

  Spring 是一個開源 框架，是為了解決企業 應用程序開發復雜性而創建的。框架的主要優勢之一就是其分層架構，分層架構允許您選擇使用哪一個組件，同時為J2EE 應用程序開發提供集成的框架。Spring 框架的功能可以用在任何J2EE 服務器中，大多數功能也適用于不受管理 的環境。Spring的核心要點是：支持不綁定到特定J2EE 服務的可重用業務和數據訪問對象。這樣的對象可以在不同J2EE 環境（Web 或EJB ）、獨立應用程序、測試 環境之間重用。

組成Spring 框架的每個模塊（或組件）都可以單獨存在，或者與其他一個或多個模塊聯合實現。每個模塊的功能如下：

• 核心容器：核心容器提供Spring 框架的基本功能。核心容器的主要組件是BeanFactory ，它是工廠模式的實現。BeanFactory 使用控制反轉 （IOC ） 模式將應用程序的配置和依賴性規范與實際的應用程序代碼 分開。
• Spring 上下文：Spring 上下文是一個配置文件，向Spring 框架提供上下文信息。Spring 上下文包括企業服務，例如JNDI 、EJB 、電子郵件、國際化、校驗和調度功能。
• Spring AOP ： 通過配置管理特性，Spring AOP 模塊直接將面向方面的編程 功能集成到了Spring 框架中。所以，可以很容易地使Spring 框架管理的任何對象支持AOP 。Spring AOP 模塊為基于Spring 的應用程序中的對象提供了事務管理服務。通過使用Spring AOP ，不用依賴EJB組件，就可以將聲明性事務管理集成到應用程序中。
• Spring DAO ：JDBC DAO 抽象層提供了有意義的異常層次結構，可用該結構來管理異常處理和不同數據庫 供應商拋出的錯誤消息。異常層次結構簡化了錯誤處理，并且極大地降低了需要編寫 的異常代碼數量（例如打開和關閉連接）。Spring DAO 的面向JDBC 的異常遵從通用的DAO 異常層次結構。
• Spring ORM ：Spring 框架插入了若干個ORM 框架，從而提供了ORM 的對象關系工具，其中包括JDO 、Hibernate 和iBatis SQL Map 。所有這些都遵從Spring 的通用事務和DAO 異常層次結構。

2.ibatis 架構圖

ibatis 是一個基于 Java 的持久層框架。 iBATIS 提供的持久層框架包括 SQL Maps 和 Data Access Objects （ DAO ），同時還提供一個利用這個框架開發的 JPetStore 實例。

IBATIS ：最大的優點是可以有效的控制sql 發送的數目，提高數據層的執行效率！它需要程序員自己去寫sql 語句，不象hibernate 那樣是完全面向對象的，自動化的，ibatis 是半自動化的，通過表和對象的映射以及手工書寫的sql 語句，能夠實現比hibernate 等更高的查詢效率。

Ibatis 只是封裝了數據訪問層，替我們做了部分的對象關系映射。但代價是必須要寫xml 配置文件，相對于Hibernate 還要寫很多sql 。Hibernate通過工具直接從數據庫模式生成實體類和基本的配置文件，而且大部分情況下不需要我們寫sql ，會較大的提升開發效率。但這些也有很多的局限性，尤其是對環境的要求較高（數據庫設計，對象設計，團隊的協作等）。 個人感覺Ibatis 對項目比較有意義的地方在于它小巧靈活，可擴展，封裝了數據訪問層（事務，緩存，異常，日志），并提供了DAO 框架支持。

利用Ibatis 我們可以做到代碼和sql 的分離，只要sql 能夠解決的問題，Ibatis 就能幫我們較容易的解決，同時也使我們的項目對某一框架的依賴性變小（因為Ibatis 是非侵入性的）。這將極大的降低項目風險，減少解決復雜問題的時間，使項目的維護變得簡單。

Ibatis 對于應用的修改，調試，擴充和維護將會變得容易自然。修改時，我們主要修改的是代表模型的實體對象，xml 配置文件中的sql ，和/ 或配置文件的ResultMap （很多時候是不需要的）。同時，sql 和代碼分離，我們不用在代碼的StringBuffer 的append 方法之間尋找需要修改的sql 。配置文件中的sql 便利了我們的調試和對sql 的評審及以后的sql 重用。

3.structs1 架構圖

Struts 是Apache 基金會Jakarta 項目組的一個Open Source 項目，它采用MVC 模式，能夠很好地幫助java 開發者利用J2EE 開發Web 應用。和其他的java 架構一樣，Struts 也是面向對象設計，將MVC 模式" 分離顯示邏輯和業務邏輯" 的能力發揮得淋漓盡致。Structs 框架的核心是一個彈性的控制層，基于如Java Servlets ，JavaBeans ，ResourceBundles 與XML 等標準技術 ，以及Jakarta Commons 的一些類庫。Struts 有一組相互協作的類（組件）、Serlvet 以及jsp tag lib 組成?；趕truts 構架的web 應用程序基本上符合JSP Model2 的設計標準，可以說是一個傳統MVC 設計模式的一種變化類型?！　?/p>

Struts 有其自己的控制器（Controller ），同時整合了其他的一些技術去實現模型層（Model ）和視圖層（View ）。在模型層，Struts 可以很容易的與數據訪問技術相結合，如JDBC / EJB ，以及其它第三方類庫，如Hibernate / iBATIS ，或者Object Relational Bridge( 對象關系橋) 。在視圖層，Struts 能夠與JSP ，包括JSTL 與JSF ，以及Velocity 模板，XSLT 與其它表示層技術。

Struts 為每個專業的Web 應用程序做背后的支撐，幫助為你的應用創建一個擴展的開發環境。

?  Client browser （客戶瀏覽器）

來自客戶瀏覽器的每個HTTP 請求創建一個事件。Web 容器將用一個HTTP 響應作出響應。

?  Controller （控制器）

控制器接收來自瀏覽器的請求，并決定將這個請求發往何處。就Struts 而言，控制器是以servlet 實現的一個命令設計模式。struts-config.xml 文件配置控制器。

?  業務邏輯

業務邏輯更新模型的狀態，并幫助控制應用程序的流程。就Struts 而言，這是通過作為實際業務邏輯“ 瘦” 包裝的Action 類完成的。

?  Model （模型）的狀態

模型表示應用程序的狀態。業務對象更新應用程序的狀態。ActionForm. bean 在會話級或請求級表示模型的狀態，而不是在持久級。JSP 文件使用JSP 標記讀取來自ActionForm. bean 的信息。

?  View （視圖）

視圖就是一個JSP 文件。其中沒有流程邏輯，沒有業務邏輯，也沒有模型信息-- 只有標記。標記是使Struts 有別于其他框架（如Velocity ）的因素之一

4.structs2 架構圖

Struts 2 相對于Struts 1.X ，將實現用戶業務邏輯（Action ）同Servlet API 分離開，這種分離機制，是采用了攔截器或者攔截器棧（攔截器鏈）。攔截器是Struts 2 的核心內容之一。

5.Hibernate 架構圖

Hibernate 是一個開放源代碼 的對象關系映射框架，它對JDBC 進行了非常輕量級的對象封裝，使得Java 程序員可以隨心所欲的使用對象編程思維來操縱數據庫。Hibernate 可以應用在任何使用JDBC 的場合，既可以在Java 的客戶端程序使用，也可以在Servlet/JSP 的Web 應用中使用，最具革命 意義的是，Hibernate 可以在應用EJB 的J2EE 架構中取代CMP ，完成數據持久化的重任。

　 　Hibernate 的核心接口一共有5 個，分別為:Session 、SessionFactory 、Transaction 、Query 和Configuration 。這5 個核心接口在任何開發中都會用到。通過這些接口，不僅可以對持久化對象進行存取，還能夠進行事務控制。下面對這五個核心接口分別加以介紹。

·Session 接口:Session 接口負責執行被持久化對象的CRUD 操作(CRUD 的任務是完成與數據庫的交流，包含了很多常見的SQL 語句。) 。但需要注意的是Session 對象是非線程安全的。同時，Hibernate 的session 不同于JSP 應用中的HttpSession 。這里當使用session 這個術語時，其實指的是Hibernate 中的session ，而 以后會將HttpSesion 對象稱為用戶session 。

·SessionFactory 接口:SessionFactory 接口負責初 始化Hibernate 。它充當數據存儲源的代理，并負責創建Session 對象。這里用到了工廠模式。需要注意的是SessionFactory 并不是輕量級的，因為一般情況下，一個項目通常只需要一個SessionFactory 就夠，當需要操作多個數據庫時，可以為每個數據庫指定一個SessionFactory 。

·Configuration 接口:Configuration 接口負責配置并啟動Hibernate ，創建SessionFactory 對象。在Hibernate 的啟動的過程中，Configuration 類的實例首先定位映射文檔位置、讀取配置，然后創建SessionFactory 對象。

·Transaction 接口:Transaction 接口負責事務相關的操作。它是可選的，開發人員也可以設計編寫自己的底層事務處理代碼。

·Query 和Criteria 接口:Query 和Criteria 接口負責執行各種數據庫查詢。它可以使用HQL 語言或SQL 語句兩種表達方式。

6.J2EE 架構圖

J2EE 是一套全然不同于傳統應用開發的技術架構，包含許多組件，主要可簡化且規范應用系統的開發與部署，進而提高可移植性、安全與再用價值。

J2EE 核心是一組技術規范與指南，其中所包含的各類組件、服務架構及技術層次，均有共通的標準及規格，讓各種依循J2EE 架構的不同平臺之間，存在良好的兼容性，解決過去企業后端使用的信息產品彼此之間無法兼容，導致企業內部或外部難以互通的窘境。

7.Oracle 架構圖

posted on 2014-02-13 17:12 順其自然EVO 閱讀(735) 評論(0)  編輯  收藏 所屬分類: 性能測試