SaaS系列介紹之十三: SaaS系統體系架構

標籤：

1 系統體系架構設計

　　軟體開發中系統體系架構決定了一個系統穩定性、健壯性、可擴充性、相容性和可用性，它是系統的靈魂。體系架構是架構師所關注的核心。良好的體系架構是系統成功的開端，否則，再好的代碼與設計也無濟於事。

　　2 當前.net主要的開發架構簡介

　　l Castle

　　Castle是針對.NET平台的一個開源項目，從資料訪問架構ORM到IOC容器，再到WEB層的MVC架構、AOP，基本包括了整個開發過程中的所有東西，為我們快速的構建企業級的應用程式提供了很好的服務。其中關鍵的技術是ActiveRecord，Facilities，MonoRail等等。

　　優點：體現了ORM、IOC、ActiveRecorder思想，MVC架構。

　　不足：架構層次劃分不太清楚。

　　l PetShop

　　PetShop是微軟用它來展示.Net企業系統開發的能力。PetShop4.0，這個執行個體是Microsoft針對SQL Server 2005 以及Visual Studio 2005發布的。其中運用了一些新的技術。快取資料與資料庫的更新同步，新的Web控制項，以及母片的應用，非同步通訊，訊息佇列。這些都是很實用的技術。PetShop中大量運用了抽象原廠模式，由於採用了Master Pages，Membership，以及Profile，表現層的編碼量減少了25%，資料層的編碼量減少了36%。

　　

　　圖1 PetShop4.0的體系架構

　　PetShop4.0在資料訪問層(DAL)中，採用DAL Interface抽象出資料訪問邏輯，並以DAL Factory作為資料訪問層對象的工廠模組。對於DAL Interface而言，分別有支援MS-SQL的SQL Server DAL和支援Oracle的Oracle DAL具體實現。而Model模組則包含了資料實體物件。可以看到，在資料訪問層中，完全採用了“面向介面編程”思想。抽象出來的IDAL模組，脫離了與具體資料庫的依賴，從而使得整個資料訪問層利於資料庫遷移。DALFactory模組專門管理DAL對象的建立，便於商務邏輯層訪問。SQLServerDAL和OracleDAL模組均實現IDAL模組的介面，其中包含的邏輯就是對資料庫的Select，Insert，Update和Delete操作。因為資料庫類型的不同，對資料庫的操作也有所不同，代碼也會因此有所區別。

　　此外，抽象出來的IDAL模組，除瞭解除了向下的依賴之外，對於其上的商務邏輯層，同樣僅存在弱依賴關係。

　　優點：體現了原廠模式ORM，IOC思想，.Net企業級開發。

　　不足：沒有ORM思想。

　　l Nhibernate

　　Hibernate是一個目前應用的最廣泛的開放原始碼的對象關係映射架構，它對Java的JDBC(類似於ADO.Net)進行了非常輕量級的對象封裝，使得程式員可以隨心所欲的使用對象編程思維來操縱資料庫，目前在國內Java開發界已經頗為流行。而NHibernate，如同NUnit，NAnt一樣，是基於.Net的Hibernate實現。主要體現了ORM的思想，解決了分層開發中的持久層的問題，在N層開發中非常重要。

　　優點：體現了ORM，持久層。

　　不足：配置複雜，過份信賴於XML檔案。

　　所用技術總結：

　　OR Mapping思想，分層架構思想，Castle-ActiveRecorder，Atlas，反射，設計模式(單例模式，簡單原廠模式，策略模式)，XML，IOC，架構。

　　3 當前J2ee主要的開發架構簡介

　　l Struts 架構

　　Struts架構是一開源產品，基於模型-視圖-控制器(MVC)設計範例來開發Web應用軟體。它使用並且擴充了Java Servlet API，最初由Craig McClanahan建立。在2000年5月，它被捐贈到Apache Foundation。Struts架構展示了一個強有力的定製標籤庫，平鋪顯示，表單檢驗和I18N(國際化)。另外，Struts支援許多描述層，包括JSP，XML/XSLT使得Java程式員可以隨心所欲的使用對象編程思維來操縱資料庫，JavaServerFaces(JSF)和Velocity;還支援一些模型層，包括JavaBeans和EJB。

　　下面是Struts的核心內容：

　　JSP(TagLib)――>ActionForm――>Action ――> Event――>EJBAction――>EJB――>DAO――>Database

　　JSP(TagLib) (forward) <――Action<――EventResponse<――

　　優點：基於MVC模式，結構很好，基於JSP。

　　不足：擴充性不太好，邏輯複雜的大型項目不適用，架構層次劃分不太清楚。

　　l Spring架構

　　Spring架構是一個分層的Java/J2EE應用程式架構，基於Expert One-on-One J2EE設計和發行的代碼。Spring架構提供一種簡單的開發技術，用於自動化處理工程中大量的屬性檔案和助理類。

　　Spring是一個開源架構，由Rod Johnson建立並且在他的著作《J2EE設計開發編程指南》裡進行了描述。它是為瞭解決公司專屬應用程式開發的複雜性而建立的。Spring使使用基本的JavaBeans來完成以前只可能由EJB完成的事情變得可能了。然而，Spring的用途不僅限於伺服器端的開發。從簡單性、可測試性和松耦合的角度而言，任何Java應用都可以從Spring中受益。

　　Spring架構套件括的主要特色有：

　　1 強有力的基於JavaBeans的組態管理，使用Inversion-of-Control(IoC)原則。

　　2 一個核心bean工廠，可用在任何環境，從applets到J2EE容器程式。

　　3 通用的抽象層適合於資料庫交易管理，允許可插入的交易管理員，並且不需要處理低層次的問題就可容易地劃分各事務的界限。

　　4 一個很有意義的異常處理的JDBC抽象層。

　　5 與Hibernate整合到一起，DAO實現支援以及事務策略。

　　優點：體現了J2EE、容器、輕量級、控制反轉、面向切面的思想。

　　不足：結構複雜，不易理解。

　　l Hibernate架構

　　Hibernate是一個開放原始碼的對象關係映射(ORM)架構，它對JDBC進行了非常輕量級的對象封裝，它提供一個易用的架構來實現把一個物件導向的領域模型映射到一傳統的關聯式資料庫，使得Java程式員可以隨心所欲的使用對象編程思維來操縱資料庫。它不僅負責從Java類到資料庫表格(以及來自Java資料類型的SQL資料類型)的映射，而且還提供資料查詢和檢索能力，並能大大減少花在SQL和JDBC手工資料處理上的開發時間。最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成資料持久化的重任。

　　Hibernate的目標是減輕開發人員的與大量普通的資料持久性相聯絡的編程任務。Hibernate還能夠適應開發進程，無論它是剛開始設計還是來自一現成的資料庫。Hibernate可以自動產生SQL，使開發人員擺脫了手工處理結果集和進行對象轉化的繁瑣任務，並能使應用程式移植到所有的SQL資料庫。它還能提供透明的持久性，對持久性類的唯一的要求的是實現一個無參數的構造器。

　　優點：主要應用在EJB層，可配置性強，靈活，簡化了資料庫操作。

　　不足：難以配置。

　　4 常見的軟體體系架構

　　l 三層體系架構

　　在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。分層式結構一般分為三層，從下至上分別為：資料訪問層、商務邏輯層(又或成為領域層)、展示層，：

　　

　　圖2 三層體系架構

　　資料訪問層：有時候也稱為是持久層，其功能主要是負責資料庫的訪問。簡單的說法就是實現對資料表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那麼就會包括對象和資料表之間的mapping，以及對象實體的持久化。

　　商務邏輯層(BusinessRules)：是整個系統的核心，它與這個系統的業務(領域)有關。以STS系統為例，商務邏輯層的相關設計，均和銷售跟蹤的邏輯相關。在結構上它封裝了資料訪問層的相關操作。該層主要由實現具體商務邏輯的類組成。

　　展示層(WebUI)：是系統的UI部分，負責使用者與整個系統的互動。在這一層中，理想的狀態是不應包括系統的商務邏輯。展示層中的邏輯代碼，僅與介面元素有關。在當前項目中，是利用ASP.NET來設計的，因此包含了許多Web控制項和相關邏輯。

　　l 五層體系架構

　　SaaS軟體體系架構也可以分為五層，從上而下分別為：使用者介面層(表現層)、商務邏輯層、通用層、應用程式框架層、遠端存取(WebService)層、資料訪問層，：

　　

　　圖3 基於微軟的.NET架構設計

　　使用者介面層(UI)

　　使用者介面層是使用者直接操作的介面。該層由介面外觀、表單控制項、架構及其它部分構成。使用者介面層負責使用者與整個系統的互動。在這一層中，理想的狀態是不應包括系統的商務邏輯。展示層中的邏輯代碼，僅與介面元素有關。在當前項目中，是利用ASP.NET來設計的，因此包含了許多Web控制項和相關邏輯。

　　² 介面外觀包括skip(皮膚)、Images(圖片)、css(樣式表)

　　² 表單控制項主要包括常用表單、使用者自訂控制項。

　　² 架構主要包括Master Page、Frame Page。

　　² 其它主要包括JavaScript檔案、Dll檔案、Report報表、Schema建資料庫、Model開發模板。

　　商務邏輯層(BusinessRules)

　　是整個系統的核心，它與這個系統的業務(領域)有關。以STS系統為例，商務邏輯層的相關設計，均和銷售跟蹤的邏輯相關。在結構上它封裝了資料訪問層的相關操作。該層主要由實現具體商務邏輯的類組成。

　　² BLFactory 商務邏輯工廠

　　² IBL 商務邏輯介面

　　² BusinessRules 商務邏輯實現

　　通用層

　　通用層貫穿整個項目的展示層和商務邏輯層。主要存放該項目中較為通用的常量定義和泛型服務(Service)，這裡指的Service是當前項目商務邏輯上通用的方法，我們把它們寫在對應的靜態類中。以服務的形式提供。

　　CommonLayer：存放通用的常量及方法。

　　資料訪問層

　　該層結構是最複雜的，主要由以下層組成：資料訪問工廠層(DALFactory)，資料提供者層(IDAL)，自訂查詢層(PersistenceFacade)，臨時層(DataAccessLayer)，資料持久層(PersistenceLayer)。

　　下面由下向上介紹：

　　² PersistenceLayer層，這是架構設計的最底層(除應用程式框架層外)。它主要負責用ORM思想將物理資料庫物件化。簡單來說就是將資料庫表映射為實體類，將相應的欄位對應為類的屬性。這樣一來物理資料庫對於開發人員是完全透明的，應用ORM的思想我們徹底擺脫了物理資料庫。並且獨立於資料庫具體實現。

　　² 具體實現我們應用著名的開源項目Castle下的輕量級資料訪問組件ActiveRecorder實現。

　　² PersistenceFacade層和IDAL，這裡定義了項目中用到的所有查詢方法。與PersistenceLayer層定義的資料實體相對應。在這些字定義的查詢類中可以應用ActiverRecorder提供的三種查詢方法(ActiverRecorderBase提供的簡單介面，簡單查詢SimpleQuery，自訂查詢CustomerQuery)的任意組合。並且這裡的每一個類都要實現IDAL介面層定義的相關介面。

　　² DALFactory層，做為資料訪問的工廠，通過.Net的反射機制調用IDAL和PersistenceFacade組成的資料訪問組件中的相關操作。

　　² DataAccessLayer臨時層。首先聲明這層是完全沒有必要的。因為我們在項目中是可以不寫任何Sql語句的。所有的Sql都用Hql代替。設計這層的目的是為了允許項目組中的人員的技術過渡。此層可以通過Sql操作資料庫(不推薦)。架構穩定後本層將不再提供。

　　應用程式框架層(Framework)

　　本層的目的是技術沉澱。將項目之間通用的東西移入應用程式框架層達到代碼重用的目的。本層以後可以黑盒化。可以包括通用的組件。

　　² Framework：積累一些可以抽象出來的方法及控制項

　　² MSMQMessag：訊息處理隊列的實現

　　² Pager：通用翻頁類

　　² Report：通用報表類

　　² Controls：控制項處理類

　　² DataFormat：資料格式轉換類

　　² WebUI：頁面處理類

　　² Validate：資料校正

　　² Object：對象之間的轉換及訪問

　　5 分層式體繫結構的好處

　　1、開發人員可以只關注整個結構中的其中某一層;

　　2、可以很容易的用新的實現來換原有層次的實現;

　　3、可以降低層與層之間的依賴;

　　4、有利於標準化;

　　5、利於各層邏輯的複用。

　　概括來說，分層式設計可以達至如下目的：分散關注、鬆散耦合、邏輯複用、標準定義。

　　一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的介面，負責不同邏輯設計的開發人員就可以分散關注，齊頭並進。例如UI人員只需考慮使用者介面的體驗與操作，領域的設計人員可以僅關注商務邏輯的設計，而資料庫設計人員也不必為繁瑣的使用者互動而頭疼了。每個開發人員的任務得到了確認，開發進度就可以迅速的提高。

　　鬆散耦合的好處是顯而易見的。如果一個系統沒有分層，那麼各自的邏輯都緊緊糾纏在一起，彼此間相互依賴，誰都是不可替換的。一旦發生改變，則牽一髮而動全身，對項目的影響極為嚴重。降低層與層間的依賴性，既可以良好地保證未來的可擴充，在複用性上也是優勢明顯。每個功能模組一旦定義好統一的介面，就可以被各個模組所調用，而不用為相同的功能進行重複地開發。

　　進行好的分層式結構設計，標準也是必不可少的。只有在一定程度的標準化基礎上，這個系統才是可擴充的，可替換的。而層與層之間的通訊也必然保證了介面的標準化。

　　“金無足赤，人無完人”，分層式結構也不可避免具有一些缺陷：

　　1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此擷取相應的資料，如今卻必須通過中介層來完成。

　　2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在展示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的商務邏輯層和資料訪問層中都增加相應的代碼。

　　6 軟體架構視圖

　　Philippe Kruchten在其著作《Rational統一過程引論》中寫道：

　　一個架構視圖是對於從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了於此方面無關的實體。

　　也就是說，架構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力範圍，因此採用“分而治之”的辦法從不同視角分別設計;同時，也為軟體架構的理解、交流和歸檔提供了方便。

　　

　　圖4 Philippe Kruchten提出的4+1視圖方法

　　該方法的不同架構視圖承載不同的架構設計決策，支援不同的目標和用途：

　　l 邏輯視圖：當採用物件導向的設計方法時，邏輯視圖即物件模型。

　　l 開發視圖：描述軟體在開發環境下的靜態組織。

　　l 處理視圖：描述系統的並發和同步方面的設計。

　　l 物理視圖：描述軟體如何映射到硬體，反映系統在分布方面的設計。

　　

　　圖5 運用4+1視圖方法針對不同需求進行架構設計

　　邏輯視圖。邏輯視圖關注功能，不僅包括使用者可見的功能，還包括為實現使用者功能而必須提供的“協助工具功能模組”;它們可能是邏輯層、功能模組等。

　　開發視圖。開發視圖關注程式包，不僅包括要編寫的來源程式，還包括可以直接使用的第三方SDK和現成架構、類庫，以及開發的系統將運行於其上的系統軟體或中介軟體。開發視圖和邏輯視圖之間可能存在一定的映射關係：比如邏輯層一般會映射到多個程式包等。

　　處理視圖。處理視圖關注進程、線程、對象等運行時概念，以及相關的並發、同步、通訊等問題。處理視圖和開發視圖的關係：開發視圖一般偏重程式包在編譯時間期的靜態依賴關係，而這些程式運行起來之後會表現為對象、線程、進程，處理視圖比較關注的正是這些運行時單元的互動問題。

　　物理視圖。物理視圖關注“目標程式及其依賴的運行庫和系統軟體”最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠性、延展性等要求。物理視圖和處理視圖的關係：處理視圖特別關注目標程式的動態執行情況，而物理視圖重視目標程式的靜態位置問題;物理視圖是綜合考慮軟體系統和整個IT系統相互影響的架構視圖。

　　7 小結

　　本文介紹了SaaS的體系架構設計方法。通過對.net主要的開發架構簡介和J2ee主要的開發架構簡介可以分析出各自的優勢與不足。

　　同時介紹了軟體體系架構的分層模式，通過具體分層體現了軟體體系架構的核心價值，架構的模型可以在我們的開發中應用。

SaaS系列介紹之十三: SaaS系統體系架構